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一 ， 版 权 所 有 侵权 必 究 ， 一 


全 书 从 操作 系统 的 基础 知识 入 手 ， 全 面 剖 析 进 程 /线程 、 内 存 管 
理 、Binder 机 制 、GUI 显 示 系 统 、 多 媒体 管理 、 输 入 系统 、 虚 拟 机 等 核 
心 技术 在 Android 中 的 实现 原理 。 书 中 讲述 的 知识 点 大 部 分 来 源 于 工程 
项 目 研发 ， 因 而 具有 较 强 的 实用 性 ， 希 望 可 以 让 读者 “ 知 其 然 ， 更 知 其 
所 以 然 ”。 本 书 分 为 编译 篇 、 系 统 原理 篇 、 应 用 原理 篇 、 系 统 工具 篇 ， 
共 4 篇 25 章 ， 基 本 涵盖 了 参与 Androiqd 开 发 所 需 具备 的 知识 ， 并 通过 大 量 
图 片 与 实例 来 引导 读者 学 习 ， 以 求 尽量 在 源码 分 析 外 为 读者 提供 更 易于 
理解 的 思维 方式 。 


本 书 既 适合 Androiqd 系 统 工程 师 ， 也 适合 于 应 用 开发 工程 师 来 阅 
读 ， 从 而 提升 Android 开 发 能 力 。 读 者 可 以 在 本 书 潜移默化 的 学 习 过 程 
中 更 深刻 地 理解 Android 系 统 ， 并 将 所 学 知识 自然 地 应 用 到 实际 开发 难 
题 的 解决 中 。 

















第 1 版 前 言 


与 本 书 的 原因 


4 次 大 幅 改 版 ，N 次 修订 ， 前 后 历时 近 3 年 ， 本 书 终于 要 与 读者 见面 
Te 


在 这 3 年 的 时 间 里 ，Android 系 统 不 断 更 新 换代 ， 书 本 内 容 也 尽 可 能 
紧 随 其 步伐 一 一 我 总 是 会 在 第 一 时 间 下 载 到 工程 源码 ， 然 后 系统 性 地 比 
对 和 研究 每 次 改版 后 的 差异 。 可 以 说 本 书 伴随 着 Android 的 高 速 发展 ， 
完整 地 见证 了 它 给 大 家 带 来 的 一 次 又 一 次 惊喜 。 


在 这 么 长 的 写作 跨度 中 ， 有 一 个 问题 始终 蒙 绕 在 我 的 脑海 中 ， 
即 “ 为 什么 写 这 本 书 ”? 
市 面 上 讲解 操作 系统 的 著作 很 多 ， 主 要 风格 有 两 种 。 
。 理论 型 
高 校 中 采用 的 操作 系统 教材 多 数 属于 这 种 类 型 。 它 们 主要 阅 述 通用 
的 计算 机 理论 与 原理 ， 一 般 不 会 针对 某 个 具体 的 操作 系统 做 详细 刘 析 。 
这 类 书籍 是 我 们 进入 计算 机 科学 的 “敲门砖 ”。 只 有 基础 打 得 扎实 ， 研 
究 市 面 上 任何 一 款 操作 系统 才能 做 到 “有 的 放 矢 ”。 
。 实用 型 





这 类 书籍 以 讲解 某 个 具体 的 操作 系统 为 主 ， 如 市 面 上 就 有 非常 多 的 
关于 Windows 和 Linux 系 统 的 。 前 者 因为 不 开源 ， 谁 也 不 可 能 深入 代码 级 
别 进行 讲解 ;而 后 者 则 恰恰 相反 ， 任 何人 都 能 轻松 获取 到 完整 的 内 核 源 
码 。 在 Linux 之 父 经 典 名 言 “Read the f**king Source Code” 的 鼓励 下 ， 
无 数 有 志 之 士 投入 到 “代码 汪洋 ”的 分 析 中 ， 从 中 细 细 感受 大 师 们 的 设 
TE Re 

那么 本 书 属于 什么 类 型 呢 ? 个 人 认为 更 贴切 地 说 ， 就 是 上 面 两 种 的 


结合 。 








中 


本 书 的 一 个 主要 宗旨 是 希望 读者 可 以 由 浅 入 深 地 逐步 理解 Andtoid 
系统 的 方方面面 。 因 而 在 每 章节 内 容 的 编排 上 ， 和 采用 由 整体 到 局 部 的 线 
索 铺 展开 来 一 一 先 让 读者 有 一 个 直观 感性 的 认识 ， 明 白 “ 是 什么 “有 
什么 用 ， 然 后 才 剖 析 “ 如 何 做 到 的 ”。 这 样 的 一 个 好 处 是 读者 在 学 习 
过 程 中 不 容易 产生 困惑 ;否则 如 果 直 接 切 入 原理 ， 长 篇 大 论 地 分 析 代 
码 ， 仅 一 大 扒 函 数 调用 就 可 能 让 人 失去 学 习 的 方向 。 这 样 的 结果 往往 
是 ， 读 者 花 了 非常 多 的 时 间 来 理 清 函数 关系 ， 但 始终 不 明白 代码 编写 者 
的 意图 ， 甚 至 连 这 些 函 数 想 实现 什么 功能 都 无 法 完全 理解 。 


本 书 希 望 可 以 从 更 高 的 层次 ， 即 抽象 的 、 反 映 设计 者 思想 的 角度 去 
理解 系统 。 而 在 思考 的 过 程 中 ， 大 部 分 情况 下 我 们 都 将 从 读者 容易 理解 
的 基础 知识 开始 讲 起 。 就 好 比 画 一 张 素描 画 一 样 F 2% 1 — 5k 
白 纸 ,勾勒 出 整体 框架 ， 然 后 针对 重点 部 位 细 细 加 工 ， 最 后 才能 还 原 出 
完整 的 画面 。 男 外 ， 本 书 在 对 系统 原理 本 身 进 行 讲解 的 同时 ， 也 最 大 程 
度 地 结合 工程 项 目 中 可 能 遇 到 的 难点 ， 理 论 联 系 实际 地 进行 解析 。 和 希望 
这 样 的 方式 既 能 让 读者 真正 学 习 到 Android 系 统 的 设计 思想 ， 也 能 学 有 
所 用 ， 增 加 一 些 实 际 的 项 目 开发 经 验 和 技巧 。 










































































本 书 的 主要 内 容 


细心 的 读者 会 发 现 本 书 章节 中 包含 了 “Android 和 OpenGL ES”“ 信 
息 安 全 基础 概述 ”等 看 似 与 本 书 无 关 的 内 容 一 一 有 些 人 可 能 会 产生 疑 
问 ， 是 否 有 此 必要 ? 


根据 我 们 多 年 的 Android 项 目 开 发 和 培训 经 验 ， 答案 就 是 “非常 有 
必要 ”。 举 个 例子 ，Android 的 显示 系统 是 围绕 OpenGL ES 来 展开 的 ， 后 
者 是 它 的 “根基 xz，。 但 另外 ， 并 非 所 有 开发 人 员 都 Ve i OpenGL 
ES。 这 样 导 致 的 结果 就 是 他 们 在 学 习 显 示 系 统 的 过 程 中 ， 有 一 种 “四 处 
Ab BE” 的 感觉 实践 证 明 ， 正 是 这 些 因素 直接 打击 到 了 大 家 学 习 
Android 系 统 的 信心 。 


因此 我 们 在 讲解 系统 实现 原理 之 前 ， 会 最 大 程度 地 为 读者 提炼 出 所 
需 的 背景 知识 。 有 了 这 样 的 铺垫 ， 相 信 对 大 家 学 习 Android 内 核 大 有 祷 
ith o 


本 书 在 内 容 选 择 上 依据 的 是 “研发 人 员 (包括 系统 开发 和 应 用 程序 
FR) 参与 实际 Android 项 目 所 需 具 备 的 知识 ”， 因 而 具有 较 强 的 实用 
性 。 全 书 共 分 为 4 篇 ， 涵 盖 了 编译 、 系 统 原理 、 应 用 原理 和 系统 工具 等 
多 个 方面 。 


其 中 第 一 篇 不 仅 详细 介绍 了 Android 源 码 的 下 载 及 编译 过 程 ， 为 读 
者 呈现 了 “Hello World” 式 的 入 门 向 导 更 为 重要 的 是 ， 结 合 编译 系 
统 的 架构 和 内 部 原理 ， 为 各 厂家 定制 自己 的 Android 产 品 提供 了 参考 范 
例 。 


Android 本 质 上 只 是 市 面 上 众多 主流 的 操作 系统 之 一 。 所 以 在 系统 
原理 的 讲解 过 程 中 ， 我 们 将 首先 引导 读者 从 计算 机 体系 结构 、 经 典 的 操 
作 系 统 理论 (比如 进程 /线程 管理 、 进 程 间 通信 等 ) 的 角度 来 思考 问题 
包括 Andtoid 在 内 的 任何 操作 系统 内 核 在 实现 过 程 中 都 “ 逃 ” 不 出 
这 些 经 典 的 理论 范畴 。 本 书 虽 然 是 剖析 Android 系 统 的 ， 但 更 希望 读者 


























可 以 从 中 学 到 ie” , WAR E” 


从 动态 运行 的 角度 来 理解 ，Android 内 核 是 由 众多 系统 服务 组 成 
的 ， 如 ActivityManagerService、GUI 系 统 中 的 SurfaceFlinger、 音 频 系 统 中 
的 AudioFlinger、 输 入 系统 InputManagerService 等 。 而 各 服务 之 间 通 信 的 
基础 就 是 Binder 机 制 。 本 书 在 阐述 它们 错综复杂 的 关系 中 ， 遵 循 由 “ 整 
体 到 局 部 ”“ 由 点 及 面 ”的 科学 方法 ， 将 知识 点 深入 浅 出 地 铺展 开 来 ， 
希望 为 读者 全 面 理解 Android 内 核 提 供 “ 思 维 捷径 。 


与 其 他 讲解 Android 应 用 程序 的 书籍 不 同 ， 本 书 在 分 析 APK 应 用 程 
序 时 的 立足 点 是 它 的 内 部 实现 原理 。 如 Intent 匹 配 规则 、 应 用 程序 的 资 
源 适 配 过 程 、 字 符 编码 的 处 理 、Widget 机 制 、 应 用 程序 的 编译 打包 等 都 
是 应 用 开发 人 员 在 工作 中 经 又 常 会 遇 到 的 难题 。 通 过 系统 性 地 解析 隐藏 在 

这 些 实现 背后 的 原理 ， 有 助 于 他 们 彻底 摆脱 困惑 ， 加 深 对 应 用 开发 的 理 
解 。 


不 论 是 系统 工程 师 还 是 应 用 开发 人 员 ， Android 调 试 工具 都 至 关 重 
要 。 但 我 们 在 实际 工作 中 发 现 ， 不 少 研发 人 员 对 这 些 工具 “只 知 其 一 ， 
不 知 其 二 ”。 因 而 系统 工具 篇 中 将 针对 常用 调试 工具 进行 全 面 解析 ， 希 
望 由 此 可 以 让 大 家 学 习 到 如 何 “ 举 一 反 三 ”， 真 正 把 它们 的 作用 发 挥 
得 “淋漓 尽 致 ”。 


















































本 书 的 主要 特点 


(1) 通过 大 量 情景 图 片 与 实例 引导 读者 学 习 ， 以 求 尽量 在 源码 分 
析 外 为 读者 提供 更 易于 理解 的 思维 路 径 。 


(2) 作者 在 展开 一 个 话题 时 ， 通 常会 由 浅 入 深 、 由 总 体 框架 再 到 
细节 实现 。 这 样 可 以 保证 读者 能 跟 得 上 分 析 的 节奏 ， 并 且 “ 有 根 有 据 可 
循 ”，， 尽 可 能 防止 部 分 读者 阅读 技术 书籍 时 “看 了 后 面 扎 了 前 面 ”的 现 
象 。 








(3) 目前 市 面 上 不 少 Android 书 籍 仍 停留 在 Android 2.3 或 者 更 早期 
的 版 本 。 虽 然 原 理 类 似 ， 但 对 于 开发 人 员 来 说 ， 他 们 需要 与 项 目 研发 相 
契合 的 技术 书籍 。 本 书 希望 尽 可 能 紧 随 Android 的 更 新 步伐 ， 为 读者 了 
解 最 新 的 Andtoid 技 术 提 供 帮 助 。 


(4) 本 书 的 出 发 点 仍 是 操作 系统 的 经 典 原理 ， 并 以 此 为 根基 扩展 
分 析 Android 中 的 具体 实现 机 制 一 一 贯 宅 其 中 的 是 经 久 不 衰 的 理论 知 


Wo 








(5) 本 书 所 阐述 的 知识 点 大 部 分 来 源 于 工程 项 目 研发 的 经 验 总 
结 ， 因 而 具有 较 强 的 实用 性 ， 希 望 可 以 让 读者 “ 知 其 然 ， 更 知 其 所 以 
然 ”。 做 到 真正 贴近 读者 ， 贴 近 开 发 需求 。 
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第 2 版 前 言 


Android 系 统 的 诞生 地 一 一 美国 硅谷 。 


nm 








Google 大 楼 前 摆 放 着 Android 的 最 新 版 本 有 雕塑， 历史 版 本 则 被 放置 在 Android Statues Park P 


写 第 2 版 前 言 时 ， 笔 者 刚好 在 美国 加 州 硅谷 等 地 公事 出 差 访问 。 其 
间 我 一 直 在 思考 的 问题 是 ， 美 国 硅 合 (Silicon Valley) 在 近 几 十 年 时 间 
里 长 感 不 衰 的 原因 是 什么 ? 技术 的 浪潮 总 是 一 波 接着 一 波 的 ， 谁 又 会 在 
不 远 的 将 来 接 茜 Google 的 Android 系 统 ， 在 操作 系统 领域 成 为 下 一 轮 的 弄 
潮 儿 ?我 们 又 应 该 如 何 应 对 这 种 “长 江 后 浪 推 前 浪 ” 的 必然 更 迭 呢 ? 


从 历史 的 长 河 来 看 ， 新 技术 、 新 事物 的 诞生 往往 和 当时 的 大 背景 有 
着 不 可 分 割 的 关系 。 如 果 我 们 追溯 硅谷 的 发 展 史 ， 会 发 现 其实 它 相对 于 
美国 很 多 传统 地 区 来 说 还 是 非常 年 轻 的 。 “硅谷 ， 这 个 词 是 在 1971 年 
HY “Silicon Valley in the USA” 系 列 报导 文章 中 才 首 次 出 现 的 。20 世 纪 四 
五 十 年 代 开 始 ， 硅 谷 就 像 一 匹 脱 了 组 的 野马 一 般 ，“ 一 发 不 可 收拾 ”。 
从 早期 的 Hewlett-Packard 公 司 ， 到 仙 童 、AMD、Intel 以 及 后 来 的 Apple、 
Yahool 等 众多 世界 一 流 企 业 ， 硅 谷 牢 牢 把 握 住 了 科技 界 的 几 次 大 变革 ， 
成 功 汇集 了 美国 90% 以 上 的 半导体 产业 ， 逐 步 呈 现 出 “生生 不 息 ” 的 最 
象 。 



































但 为 什么 是 硅谷 ， 而 不 是 美国 其 他 地 区 成 为 高 科技 行业 的 “发 动 
机 ” 呢 ? 


TAZ, SAh Wih AR, ZETE, BEAR?” o 


现在 我 们 回 过 头 来 看 这 段 历 史 ， 应 该 说 硅谷 早期 的 发 展 和 当时 的 世 
界 大 环境 有 很 大 关系 一 一 更 确切 地 说 ， 正 是 美国 国防 工业 的 发 展 诉求 ， 
才 给 了 硅谷 创业 初期 的 “第 一 桶 金 ”。 只 有 “ 先 活 下 来 ， 才 有 可 能 走 得 
更 远 ”。 而 接 下 来 社会 对 半导体 工业 需求 的 爆炸 式 增长 ， 同 样 让 硅谷 占 
据 了 “天 时 ”的 优势 ， 再 接 再 厉 最 终 走 上 良性 循环 。 


























密密麻麻 的 硅谷 大 企业 
(引用 自 cdn.com ) 


硅谷 的 “地 利 ” 和 “人 和 ”， 可 能 主要 体现 在 : 


(1) Stanford University 
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斯 坦 福 大 学 校 


Stanford Univetsity 在 硅谷 的 发 展 过 程 中 起 到 了 非常 关键 的 作用 。20 
世纪 50 年 代 的 时 候 ， 这 所 大 学 还 并 不 是 很 起 眼 ， 各 方面 条 件 都 比较 精 
糕 ， 她 的 毕业 生 也 多 数 会 去 东海 岸 寻求 就 业 机 会 。 后 来 她 的 一 位 教授 
Frederick Terman 看 到 了 产业 和 学 术 的 接合 点 ， 从 学 校 里 划分 出 一 大 块 空 
地 来 鼓励 学 生 创 业 ， 并 且 指 导 其 中 两 位 学 生 创 立 了 Hewlett-Packard 公 
司 。 随 后 的 几 年 他 又 成 立 了 Stanford Research Patk， 这 也 同时 是 后 来 全 球 
各 高 科技 园区 的 起 点 ， 并 吸引 了 越 来 越 多 的 公司 加 入 。 在 那 段 时 间 里 ， 
相信 起 到 核心 催化 作用 的 是 “ 产 ”+ “学 ”的 高 度 结 合 一 一 将 科技 产品 
不 断 推 陈 出 新 产生 经 济 效 益 ， 然 后 再 回馈 到 研究 领域 。 在 几 十 年 的 跨度 
里 ,很 多 顶尖 公司 (Google、Yahool、HP 等 ) 的 创始 人 都 出 自 该 校 。 有 
统计 显示 Standford 师 生 及 校友 创造 了 硅谷 一 半 以 上 的 总 产值 ， 其 影响 力 
可 见 一 斑 。 


(2) 便利 的 地 理 环 境 


整个 硅谷 地 区 面积 并 不 是 很 大 ， 属 于 温带 海洋 性 气候 ， 全 年 平均 温 
度 在 13C ~24C ， 污 染 很 小 。 同 时 ， 它 依 林 傍 海 ， 陆 、 海 、 空 都 可 以 很 
好 地 与 外 界 相连 ， 这 样 一 来 自然 有 利于 人 才 的 引入 。 


(3) 鼓励 创新 ， 完 善 的 专利 保护 机 制 


从 法 律 上 讲 ， 硅 合 每 年 有 超过 4000 项 的 专利 申请 ， 工 程 师 和 律师 的 
比例 达到 了 10 : 1。 在 创新 点 得 到 保护 的 同时 ， 也 使 得 初创 公司 能 够 得 
到 进一步 的 发 展 ， 从 而 避免 它们 被 扼杀 在 摇篮 中 。 从 观念 上 来 说 ， 硅 谷 
和 对 知识 产权 还 是 非常 尊重 的 ， 他 们 大 多 认为 旭 禄 是 没有 技术 含量 的 ， 
相当 于 “润泽 而 渔 。 


(4) 完善 的 风 投 体系 ， 并 容忍 失败 
事实 上 在 硅谷 创业 ， 其 成 本 和 失败 率 都 很 高 其 中 能 存活 3 一 5 年 
的 公司 只 有 10% 一 20%。 一 方面 ， 风 险 投 资方 需要 高 度 容 驴 这 样 的 失败 


率 ; 另 一 方面 ， 在 允许 快速 斌 错 的 同时 ， 风 险 投资 方 又 可 以 从 某 些 成 功 
中 获得 巨大 收益 一 一 硅谷 就 是 一 个 可 以 达到 这 种 矛盾 平衡 的 神奇 所 在 







































































地 。 


“三 十 年 河东 ， 三 十 年 河西 ”， 技 术 的 浪潮 总 是 在 不 断 演进 的 。 从 
Symbian, Black Berry， 到 Android、iOS，, 历史 经 验 告 诉 我 们 没有 一 项 技 
术 是 会 永远 一 成 不 变 的 。 所 以 我 们 在 技术 领域 的 探索 过 程 中 ， 既 要 
ZE”, 更 要 学 会 渔 一 一 前 者 是 为 当前 的 工作 而 努力 ， 后 者 则 是 
为 我 们 的 未 来 做 投资 。 以 Android 操 作 系 统 为 例 ， 事 实 上 我 们 除了 “ 知 
其 然 ” 外 ， 还 更 应 该 学 习 它 的 内 部 设计 思想 BY “ant UPR” 未 当 
我 们 真正 地 理解 了 那些 “精华 ”所 在 以 后 ， 那 么 相信 以 后 再 遇 到 任何 其 
他 的 操作 系统 ， 就 都 可 以 做 到 “ 触 类 旁 通 ”了 。 也 只 有 这 样 ， 或 许 才 能 
在 快速 变革 的 科技 领域 中 把 握 住 脉搏 ， 立 于 不 败 之 地 。 
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于 美国 硅谷 


关于 本 书 第 2 版 


在 第 1 版 上 市 的 这 两 年 时 间 里 ， 不 断 有 读者 来 信 分 享 他 们 阅读 本 书 
时 的 感想 和 心得 ， 笔 者 首先 要 在 这 里 更 心地 向 大 家 说 声 感 谢 ! 正 是 你 们 
的 支持 和 肯定 ， 才 有 了 《深入 理解 Android 内 核 设计 思想 》 (第 2 版 ) 的 
PEA. 


其 中 有 不 少 读者 提 到 了 他 们 希望 在 本 书后 续 更 新 中 看 到 的 内 容 ， 包 
括 Android 虚 拟 机 的 内 部 实现 原理 、Android 的 安全 机 制 、Gradle 自 动 化 构 
建 工 具 等 一 一 这 些 要 求 都 在 本 次 版 本 更 新 中 得 到 了 体现 。 


需要 特别 说 明 的 是 ， 第 2 版 中 的 所 有 新 增 和 有 更 新 的 部 分 都 是 基于 
Android 最 新 的 N 版 本 展开 的 。 由 于 Android 版 本 的 更 新 换代 很 快 ， 且 版 
本 问 的 差异 巨大 ， 导 致 书 中 很 多 内 容 几 乎 需要 全 部 重 写 。 另 外 笔者 写 书 
都 是 在 下 班 后 的 业余 时 间 进 行 的 ， 所 以 即便 是 每 晚 奋 笔 疾 书 到 深夜 ， 再 
加 上 周末 和 市 假日 时 间 (如 果 没 有 加 班 工作 的 话 ) ， 最 后 发 现 更 新 全 书 
所 需 时 间 依然 要 大 于 Android 系 统 的 发 布 间隔 。 为 了 让 读者 可 以 早日 阅 
读 到 大 家 感 兴趣 的 内 容 ， 本 次 版 本 的 部 分 章节 保留 了 第 1 版 的 原 有 内 容 
一 一 本 书 下 一 次 再 版 时 会 争取 将 它们 更 新 到 Android 的 最 新 版 本 。 这 一 
点 希望 得 到 大 家 的 谅解 ， 谢 谢 ! 














致谢 


感谢 我 目前 任职 公司 的 领导 和 同事 们 ， 是 你 们 的 帮助 和 支持 ， 才 让 
我 更 快 地 融入 到 了 这 个 大 家 庭 中 。 在 一 个 到 处 都 是 “聪明 人 HA 
有 “ 狼 性 奋斗 者 ”精神 的 公司 里 ， 每 天 的 进步 和 知识 积累 都 是 让 人 愉悦 
的 。 


感谢 人 民 邮 电 出 版 社 的 编辑 ， 你 们 的 专业 态度 和 处 理 问题 的 人 性 
化 ， 是 所 有 作者 的 “福音 ” 


Ra RAPER, TK. MRE. WR. MAR. A 
明 ， 没 有 你 们 的 鼓励 与 理解 ， 就 没有 本 书 的 顺利 出 版 。 


感谢 我 的 麦子 张 白 杨 的 默默 付出 ， 是 你 工作 之 外 还 无 她 无 悔 地 在 照 
顾 着 我 们 可 爱 的 宝宝 ， 才 让 我 有 充足 的 时 间 和 精力 来 写作 。 


感谢 所 有 读者 的 支持 ， 是 你 们 赋予 了 我 写作 的 动力 。 另 外 ， 因 为 个 
人 能 力 和 水 平 有 限 ， 书 中 难免 会 有 不 足 之 处 ， 和 希望 读者 不 识 指 教 ， 一 起 
探讨 学 习 ， 作 者 的 联系 方式 是 : xuesenlin@alumni. cuhk.net。 编 辑 联系 
和 投稿 邮箱 是 : zhangtao(@ptpress.com.cn。 本 书 读者 交流 QQ 群 为 
216840480。 
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#12 Android 系 统 简 介 
第 2 章 Android 源 码 下 载 及 编译 


$ 3% Android 编 译 系统 


. 
Android 系 统 简 介 


美国 当地 时 间 2015 年 5 月 28 日 ，“Google 1/0 2016” 大 会 在 旧金山 
市 的 Moscone _ Center 举行 。 


会 议 公布 的 官方 数据 如 下 : 


全 球 已 经 激活 的 Android 设 备 达 到 9 亿 次 ; 

Google Play 中 收录 了 超过 70 万 的 应 用 程序 ; 

应 用 程序 安装 量 达到 480 亿 次 ; 

132 个 以 上 的 国家 或 地 区 销售 Android 设 备 ; 

超过 190 个 国家 或 地 区 可 以 下 载 到 免费 的 Android 应 用 程序 。 


2016 年 ，Google 则 直接 把 大 会 地 址 从 传统 的 Moscone Center 改 到 了 
Shoreline 公 园 的 户外 ， 吸 引 了 成 和 上 万 来 自 全 球 各 地 的 科技 爱好 者 。 


从 2008 年 9 月 Google 发 布 Android 1.0 版 本 开始 ，Android 已 经 走 过 
了 8 个 年 头 。 在 这 短 短 的 几 年 间 ， 这 个 以 机 器 人 为 Logo 的 操作 系统 不 仅 
席卷 了 全 球 各 地 的 手机 市 场 ， 而 且 与 ij0S、Windows _ Phone 形成 三 足见 立 
之 势 ， 更 渗透 到 传统 与 新 兴 电 子 产 业 的 方方面面 。 越 来 越 多 的 电子 产品 
已 开始 采用 Android 系 统 ， 如 Android 电 视 、 平 板 电脑 、MP4 等 与 人 们 日 
党 生活 息息相关 的 电子 设备 。 


那么 ，Android 势 不 可 当 的 魅力 从 何 而 来 呢 ? 本 章 将 试 着 以 Android 
系统 的 发 展 历史 为 主线 ， 先 为 读者 提供 最 直观 的 背景 知识 ， 从 而 为 以 后 
的 “ 透 过 现象 看 本 质 ” 打 下 一 定 的 基础 。 


1.1 Android 系 统 发 展 历程 

“Android” 一 词 先天 就 充满 着 天 才 们 改变 世 夫 的 梦想 味 。 虽 然 一 
件 杰 出 的 作品 并 不 能 只 靠 “ 名 号 ”， 但 毋庸 置疑 的 是 ， 一 个 叫 得 啊 又 耐 
人 寻味 的 名 称 总 会 使 人 产生 不 自觉 的 杀 近 感 。 这 或 许 就 是 每 个 Android 
Rae 下 面 来 看 看 各 个 版 本 对 应 的 Android“ 外 
= 0H 表 1-1 所 示 。 
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“Android” 一 词 来 源 于 法 国 作 家 Auguste Villiers de l'Isle- 
Adam 的 科幻 小 说 《L'eve future) (AKI) ， 是 机 器 人 的 意思 。 
此 ， 最 初 每 个 系统 版 本 的 命名 也 都 是 以 全 球 著 名 的 机 器 人 为 参考 的 ， 

如 “AstroBoy”。 后 来 由 于 版 权 问题 ， 才 改 为 以 食物 的 方式 取 名 。 不 过 
Android 的 Logo 仍 然 是 机 器 人 的 形象 ， 如 图 1-1 所 示 。 





全 图 1-1 Android 官 方 Logo 


和 很 多 著名 的 科技 企业 一 样 ，Android 的 创始 人 Andy Rubin 也 是 一 
个 技术 狂人 。 在 创立 Android 公 司 前 ， 他 曾 完 成 多 项 当时 被 称 为 “过 于 
超前 ”的 产品 研发 ， 并 取得 了 一 定 的 成 绩 。 而 创办 Android， 最 初 的 目 
的 是 提供 一 款 开 放 式 的 移动 平台 系统 。 从 2003 年 10 月 Andy Rub in 开始 启 
动 这 一 系统 的 研究 ，Android 便 正式 走 上 历史 的 舞台 。 以 下 是 关于 这 个 
系统 的 一 些 重要 历史 事件 。 


e 2003 年 10 月 ，Andy Rubin 在 加 利 福 尼 亚 州 成 立 Android 公 司 。 

e 2005 年 4 月 ，Google 收 购 Android。 

e 2007 年 11 月 ，Google 成 立 OHA (Open Handset Alliance) 联盟 ， 成 员 
包括 Google、Broadcom、HTC、Intel、LG、Marvell、Motorola、 
NVIDIA、Qualcomm、Samsung 等 通信 行业 和 和 芯片 制造 领域 的 巨 
头 。 随 后 几 年 ， 这 个 联盟 又 陆续 有 不 少 公 司 加 入 ， 如 著名 的 Arm 公 
司 、 中 国 的 华为 等 

2007 年 11 月 ，Google 成 立 “Android Open Source 

Project” (AOSP) 。 这 一 项 目的 起 步 标 志 着 Android 系 统 首次 公开 
面向 全 世界 的 开发 者 与 使 用 者 。 


AOSP 的 宗旨 是 : 


Android Open Source Project is to create a successful 
real-world product that improves the mobile experience for end 
user So 


因为 是 开源 开放 的 组 织 ， 所 以 意味 着 每 个 人 都 可 以 参与 进来 ， 并 为 
整个 项 目的 发 展 添 砖 加 瓦 。 如 果 读 者 有 意愿 成 为 其 中 的 一 员 ， 可 以 参考 
该 组 织 的 相关 说 明 Chttp://source. android. com/source/ 
index. html) 。 


e 200711} , Android Beta 版 本 发 布 。 
e 2007 年 11 月 ，Android 第 一 个 SD 开 版 本 发 布 。 


e 2008 年 9 月 ，Android 1.0 版 本 正式 发 布 。 


至 此 ，Android 版 本 的 发 布 驶 入 正常 轨道 ， 保 持 着 每 年 多 次 升级 的 
速度 ， 并 加 入 越 来 越 多 的 创新 功能 。 


关于 Android 每 个 版 本 的 特性 及 改版 后 一 些 重要 变化 的 详细 说 明 ， 
请 参阅 官方 网 站 
(http://source. android. com/source/overview. html) 。 相 信 经 过 仔 
细 比 对 各 个 版 本 的 变化 ， 读 者 会 发 现 Android 系 统 确 实 一 直 在 秉承 
其 “为 终端 用 户 提供 更 好 的 移动 设备 体验 ”的 宗旨 。 


1.2 ”Android 系 统 特 点 


在 这 一 证 中， 我 们 将 从 观察 者 的 角度 来 各 观 评价 Android 系 统 芭 些 
突出 的 特点 。 这 些 分 析 中 既 包 含 了 其 值得 肯定 的 诸多 优点 ， 也 不 音 指 出 
其 需要 持续 改善 的 地 方 。 只 有 正确 全 面 地 了 解 一 个 系统 所 存在 的 优 缺 
en A a a 
门 所 用 。 


1. 开放 与 扩展 性 


相对 于 i0S 和 Windows _ Phone 阵营 ，Android 操 作 系 统 最 大 的 特点 就 
是 开放 性 ; MAASIF-MIFHRREN “Ramin” A HOE EASE 
面 ”，Android 几 乎 所 有 源码 都 可 以 免费 下 载 到 。 无 论 是 公司 组 织 ， 还 
是 个 人 开发 者 ，Android 对 于 下 载 者 基本 没有 限制 ， 也 没有 下 载 权 限 的 
认证 束缚 。 关 于 如 何 下 载 系统 源码 的 完整 描述 ， 请 参考 下 一 章节 。 


当然 ， 这 并 不 代表 开发 者 可 以 随意 使 用 Android 源 码 。 事 实 上 ， 
Android 遵 循 的 是 Apache 开 源 软件 许可 证 。 因 此 ， 所 有 跨越 许可 证 规定 
范畴 的 行为 都 将 是 被 禁止 的 。 和 希望 了 解 更 多 Apache 协 议 条 款 详情 的 读 
者 ， 可 以 自行 查阅 其 官方 说 明 (http://www. apache. org/) 。 


不 过 在 大 部 分 情况 下 ，Android 操 作 系 统 仍然 被 认为 是 “高 度 自 
由 ”的 。 这 也 是 越 来 越 多 的 厂商 选择 Android 作 为 下 一 代 产 品 基 础 平台 
最 主要 的 原因 之 一 。 可 以 想象 ， 在 其 他 操作 系统 对 其 授权 的 设备 动 辆 收 
取 每 台 高 达 几 十 甚至 数 百 美元 专利 费 的 情况 下 ， 采 用 Android 开 源 系 统 
理论 上 融 意 味 着 降低 成 本 。 


另外 ， 由 于 整个 操作 系统 是 开源 的 ， 从 而 给 诸多 产品 制造 商 、 软 件 
开发 商 提供 了 创新 的 土壤 环境 。 各 厂商 可 以 根据 自己 的 需求 ， 来 完成 对 
原生 态 系统 的 修改 。 大 多 数 情况 下 ， 这 种 修改 只 是 基于 上 层 U1 交 互 
的 “二 次 包装 ”， 而 保留 底层 系统 的 大 框架 。 这 就 好 比 Goog1e 为 大 家 免 
费 提 供 了 已 经 苹 好 的 办 公 大 楼 ， 虽 然 是 毛坯 房 ， 但 相 较 于 “万 丈 高 楼 平 
地 起 ”的 艰 平 ， 显 然 已 经 为 我 们 市 约 了 大 量 的 项 目 时 间 ; 而 且 我 们 可 以 
通过 “ 闭 修 ”把 主要 精力 倾注 在 用 户 看 得 到 的 地 方 ， 从 而 更 大 限度 地 摆 
及 “产品 同 质 化 ”。 事 实 上 ， 目 前 全 球 范 围 内 已 经 有 非常 多 这 样 的 “法 
修 范 例 ”。 大 到 跨国 企业 、 运 营 商 ， 小 到 一 些 初创 的 设计 公司 ， 都 选择 
在 Android 系 统 上 进行 “表面 ”改造 ， 再 冠 以 新 的 操作 系统 名 号 。 其 中 


也 不 乏 一 些 成 功 者 ， 根 据 不 同 的 地 域 环境 、 文 化 差异 、 使 用 习惯 而 定制 
出 新 的 系统 一 一 这 些 具有 “本 地 化 ”风格 的 “办 公 楼 ”往往 比 原生 态 系 
统 更 贴近 当地 消费 者 ， 因 此 受到 热烈 追捧 。 


而 这 一 切 ， 都 要 归功 于 Android 系 统 的 开放 性 。 
2. 合理 的 分 层 架 构 


要 学 习 Android 系 统 ， 就 不 得 不 提 它 的 分 层 架 构 。 早 期 版 本 的 
Android 系 统 框架 包括 4 层 ， 即 Linux Kernel, Library and Runtime, 
Application Framework 及 Application。 后 来 因为 版 权 相 关 原因 在 
Kerne1 层 之 上 新 增 了 一 个 Hardware Abstraction Layer 。 我 们 会 在 后 续 
小 节 对 各 层 功 能 适当 地 展开 讨论 。 


由 此 可 见 ，Android 系 统 是 一 个 “ 杂 合 体 ”， 即 便 说 其 “包罗 万 
象 ”也 一 点 不 为 过 。 它 包括 了 prebui lt、bionic 等 在 内 的 不 少 开 源 项 
目 。 管 理 这 些 项 目 显 然 不 是 件 容易 的 事 ， 这 也 是 Android 系 统 提 供 Repo 
cee it 来 进行 版 本 管理 的 原因 之 一 《〈 详 见 后 续 章 节 
JHR) 。 


在 面 对 这 么 多 独立 项 目的 时 候 ， 合 理 的 分 层 架 构 融 显得 异常 重要 
既 要 保证 系统 功能 的 完整 性 ， 也 要 确保 各 项 目的 相对 独立 性 。 
Android 系 统 成 功 地 做 到 了 这 一 点 ， 整 个 软件 栈 条 理 清 晰 ， 分 工 明确 。 
一 方面 ， 它 将 底层 复杂 性 与 移植 难度 尽 可 能 隐藏 起 来 ; 另 一 方面 ， 则 提 
oe 1 接口 ， 为 开发 者 设计 实现 各 种 应 用 程序 打下 了 
坚实 JÆ Ail o 





3. 易 用 强大 的 SDK 


SDK (Software Development Kit) 是 操作 系统 与 开发 者 之 间 的 接 
口 ， 也 可 以 看 成 一 个 系统 对 外 的 窗口 。 对 于 广大 的 开发 者 而 言 ， 能 否 借 
助 这 个 工具 在 尽 可 能 短 的 周期 内 设计 出 符合 需求 而 又 稳定 可 靠 的 应 用 程 
序 ， 是 评判 一 个 操作 系统 SDK 好 坏 的 重要 标准 之 一 。 


Android 系 统 的 大 部 分 应 用 程序 可 以 基于 Java 来 开发 。 如 果 读者 曾 
参与 过 大 型 的 C/C++ 研 发 项 目 〈 特 别 是 面向 嵌入 式 系统 的 ) ， 一 定 不 会 
忘记 加 班 加 点 解决 内 存 泄露 或 者 空 指针 异常 的 那些 无 眠 夜 。Java 语 言 对 
这 些 软件 开发 中 最 令 人 头疼 的 问题 进行 了 强 有 力 的 改造 ， 不 但 提供 了 垃 


圾 回收 机 制 | 而 且 彻 底 隐藏 了 指针 的 使 用 。 即 便 程 序 出 现 了 衣 溃 ， 通 常 
情况 下 也 可 以 根据 调用 栈 及 各 种 Log 来 定位 出 问题 的 根源 。 这 无 疑 为 我 
们 快速 解决 问题 、 保 证 程序 稳定 性 提供 了 很 好 的 平台 基础 。 


Android 系 统 通过 总 结 应 用 程序 的 开发 规律 ， 提 供 了 Activity、 
Service, Broadcast Receiver 及 Content Provider 四 大 组 件 ; 并且 和 
MFC 类 似 ， 设 计 了 人 性 化 的 向 导 模 式 来 帮助 开发 者 便捷 地 生成 工程 原 
型 。 可 以 说 ， 这 些 都 为 项 目 开 发 节约 了 不 少 宝贵 时 间 。 


另外 ，Android SDK 覆 盖 面 相当 广 ， 且 仍 在 持续 扩充 中 。 从 线程 管 
IE, FFE E SET Raa MARAEA, REZARSA 
能 想到 的 ， 几 乎 都 可 以 在 SDK 中 找到 现成 的 调用 接口 。 而 对 一 些 珊 面 特 
效 的 封装 ， 使 得 开发 者 可 以 高 效 地 设计 出 各 种 绚丽 的 U1 效果 ， 进 而 让 
Android 系 统 加 分 良 多 。 


4. 不 断 改 进 的 交互 界面 


Android 版 本 的 更 返 是 一 件 让 无 数 人 兴奋 的 事 。 除 了 那些 令 人 眼前 
一 亮 的 新 功能 外 ， 不 断 改 进 的 用 户 交 互 再 面 也 是 吸引 用 户 的 一 个 重要 因 
素 。 a 
验 的 决心 。 


下 面 先 来 看 看 Gingerbread (2. 3 版 本 ) 的 Launcher 与 Cbamera 界 面 ， 
如 图 1-2 所 示 。 
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他 图 1-2 Launchetr 和 Camera 界 面 


然后 来 看 看 后 续 版 本 上 的 变化 ， 如 图 1-3 所 示 。 











全 图 1-3 ”后续 Andtoid 版 本 变化 


可 以 发 现 ， 新 的 版 本 相 较 于 以 前 ， 不 但 在 JI 表面 的 色彩 搭配 、 布 局 
上 有 了 很 大 提高 ， 用 户 交 互 也 更 趋 于 人 性 化 。 这 种 对 于 用 户 最 直观 
的 “艺术 盛 刘 ” 展 示 ， 促 使 越 来 越 多 的 人 投身 到 Android 阵 营 中 。 


5. 逐步 完善 的 生态 系统 


1T 业 再 长 期 以 来 都 有 一 个 共识 一 一 开发 一 个 操作 系统 《0S) 并 不 是 
最 难 的 ， 而 基于 这 个 新 的 操作 系统 建立 完整 的 生态 系统 才 是 最 大 的 难 


点 。 用 一 名 老话 来 说 ， 颇 有 点 “ 打 江山 易 ， 守 江山 难 ”的 味道 。 


那么 ， 什 么 是 基于 0S 的 生态 系统 (ecosystem) We? 虽然 我 们 一 再 
听 到 媒体 在 大 哇 宣 扬 这 个 词 ， 但 目前 还 没有 人 能 给 出 权威 、 严 说 的 解释 
来 前 述 这 个 特殊 “生态 系统 ”的 定义 与 形成 。 本 书 下 面 所 提出 的 释义 也 
未 必 能 完整 解读 这 个 词 ， 读 者 可 以 市 着 自己 的 理解 深入 思考 。 


Ecosystem 原 本 是 生态 学 中 的 一 个 概念 。 简 单 而 言 ， 它 体现 了 一 定 
时 间 和 空间 内 能 量 的 可 循环 平衡 流动 ， 例 如 ， 自 然 界 的 生态 系统 组 成 如 
Te 


无 机 环境 ， 包 括 太 阳 、 有 机 物质 、 无 机 物质 等 非 生 物 环境 。 
生产 者 。 
消费 者 。 
分 解 者 。 


因此 ， 它 们 之 间 所 体现 出 的 能 量 循环 如 图 1-4 所 示 。 





全 图 1-4 自然 生态 系统 的 能 量 循环 
生产 者 依靠 无 机 环境 制造 食物 ， 并 实现 自 养 ; 而 消费 者 则 需要 消耗 
其 他 生物 来 生存 发 展 ; 分 解 者 最 终 将 有 机 物 分 解 为 可 被 生产 者 重新 利用 
的 物质 。 这 样 ， 就 构成 了 整个 生态 链 的 循环 。 


针对 Android 生 态 系统 ， 我 们 可 以 得 到 以 下 的 类 比 ， 如 图 1-5 所 示 。 





全 图 1-5 Android 生 态 系 统 假想 
在 Android 生 态 系 统 中 : 


。Android 系 统 提供 了 底层 基础 平台 ; 

。 开 发 者 通过 研发 新 产品 来 获取 利润 ， 或 者 提供 相应 服务 ; 

。 消 费 者 使 用 这 些 产品 或 服务 来 满足 自身 需求 ; 

。Market 提 供 了 开发 者 与 消费 者 间 资 金 支付 与 交易 的 平台 ， 加 快 了 生 
物 间 的 “能 量 ” 流 动 。 


当然 ， 这 只 是 本 书 对 Android 生 态 系统 的 一 个 初步 设想 ， 实 际 情况 
一 定 更 复杂 。 但 客观 来 说 ，Goog le 一 方面 既 在 努力 打造 “双赢 ”的 市 场 
机 制 ， 以 吸引 更 多 的 开发 者 介入 ; 另 一 方面 也 在 提高 为 消费 者 服务 的 能 
力 ， 如 图 1-6 所 示 。 


~ Android 
Eos 


Blackberry 
E Windows Phone 
[Other 





全 图 1-6 各 操作 系统 平台 占有 率 及 开发 者 赢利 对 比 


虽然 最 新 的 调查 报告 显示 ， 依 靠 Android 软 件 赢利 的 开发 者 寥寥 无 
几 ， 还 远 远 比 不 上 i0S 系 统 赢利 模式 成 熟 〈 见 图 1-6) 。 但 同时 也 应 该 看 
到 ， 随 着 整个 Android 市 场 占有 率 的 提升 以 及 Goog1e 一 系列 措施 的 实 
行 ，Android 生 态 系统 正在 逐步 完善 ， 前 景 一 片 光明 。 


6. 阵营 良 著 不 齐 


开源 是 一 把 “ 双 刃 剑 ”， 它 帝 来 的 一 个 突出 问题 就 是 阵营 混乱 。 和 
一 些 操 作 系 统 需要 收取 高 额 的 加 盟 费 用 不 同 ，Android 的 免费 开源 大 大 
降低 了 开发 商 的 准 入 门槛 。 因 此 ， 出 现 了 “人 人 都 可 以 做 手机 ”的 局 
面 。 无 论 是 资本 、 研 发 实力 奴 厚 的 大 型 企业 ， 还 是 初出 茅 庐 没有 太 多 经 
验 的 小 公司 ， 都 在 不 断 进 入 这 个 生态 圈 。 这 既是 Android 系 统 的 优势 ， 


同时 也 是 隐患 。 


因为 每 个 厂商 都 可 以 根据 自己 的 需求 来 改造 原生 态 系 统 ， 从 而 难免 
造成 整个 Android 阵 营 的 分 裂 ; 而 且 ， 有 的 开发 商 也 在 努力 基于 Android 
建立 自己 的 生态 系统 。 这 无 疑 会 对 Android 的 整体 发 展 产生 一 定 的 影 
响 。 如 果 这 些 状 况 在 今后 一 段 时 间 里 无 法 得 到 解决 ， 那 么 很 可 能 阻 渍 
Android 的 进一步 发 展 壮 大 。 


T. 系统 运行 速度 有 待 改 善 


使 用 过 Android 相 关 产 品 的 用 户 一 定 有 这 样 的 体验 ， 那 就 是 开机 
慢 。 一 个 针对 目前 市 面 上 主流 Android 设 备 的 不 完全 统计 显示 ，Android 
产品 的 平均 开机 时 间 超 过 了 1 分 钟 ， 有 的 甚至 达到 5 分 钟 以 上 。 对 于 某 些 
需要 快速 实时 响应 的 电子 设备 而 言 〈 比 如 车 载 电 子 导航 一 体 机 ， 往 往 需 
要 在 汽车 启动 后 非常 短 的 时 间 内 完成 操作 系统 开机 ， 以 显示 倒车 影 
像 〉， 这 样 的 “ 包 速 ”显然 是 很 难 让 人 接受 的 。 


值得 欣慰 的 是 ，Google 也 正 致 力 于 运行 速度 的 改进 。 随 着 新 版 本 的 
人 
效 。 


8. 兼容 性 问题 


对 于 Android 平 台 的 应 用 开发 者 而 言 ， 最 头疼 的 恐怕 并 不 是 某 项 创 
新 功能 的 研发 ， 而 是 对 市 面 上 多 种 设备 的 适 配 。 在 这 方面 ，i0S 的 开发 
人 员 有 绝对 的 优势 ， 因 为 他 们 面 对 的 往往 只 是 一 款 机 器 〈 如 iPhone6、 
iPhone7) ， 而 且 屏 幕 尺 寸 、 分 辩 率 等 系统 属性 也 都 是 固定 已 知 的 ， 如 
图 1-7 所 示 。 


Android 系 统 由 于 开源 、 生 产 商 众多 ， 致 使 产品 形态 五 花 八 门 。 以 
手机 为 例 ， 为 消费 者 所 熟识 的 全 球 大 型 Android 手 机 开发 商 就 已 经 超过 
了 20 个 。 而 这 些 厂商 还 有 各 自 不 同 的 产品 型 号 一 一 这 也 就 意味 着 屏幕 大 
小 、 分 辩 率 等 各 种 硬件 参数 的 差异 。 按 照 目 前 行业 的 普遍 经 验 ， 开 发 一 
款 成 熟 的 Android 手 机 应 用 软件 ， 需 要 适 配 200 款 以 上 不 同 厂商 的 手机 ， 
以 保证 软件 发 布 后 不 至 于 出 现 大 规模 的 用 户 投 诉 。 如 果 是 面向 海外 市 
场 ， 则 需要 兼容 的 终端 产品 数量 可 能 还 会 更 多 。 





Device model 
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全 图 1-7 OpenSignalMaps 对 市 面 上 主流 Android 手 机 品牌 的 跟踪 结果 
虽然 Android 针 对 这 一 问题 有 一 定 的 解决 方法 “ 详 见 本 书 应 用 原理 


er ， 但 以 实际 开发 经 验 来 看 ， 暂 时 还 没有 很 好 地 解决 难题 
方法 。 


1.3 ”Android 系 统 框架 
Android 系 统 框架 如 图 1-8 所 示 。 
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全 图 1-8 Android 系 统 5 层 框 架 图 
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9 注意 


引用 自 2008 年 的 Google 1/0 大 会 《Anatomy & Physiology of 
an Android》 主 题 演讲 ， 作 者 Patrick Brady. 


前 面 说 过 ，Android 系 统 是 由 众多 子 项 目 组 成 的 。 从 编程 语言 的 角 
度 来 看 ， 这 些 项 目 主要 是 使 用 Java 和 C/C++ 来 实现 的 ; 从 整体 系统 框架 
而 言 ， 分 成 内 核 层 、 硬 件 抽象 层 、 系 统 运 行 库 层 、 应 用 程序 框架 层 以 及 
应 用 程序 层 。 本 书 的 一 个 主要 宗旨 是 希望 读者 可 以 由 浅 入 深 地 逐步 理解 
Android 系 统 的 方方面面 。 因 而 在 每 章节 内 容 的 编排 上 ， 我 们 采用 了 由 
整体 到 局 部 的 线索 来 铺展 开 一 一 先 让 读者 有 一 个 直观 感性 的 认识 ， 明 
白 “ 是 什么 ”“ 有 什么 用 ”， 然 后 才 剖 析 “ 如 何 做 到 的 ”。 这 样 做 的 一 
个 好 处 是 读者 在 学 习 的 过 程 中 不 容易 产生 困惑 。 否 则 如 果 直接 切入 原 
理 ， 长 篇 大 论 地 分 析 代 码 ， 仅 一 大 堆 函 数 调用 就 可 能 让 人 失去 学 习 的 方 
向 。 这 样 的 结果 往往 是 读者 花 了 非常 多 的 时 间 来 理 清 函数 关系 ， 但 始终 
A EE A E E 
理解 。 


本 书 希望 可 以 从 更 高 的 层次 ， 即 抽象 的 、 反 映 代码 设计 思想 和 设计 
者 初衷 的 角度 去 理解 系统 。 而 在 思考 的 过 程 中 ， 大 部 分 情况 下 我 们 都 将 
从 读者 容易 理解 的 基础 开始 讲 起 。 就 好 比 画 一 张 素描 ， 先 给 出 一 张 白 
纸 ， 勾 勒 出 整体 的 框架 ， 然 后 针对 重点 部 位 细 细 加 工 ， 最 后 才能 还 原 出 
完整 的 画面 。 另 外 ， 本 书 在 对 系统 原理 本 身 进行 讲解 的 同时 ， 也 最 大 程 
度 地 结合 工程 项 目 中 可 能 遇 到 的 问题 ， 理 论 联 系 实际 地 进行 解析 。 和 希望 
这 样 的 方式 既 能 让 读者 真正 学 习 到 Android 系 统 的 设计 思想 ， 也 能 学 有 
所 用 ， 增 加 一 些 实际 的 项 目 开发 经 验 和 技巧 。 


接 下 来 的 内 容 将 对 Android 系 统 的 5 层 框架 做 一 个 简单 描述 。 
。 内 核 层 


Android 的 底层 是 基于 Linux 操 作 系 统 的 。 从 严格 意义 上 来 讲 ， 它 属 
于 Linux 操 作 系 统 的 一 个 变种 。Android 选 择 在 Linux 内 核 的 基础 上 来 搭 


建 自己 的 运行 平台 有 几 个 好 处 。 


首先 ， 避 开 了 与 硬件 直接 打交道 。Li nux 经 过 多 年 的 发 展 ， 这 方面 
工作 正 是 它 的 强项 ， 其 表现 可 以 说 相当 优秀 。 更 为 难能可贵 的 是 ， 
Li a ER 所 以 Android 系 统 没 有 必要 花费 额外 的 时 间 去 做 
重复 工作 。 


其 次 ， 基 于 Linux 系 统 的 驱动 开发 可 扩展 性 很 强 。 这 对 于 府 入 式 系 
统 而 言 非常 重要 ， 因 为 每 款 产 品 在 硬件 上 或 多 或 少 都 会 有 差异 ， 如 果 驱 
动 开 发 不 能 做 到 高 度 可 扩展 和 易 用 性 ， 那 么 Android 系 统 的 移植 工作 将 
ec Ibis hy He. 


值得 一 提 的 是 ，Android 的 工程 项 目 中 并 没有 包括 内 核 源 码 一 一 内 
核 源码 的 具体 下 载 方式 可 以 参见 下 一 章节 。 


。 硬件 抽象 层 


大 家 可 能 都 有 这 样 的 疑问 ， 既 然 Linux 内 核 是 专职 与 硬件 打交道 
的 ， 为 什么 又 杀 出 个 “ 程 咬 金 ”硬件 抽象 层 (HAL) We? 没 错 ， 这 
个 “人 物 ” 一 开始 并 没有 出 现在 Android 的 “剧本 ”中 ， 其 出 场 是 有 一 
定 历史 原因 的 。 


HAL 的 第 一 次 亮相 要 追溯 到 2008 年 的 Google 1/0 大 会 上 。 当 时 
Google 员 工 Patrick Brady 发 表 了 一 篇 名 为 《Anatomy & Physiology of 
an Android) 的 演讲 ， 并 在 其 中 提出 了 带 HAL 的 Android 新 架构 。 根 据 这 
份 文档 的 描述 ，HAL 是 : 


(1) User space C/C++ library layer; 


(2) Defines the interface that Android requires hardware 
“drivers” to implement; 


(3) Separates the Android platform logic from the 
hardware interface. 


也 就 是 说 ， 它 希望 通过 定义 硬件 “驱动 ”的 接口 来 进一步 降低 
Android 系 统 与 硬件 的 耦合 度 。 另 外 ， 由 于 Linux 遵 循 的 是 GPL 协议 GÈ 
意 ，Android 开 源 项 目 基 于 Apache 协 议 ) ， 意 味 着 其 下 的 所 有 驱动 都 应 


该 是 开源 的 一 一 这 点 对 于 部 分 厂商 来 说 是 无 法 接受 的 。 因 而 ，Android 
提供 了 一 种 “ 打 擦 边 球 ” 的 做 法 来 规避 这 类 问题 。 我 们 会 在 后 续 章 节 中 
继续 讲解 关于 HAL 的 更 多 知识 。 


。 系统 运行 库 层 
这 一 层 


中 包含 了 支撑 整个 系统 正常 运行 的 基础 库 。 由 于 这 些 库 多 数 
由 C/C++ 实现 ， 因 此 也 被 一 些 开 发 人 员 称 为 “C6 库 层 ”， 以 区 别 于 应 用 程 
序 框 染 层 。Android 中 很 多 系统 运行 库 实 际 上 都 是 成 熟 的 开源 项 目 ， 如 
WebKit、0penGL、SQLite 等 。 我 们 并 不 要 求 读 者 去 理解 所 有 库 的 内 部 原 
理 ， 这 样 做 不 现实 。 重 点 在 于 Android 系 统 是 如 何 有 机 地 与 这 些 库 建立 
联系 ， 从 而 保证 整个 设备 的 稳定 运作 的 。 


。 应 用 程序 框架 层 


与 系统 运行 库 被 称 为 “0 库 层 ” 相 对 应 ， 应 用 程序 框架 层 往往 被 冠 
以 “Java 库 ”的 称号 。 这 是 因为 框架 层 所 提供 的 组 件 一 般 都 用 Java 语 言 
编写 而 成 ， 它 们 一 方面 为 上 层 应 用 程序 提供 了 AP1 接 口 ， 另 一 方面 也 可 
锋 了 不 少 系统 级 服务 进程 的 实现 ， 是 与 droid 应 用 程序 开发 者 关系 最 
直接 的 一 层 。 


。 应 用 程序 层 


和 
开发 。 


对 于 一 名 出 色 的 应 用 程序 员 而 言 ， 不 仅 要 了 解 该 使 用 哪些 系统 AP | 
接口 去 完成 一 个 功能 ， 还 要 尽 可 能 了 解 这 些 接口 及 其 下 的 系统 底层 框 染 
是 如 何 实现 的 。 虽 然 理解 系统 运行 原理 对 于 应 用 开发 者 来 说 并 不 是 必需 
的 ， 但 在 很 多 情况 下 却 可 以 极 大 地 提高 程序 员 分 析 问 题 的 能 力 ， 也 可 在 
产品 性 能 优化 方面 产生 积极 的 作用 。 


` * + 
Android 源 码 下 载 及 编译 


在 分 析 Android 源 码 前 ， 首 先 要 学 会 如 何 下 载 和 编译 系统 。 本 章 将 
向 读者 完整 地 呈现 Android 源 码 的 下 载 流程 、 常 见 问题 以 及 处理 方法 ， 
并 从 开发 者 的 角度 来 理解 如 何 正确 地 编译 出 Android 系 统 〈 包 括 原生 态 
系统 和 定制 设备 ) 。 


后 面 ， 我 们 将 在 此 基础 上 深入 到 编译 脚本 的 分 析 中 ， 以 “让 丁 解 
牛 ” 的 方式 来 还 原 一 个 庞大 而 严谨 的 Android 编 译 系 统 。 


2.1 Android 源 码 下 载 指 南 
2.1.1 基于 Repo 和 Git 的 版 本 管理 


Git 是 一 种 分 布 式 的 版 本 管理 系统 ， 最 初 被 设计 用 于 Linux 内 核 的 版 
本 控制 。 本 书 工具 篇 中 对 6Git 的 使 用 方法 、 原 理 框 架 有 比较 详细 的 剂 
析 ， 建 议 读者 先 到 相关 章节 阅读 了 解 。 


Git 的 功能 非常 强大 ， 速 度 也 很 快 ， 是 当前 很 多 开源 项 目的 首选 工 
具 。 不 过 Git 也 存在 一 定 的 缺点 ， 如 相对 于 图 形 珊 面 化 的 工具 没 那么 容 
人 ee 
传 等 。 


为 此 ，Google 提 供 了 一 个 专门 用 于 下 载 Android 系 统 源 码 的 Python 
脚本 ， 即 Repo。 


在 Repo 环 境 下 ， 版 本 修改 与 提交 流程 是 : 
。 用 Repo 创 建新 的 分 支 ， 通 常情 况 下 不 建议 在 mastet 分 支 上 操作 ; 
。 开发 者 根据 需求 对 项 目 文件 进行 修改 ; 
。 利用 git add 命 令 将 所 做 修改 进行 暂 存 ; 
。 利用 git commit 命 令 将 修改 提交 到 仓库 ; 
。 利用 tepo upload 命 令 将 修改 提交 到 代码 服务 器 上 。 


由 此 可 见 ，Repo 与 我 们 在 工具 篇 中 讨论 的 Git 流 程 上 有 些许 不 同 ， 差 
异 主要 体现 在 与 远程 服务 仓库 的 交互 上 ; 而 本 地 的 开发 仍然 是 以 原生 的 
Git 命 令 为 主 。 下 面 我 们 讲解 Repo 的 一 些 常用 命令 ， 读 者 也 可 以 拿 它 和 
Git 进 行 仔 细 比 较 。 
1. 同步 

同步 操作 可 以 让 本 地 代码 与 远程 仓库 保持 一 致 。 它 有 两 种 形式 。 

如 果 是 同步 当前 所 有 的 项 目 : 


$ repo sync 


或 者 也 可 以 指定 需要 同步 的 茶 个 项 目 : 
$ repo Sync [PROJECT1] [PROJECT2]... 
2. 分 支 操作 

创建 一 个 分 支 所 需 的 命令 : 
$ repo start <BRANCH_NAME> 

也 可 以 查看 当前 有 多 少 分 支 : 

$ repo branches 

或 者 : 
$ git branch 

以 及 切换 到 指定 分 支 : 
$ git checkout <BRANCH_NAME> 


3. 查询 操作 


查询 当前 状态 : 
$ repo status 
查询 未 提交 的 修改 : 
$ repo diff 
4. 版 本 管理 操作 
暂 存 文件 ， 
$git add 
提交 文件 : 


$git commit 


如 果 是 提交 修改 到 服务 器 上 ， 首 先 需 要 同步 一 下 : 
$repo sync 


然后 执行 上 传 指令 : 


$repo upload 


2.1.2 Android 源 码 下 载 流程 


了 解 了 Repo 的 一 些 常 规 操 作 后 ， 这 一 小 节 接 着 分 析 Android 源 码 下 
载 的 全 过 程 。 这 既是 剖析 Android 系 统 原理 的 前 提 ， 也 是 让 很 多 新 手感 
到 困惑 的 地 方 一 一 源码 下 载 可 以 作为 初学 者 了 解 Android 系 统 的 “Hello 
World” o 


值得 一 提 的 是 ，Androi d 官 方 建议 我 们 务必 确保 编译 系统 环境 符合 
以 下 几 点 要 求 : 


e Linux 或 者 Mac 系 统 


在 虚拟 机 上 或 是 其 他 不 支持 的 系统 〈 例 如 Windows) 上 编译 Android 
系统 也 是 可 能 的 ， 事 实 上 6oog1e 鼓 励 大 家 去 尝试 不 同 的 操作 系统 平台 。 
不 过 Goog le 内 部 针对 Android 系 统 的 编译 和 测试 工作 大 多 是 在 Ubuntu 
LTS (14. 04) 上 进行 的 。 因 而 建议 开发 人 员 也 都 选择 同样 的 操作 系统 版 本 
来 开展 工作 ， 经 验 告诉 我 们 这 样 可 以 少 走 很 多 弯路 。 


如 果 是 在 虚拟 机 上 运行 的 Linux 系 统 ， 那 么 理论 上 至 少 需要 16GB 的 
RAM/Swap 才 有 可 能 完成 整个 Android 系 统 的 编译 。 


对 于 Gingerbread(2.3.X) 及 以 上 的 版 本 ，64 位 的 开发 环境 是 必需 的 。 
其 他 旧 的 Android 系 统 版 本 可 以 采用 32 位 的 开发 环境 。 

需要 至 少 100GB 以 上 的 磁盘 空间 才能 完成 系统 的 一 系列 编译 过 程 
一 一 仅 源码 大 小 就 已 经 将 近 10GB 了 。 

Python 2.6-2.7， 开 发 人 员 可 以 从 Python 官网 上 下 载 : 
www.python.org. 

GNU Make 3.81-3.82， 开 发 人 员 可 以 从 Gnu 官 网 上 下 载 : 


Www.ghu.orgo 


。 如 果 是 编译 最 新 版 本 的 Andtoid NAA, Ab A F BJava8(Open]DK). 
后 续 编 译 章节 我 们 还 会 专门 介绍 。 
e Git1.7 以 上 版 本 ， 开 发 人 员 可 以 从 Git 官 网 上 下 载 : http://git- 


Scm.COM o 


要 特别 提醒 大 家 的 是 ， 以 下 所 有 步骤 都 是 在 Ubuntu 操作 系统 中 完成 
的 〈《“#” 号 后 面 表示 注释 内 容 ) 。 


ile 下 载 Repo 


$ cd ~ # 进 入 home 目 录 

$ mkdir bin # 创 建 bin 目 录用 于 存放 Repo 脚 本 

$ PATH=~/bin:$PATH # 将 bin 目 录 加 入 系统 路 径 中 

$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~ 
# 是 一 个 基于 命令 行 的 文件 传输 工具 ， 它 文 持 非常 多 的 协议 。 这 里 我 们 利用 cur1 来 将 rep: 
$ chmod a+x ~/bin/repo 


注 : 网 上 有 很 多 开发 者 《中国 大 陆地 区 ) 反映 上 面 的 地 址 经 常 无 法 
成 功 访问 。 如 果 读 者 也 有 类 似 困扰 ， 可 以 试 试 下 面 这 个 : 


$curl http://android.googlesource.com/repo > ~/bin/repo 


另外 ， 国 内 不 少 组 织 〈 特 别 是 教育 机 构 ) 也 对 Android 做 了 镜像 ， 
如 清华 大 学 提供 的 开源 项 目 (TUNA) 的 mi rror 地 址 如 下 : 


https://aosp.tuna.tsinghua.edu.cn/ 


下 面 是 TUNA 官 方 对 Android 代 码 库 的 使 用 帮助 节选 : 


Android 镜 像 使 用 帮助 

参考 Go0gle 教 程 https://source.android.com/source/downloading.html, +} 
本 站 资源 有 限 ， 每 个 TP 限制 并 发 数 为 4， 请 勿 使 用 repo sync-j8 这 样 的 方式 同步 。 
替换 已 有 的 AOSP 源 代码 的 remote。 

如 果 你 之 前 已 经 通过 某 种 途径 获得 了 AOSP 的 源码 〈 或 者 你 只 是 init 这 一 步 完 成 后 ) ， 你 : 























<manifest> 
<remote name="aosp" 
- fetch="https://android.googlesource.com" 
十 fetch="git://aosp.tuna.tsinghua.edu.cn/android/" 
review="android-review.googlesource.com" /> 
<remote name="github" 
这 个 方法 也 可 以 用 来 在 同步 cyanogenmod 代 码 的 时 候 从 TUNA 同 步 部 分 代码 





下 载 repo 后 ， 最 好 进行 一 下 校 验 ， 各 版 本 的 校 验 码 如 下 所 示 : 


对 于 版 本 1.17, SHA-1 checksum 是 : ddd79b6d5a7807e911b524cb223bc3544 
对 于 版 本 1.19, SHA-1 checksum 是 : 92cbad8c880f697b58ed83e348d06619f 
对 于 版 本 1.20, SHA-1 checksum Æ: e197cb48ff4ddda4d11f23940d316e32 
对 于 版 本 1.21, SHA-1 checksum Æ: b8bd1804f432ecf1bab730949c82b93b 


2. Repo 配 置 
在 开始 下 载 源码 前 ， 需 要 对 Repo 进 行 必要 的 配置 。 
如 下 所 示 : 


$ mkdir source # 用 于 存放 整个 项 目 源码 

$ cd source 

$ repo init -u https://android.googlesource.com/platform/manifest 
HHHHNHHNHNHHH## 以 下 为 注释 部 分 #HNHHH#H# 

init 命 令 用 于 初始 化 repo 并 得 到 近期 的 版 本 更 新 信息 。 如 果 你 想 获 取 某 个 非 master 分 去 
$ repo init -u https://android.googlesource.com/platform/manifest 
完成 配置 后 ，repo 会 有 如 下 提示 : 

repo initialized in /home/android 

这 时 在 你 的 机 器 home 目 录 下 会 有 一 个 ,repo 目 录 ， 用 于 记录 manifest 等 信息 #HHHHHH# 
HHAHHH 


3. 下 载 源码 


完成 初始 化 动作 后 ， 束 可 以 开始 下 载 源码 了 。 根 据 上 一 步 的 配置 ， 
下 载 到 的 可 能 是 最 新 版 本 或 者 东 分 支 版 本 的 系统 源码 。 


$ repo sync 


由 于 整个 Android 源 码 项 目 非 常 大 ， 再 加 上 网 络 等 不 确定 因素 ， 运 
气 好 的 话 可 能 1 一 2 个 小 时 就 能 品尝 到 “Android 盛 刘 ”; 运气 不 好 的 
话 ， 估 计 一 个 礼拜 也 未 必 能 完成 这 一 步 一 一 如 果 下 载 一 直 失 败 的 话 ， 读 
者 也 可 以 党 试 到 网 上 搜索 别人 已 经 下 载 完成 的 源码 包 ， 因 为 通常 在 新 版 
本 发 布 后 的 第 一 时 间 就 有 热心 人 把 它 上 传 到 网 上 了 。 


可 以 看 到 在 Repo 的 帮助 下 ， 整 个 下 载 过 程 还 是 相当 简单 直观 的 。 
提示 : 如 果 你 在 下 载 过 程 中 出 现 暂时 性 的 问题 (如 下 载 意外 中 


断 ) ， 可 以 多 试 几 次 。 如 果 一 直 存 在 问题 ， 则 很 可 能 是 代理 、 网 关 等 原 
因 造 成 的 。 更 多 常见 问题 的 描述 与 解决 万 法 ， 可 以 参见 下 面 这 个 网 址 。 


http://source.android.com/source/known-issues. html 
典型 的 repo 下 载 再 面 如 图 2-1 所 示 。 


android-cts-4.4 r1 -> android-cts-4.4 r1 
android-cts-5.1_r1 -> android-cts-5.1_r1 
android-cts-verifier-4.0.3 r1 -> android-cts-verifier-4.0.3 r1 
android-cts-verifier-4.0 r1 -> android-cts-verifier-4.0 r1 
android-l-preview_r2 -> android-l-preview_r2 
android-sdk-4.0.3-tools_ri -> android-sdk-4.0.3-tools_r1 
android-sdk-4.0.3 ri -> android-sdk-4.0.3 r1 
android-sdk-4.4.2_r1 -> android-sdk-4.4.2_r1 
android-sdk-4.4.2_r1.0.1 -> android-sdk-4.4.2 11.0.1 
android-sdk-adt_r16.0.1 -> android-sdk-adt_r16.0.1 
android-sdk-adt_r20 -> android-sdk-adt_r20 
android-sdk-support_r11 -> android-sdk-support_ri1 
[new android-wear-5.0.0_r1 -> android-wear-5.0.0 r1 

etching project device/samsung/manta 

% Total % Received % Xferd Average Speed Time Time Time Current 

Dload Upload Total Spent Left Speed 
100 1 100 1 0 0 1 © 6:00:01 --:--:-- 6:06:61 19-k - -- t--: 
49 428M © 134990M 212 0M 159 3k 0 0 0 0 25319k0k 00 
0 34954 Sk 42 8M 0 4 09 21354M1k 0 0 1 :076 :2 8 256:09k@: 16 
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全 图 2-1 原生 Android 工 程 的 典型 下 载 界 面 


Android 系 统 本 身 是 由 非常 多 的 子 项 目 组 成 的 ， 这 也 是 为 什么 我 们 
需要 repo 来 统一 管理 A0SP 源 码 的 一 个 重要 原因 ， 如 图 2-2 所 示 “部 


at) a 


platform/external/alsa-lib 
platform/external/android-clat 
platform/external/android-cmake 
platform/external/android-mock 
platform/external/androidplot 

platform/external/angle 
platform/external/AntennaPod/afollestad b/27076782 
platform/external/AntennaPod/AntennaPod b/27076782 
platform/external/AntennaPod/AudioPlayer b/27076782 
platform/external/ant-glob 


全 图 2-2 FRA 


另外 ， 不 同 子 项 目 之 间 的 branches 和 tags 的 区 别 如 图 2-3 所 示 。 


Branches 

master 

donut-release 
donut-release2 
eclair-passion-release 
eclair-release 
eclair-sholes-release 
eclair-sholes-release2 
froyo 

froyo-release 


gingerbread 
More... 


Tags 
android-n-preview-2 
android-6.0.1_ r31 
android-6.0.1 r30 
android-cts-5.0 r5 
android-cts-5.1 r6 
android-cts-6.0 r5 
android-6.0.1 r24 


Branches 
master 
brillo-m10-dev 


brillo-m10-release 


brillo-m7-dev 
brillo-m7-mr-dev 
brillo-m7-release 
brillo-m8-dev 
brillo-m8-release 
brillo-m9-dev 
brillo-m9-release 
More... 


Tags 


android-n-preview-2 


android-6.0.1 r31 
android-6.0.1 r30 


radle 2.0.0 
studio-2.0 


android-cts-5.0 r5 
android-cts-5.1 r6 


Branches 

master 

gingerbread 
gingerbread-mr4-release 
gingerbread-release 
ics-factoryrom-2-release 
ics-mro 

ics-mr0-release 
ics-mr1 

ics-mri-release 
ics-plus-aosp 

More... 


Tags 
android-n-preview-2 
android-6.0.1 r31 
android-6.0.1 r30 
android-cts-5.0 r5 
android-cts-5.1_ r6 
android-cts-6.0 r5 
android-6.0.1 r24 


全 图 2-3 Android 各 子 项 目的 分 支 和 标签 
(Æ: framewortks/base， 中 : frameworks/native， 右 : /platform/libcore) 


当 我 们 使 用 repo init 命 令 初 始 化 A0SP 工 程 时 ， 会 在 当前 目录 下 生 
成 一 个 repo 文 件 夹 ， 如 图 2-4 所 示 。 


manifests 


Ko 


manifest.xml 


manifests.git 


repo 


全 图 2-4 repo 文 件 


其 中 manifests 本 身 也 是 一 个 Git 项 目 ， 它 提供 的 唯一 文件 名 为 
default. xm| ， 用 于 管理 A0SP 中 的 所 有 子 项 目 〈 每 个 子 项 目 都 由 一 
project 标 签 表示 ) : 


<project path="art" name="platform/art" groups="pdk" /> 

<project path="bionic" name="platform/bionic" groups="pdk" /> 

<project path="bootable/recovery" name="platform/bootable/recovery" groups="pdk" /> 
<project path="cts" name="platform/cts" groups="cts,pdk-cw-fs,pdk-fs" /> 


Fb, default. xm1 中 记录 了 我 们 在 初始 化 时 通 选项 指定 的 分 
支 版 本 ， 例 如 “android-n-preview-2” 


<default revision="refs/tags/android-n-preview-2" 
remote="aosp" 
sync- j="4" />| 


这 样 当 执行 repo sync 命 令 时 ， 系 统 就 可 以 根据 我 们 的 要 求 去 获取 
正确 的 源码 版 本 了 。 


友情 提示 : 经 常 有 读者 询问 阅读 Android 源 码 可 以 使 用 哪些 工具 。 
除了 著名 的 Source Insight 外 ， 另 外 还 有 一 个 名 为 SlickEdit 的 1DE 也 是 
相当 不 错 的 (支持 Windows、Linux 和 Mac) ， 建 议 大 家 可 以 对 比 选择 最 
适合 自己 的 工具 。 


2.2 原生 Android 系 统 编译 指南 


任何 一 个 项 目 在 编译 前 ， 都 首先 需要 搭建 一 个 完整 的 编译 环境 。 
Android 系 统 通常 是 运行 于 类 似 Arm 这 样 的 区 入 式 平台 上 ， 所 以 很 可 能 涉 
及 交叉 编译 。 


什么 是 交叉 编译 呢 ? 


简单 来 说 ， 如 果 目 标 平台 没有 办 法 安 效 编译 器 ， 或 者 由 于 资源 有 限 
等 无 法 完成 正常 的 编译 过 程 ， 那 就 需要 另 一 个 平台 来 辅助 生成 可 执行 文 
件 。 如 很 多 情况 下 我 们 是 在 PC 平台 上 进行 Android 系 统 的 研发 工作 ， 这 
时 就 需要 通过 交叉 编译 器 来 生成 可 运行 于 Arm 平 台 上 的 系统 包 。 需 要 特 
别提 出 的 是 ，“ 平 台 ” 这 个 概念 是 指 硬件 平台 和 操作 系统 环境 的 综合 。 


交叉 编译 主要 包含 以 下 几 个 对 象 。 


TSE (Host) : 指 的 是 我 们 开发 和 编译 代码 所 在 的 平台 。 目 前 不 
ae 的 PC， 操 作 系统 环境 以 Windows 和 
Linux 为 主 。 


目标 机 (Target) : 相对 于 宿主 机 的 就 是 目标 机 。 这 是 编译 生成 的 
系统 包 的 目标 平台 。 


交叉 编译 器 (Cross Compiler) : 本 身 运行 于 宿主 机 上 ， 用 于 产生 
目标 机 可 执行 文件 的 编译 器 。 


针对 具体 的 项 目 需求 ， 可 以 自行 配置 不 同 的 交叉 编译 器 。 不 过 我 们 
建议 开发 者 尽 可 能 直接 采用 国际 权威 组 织 推荐 的 经 典 交叉 编译 器 。 因 为 
它们 在 release 之 前 就 已 经 在 多 个 项 目 上 测试 过 ， 可 以 为 接 下 来 的 产品 
开发 节约 宝贵 的 时 间 。 表 2-1 所 示 给 出 了 一 些 常见 的 交叉 编译 器 及 它们 
的 应 用 环境 。 


表 2-1 常用 交叉 编译 器 及 应 用 环境 





Bi 人 ADS 开 发 环境 [A | 
pvt seconds Cygwin 开 发 环境 fm | 





2.2.1 建立 编译 环境 

本 书 所 采用 的 宿主 机 是 X86PC (Linux) ， 通 过 表 2-1 可 知 在 编译 过 
程 中 需要 用 到 arm-1inux-gcc 交 叉 编 译 器 GE: Android 系 统 工程 中 自 带 
了 交叉 编译 工具 ， 只 要 在 编译 时 做 好 相应 的 配置 即 可 ) 。 

接 下 来 我 们 分 步骤 来 搭建 完整 的 编译 环境 ， 并 完成 必要 的 配置 。 所 
选取 的 宿主 机 操作 系统 是 Ubuntu 的 14. 04 版 本 LTS (这 也 是 Android 官 方 
推荐 的 ) 。 为 了 不 至 于 在 编译 过 程 中 出 现 各 种 意 想 不 到 的 问题 ， 建 议 大 
家 也 采用 同样 的 操作 系统 环境 来 执行 编译 过 程 。 

Step1， 通 用 工具 的 安装 

表 2-2 给 出 了 所 有 需要 安装 的 通用 工具 及 它们 的 下 载 地 址 。 


表 2-2 通用 编译 工具 的 安装 及 下 载 地 址 


最 新 的 Android 工 程 已 经 改 用 OpenJDK， 并 要 
求 为 Java 87 及 以 上 版 本 。 这 点 大 家 应 该 特别 
注意 ， 人 否则 可 能 在 编译 过 程 中 遇 到 各 种 问题 。 
具体 安装 方式 见 下 面 的 描述 











Gingerbread 
JDKI 到 Kitkat 之 


| 间 的 版 本 ttp:/java.sun.com/javase/downloads/ 





Git 1.7 以 上 版 本 jlhttp://git-scm.com/download 


对 于 开发 人 员 来 说 ， 他 们 习惯 于 通过 以 下 方法 安装 JDK〈 如 果 处 于 
Ubuntu 系统 下 ) : 





Java 6: 


$ sudo add-apt-repository "deb http://archive.canonical.com/ luci 
$ sudo apt-get update 
$ sudo apt-get install sun-java6-jdk 


Java 5: 


$ sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu h 
$sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu ha 
multiverse" 

$ sudo apt-get update 

$ sudo apt-get install sun-java5-jdk 


但 是 随 着 Java 的 版 本 变迁 及 Sun (已 被 0racle 收 购 ) 公司 态度 的 转 
变 ， 目 前 获取 Java 的 方式 也 发 生 了 很 大 变化 。 基 于 版 权 方 面 的 考虑 (A 
家 应 该 已 经 听 说 了 0racle 和 Google 之 间 的 官司 恩怨 ) ，Android 系 统 已 
经 将 Java 环 境 切 换 到 了 0penJDK， 安 装 步 骤 如 下 所 示 : 


$ sudo apt-get update 
$ sudo apt-get install openjdk-8-jdk 


首先 通过 上 述 命令 install OpenJDK 8， 成 功 后 再 进行 如 下 配置 : 


$ sudo update-alternatives --config java 
$ sudo update-alternatives --config javac 


如 果 出 现 Java 版 本 错误 的 问题 ，make 系 统 会 有 如 下 提示 : 
类 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 炎炎 火炎 火炎 火炎 炎炎 炎炎 炎炎 类 


You are attempting to build with the incorrect version 


of java. 


Your version is: WRONG_VERSION. 
The correct version is: RIGHT_VERSION. 


Please follow the machine setup instructions at 
https://source.android.com/source/download. html 


Step2. Ubuntu 下 特定 工具 的 安装 
注意 ， 这 一 步 中 质 述 的 安装 过 程 是 针对 Ubuntu 而 言 的 。 如 果 你 是 在 
其 他 操作 系统 下 执行 的 编译 ， 请 参阅 官方 文档 进行 正确 配置 ; 如果 你 是 
在 虚拟 机 上 运行 的 Ubuntu 系 统 ， 那 么 请 至 少 保留 166B 的 RAM/SWAP 和 
100GB 以 上 的 磁盘 空间 ， 这 是 完成 编译 的 基本 要 求 。 
e Ubuntu 14.04 


$ sudo apt-get install bison g++-multilib git gperf libxm1l2-u 
dev:1386 zip 


e Ubuntu 12.04 


所 需 的 命令 如 下 : 


$ sudo apt-get install git gnupg flex bison gperf build-essen 
Zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev \ 
libxii-dev:i386 libreadline6-dev:i386 libgl1i-mesa-glx:i386 \ 
libgli-mesa-dev g++-multilib mingw32 tofrodos \ 
python-markdown libxml2-utils xsltproc zlibig-dev:i386 

$ sudo 1n -s /usr/1ib/i386-linux-gnu/mesa/1libGL.so.1 /usr/1lib/1i38 


e Ubuntu 10.04 - 11.10 


需要 安 效 的 程序 比较 多 ， 不 过 我 们 还 是 可 以 通过 apt-get 来 轻松 完 
成 。 


具体 命令 如 下 : 


$ sudo apt-get install git-core gnupg flex bison gperf build-esse 
Zip curl zlibig-dev libc6-dev lib32ncurses5-dev 1a32-libs \ 
x1i1proto-core-dev libx11-dev 1ib32readline5-dev 1ib32z-dev \ 


libgli-mesa-dev gt++-multilib mingw32 tofrodos python-markdown \ 
libxml2-utils xsltproc 


注意 ， 如 果 以 上 命令 中 存在 某 些 包 找 不 到 的 情况 ， 可 以 试 试 以 下 命 
a 
Z o: 
$ sudo apt-get install git-core gnupg flex bison gperf libsdl-dev 
如 果 你 的 操作 系统 刚好 是 Ubuntu 10. 10， 那 么 还 需要 : 


$ sudo ln -s /usr/1ib32/mesa/1ibGL.so.1 /usr/1l1ib32/mesa/1libGL.so 


如 果 你 的 操作 系统 刚好 是 Ubuntu 11.10, MAMA: 


$ sudo apt-get install libx11-dev:i386 
Step3. iWilccache (可 选 ) 


如 果 你 经 常 执行 “make clean”， 或 者 需要 经 常 编译 不 同 的 产品 类 
别 ， 那 么 ccache 还 是 有 用 的 。 它 可 以 作为 编译 时 的 缓冲 ， 从 而 加 快 重新 
编译 的 速度 。 

首先 ， 需 要 在 . bashrc 中 加 入 如 下 命令 。 


export USE_CCACHE=1 


如 果 你 的 home 目 录 是 非 本 地 的 文件 系统 “如 NFS) ， 那 么 需要 特别 
指定 〈 默 认 情 况 下 它 存放 于 一 /. ccache) : 


export CCACHE_DIR=<path-to-your-cache-directory> 
在 源码 下 载 完 成 后 ， 必 须 在 源码 中 找到 如 下 路 径 并 执行 命令 : 


prebuilt/linux-x86/ccache/ccache -M 50G 
# 推 荐 的 值 为 59-1009GB， 你 可 以 根据 实际 情况 进行 设置 





Step4， 配 置 USB 访 问 权 限 


USB 的 访问 权限 在 我 们 对 实际 设备 进行 操作 时 是 必 不 可 少 的 《如 下 
载 系统 程序 包 到 设备 上 ) 。 在 Ubuntu 系统 中 ， 这 一 权限 通常 需要 特别 的 
配置 才能 获得 。 


可 以 通过 修改 /etc/udev/rules. d/51-android. rules 来 达到 目的 。 
例如 ， 在 这 个 文件 中 加 入 以 下 命令 内 容 : 


# adb protocol on passion (Nexus One) 

SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct }=="4e12" 
="<username>" 

# fastboot protocol on passion (Nexus One) 

SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct }=="0fff" 
="<username>" 

# adb protocol on crespo/crespo4g (Nexus S) 

SUBSYSTEM=="usb", ATTR{idVendor }=="18d1", ATTR{idProduct }=="4e22" 
="<username>" 

# fastboot protocol on crespo/crespo4g (Nexus S) 
SUBSYSTEM=="usb", ATTR{idVendor }=="18d1", ATTR{idProduct }=="4e20" 
="<username>" 

# adb protocol on stingray/wingray (Xoom) 

SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", ATTR{idProduct }=="70a9" 
="<username>" 

# fastboot protocol on stingray/wingray (Xoom) 

SUBSYSTEM=="usb", ATTR{idVendor }=="18d1", ATTR{idProduct }=="708c" 
="<username>" 

# adb protocol on maguro/toro (Galaxy Nexus) 

SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", ATTR{idProduct }=="6860" 
="<username>" 

# fastboot protocol on maguro/toro (Galaxy Nexus) 
SUBSYSTEM=="usb", ATTR{idVendor }=="18d1", ATTR{idProduct }=="4e30" 
="<username>" 

# adb protocol on panda (PandaBoard) 

SUBSYSTEM=="usb", ATTR{idVendor }=="0451", ATTR{idProduct }=="d101" 
="<username>" 

# fastboot protocol on panda (PandaBoard) 

SUBSYSTEM=="usb", ATTR{idVendor }=="0451", ATTR{idProduct }=="d022" 
="<username>" 

# usbboot protocol on panda (PandaBoard) 

SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct }=="doof" 
="<username>" 

# usbboot protocol on panda (PandaBoard ES) 

SUBSYSTEM=="usb", ATTR{idVendor }=="0451", ATTR{idProduct }=="d010" 
="<username>" 


如 果 严 格 按照 上 述 4 个 步骤 来 执行 ， 并 且 没 有 任何 错误 一 一 那么 共 
喜 你 ， 一 个 完整 的 Android 编 译 环境 已 经 搭建 完成 了 。 


2.2.2 编译 流程 


上 一 小 节 我 们 建立 了 完整 的 编译 环境 ， 可 谓 “ 万 事 俱 备 ， 只 欠 东 
风 ”， 现 在 就 可 以 执行 真正 的 编译 操作 了 。 


下 面 内 容 仍 然 采 用 分 步 的 形式 进行 讲解 。 

Step1. 执行 envsetup 脚 本 

脚本 文件 envsetup. sh 记录 着 编译 过 程 中 所 需 的 各 种 函数 实现 ， 如 
lunch、m、mm 等 。 你 可 以 根据 需求 进行 一 定 的 修改 ， 然 后 执行 以 下 命 


A. 
Zi 


$ source ./build/envsetup.sh 
也 可 以 用 点 号 代替 source: 

$ . ./build/envsetup.sh 
Step2， 选 择 编 译 目 标 


编译 目标 由 两 部 分 组 成 ， 即 BUILD 和 BUILDTYPE。 表 2-3 和 表 2-4 给 出 
了 详细 的 解释 。 


2= BUILD 人 参数 详解 


典 | 全 编译 ， 即 包括 所 有 的 语言 、 应 用 程序 
下 | 输入 法 等 


全 编译 ， 并 且 运 行 于 Galaxy Nexus 
iui magut = GSM/HSPA+ ("maguro") 
full_panda apis ta fs 并 且 运 行 于 PandaBoard ("panda") 





可 见 BUILD 可 用 于 描述 不 同 的 目标 设备 。 


表 2-4 ”BUILDTYPE 参 数 详 解 


编译 出 的 系统 有 一 定 的 权限 限制 ， 通 常用 来 发 布 
最 终 的 上 市 版 本 


编译 出 的 系统 拥有 root 权 限 ， 通 常用 于 调试 目的 


pe | 即 engineering 版 本 


可 见 BUILDTYPE 可 用 于 描述 各 种 不 同 的 编译 场景 。 
选择 不 同 的 编译 目标 ， 可 以 使 用 以 下 命令 : 


$ lunch BUILD-BUILDTYPE 





如 我 们 执行 命令 “lunch ful1-eng”， 就 相当 于 编译 生成 一 个 用 于 
工程 开发 目的 ， 且 运行 于 模拟 器 的 系统 。 


如 果 不 知 道 有 了 哪些 产品 类 型 可 选 ， 也 可 以 只 艇 入 “lunch” 命 令 ， 
这 时 会 有 一 个 列表 显示 出 当前 工程 中 已 经 配置 过 的 所 有 产品 类 型 〈 后 续 
小 节 会 讲解 如 何 添加 一 款 新 产品 ) ; 然后 可 以 根据 提示 进行 选择 ， 如 图 
2-5 所 示 。 


You're building on Linux 


Lunch menu... pick a combo: 
. full-eng 
. full x86-eng 
. vbox x86-eng 
. full grouper-userdebug 
. Mini armv7a neon-userdebug 


. full wingray-userdebug 
. full crespo-userdebug 


. full maguro-userdebug 
0. full panda-userdebug 


1 
2 
3 
4 
5 
6. mini armv7a-userdebug 
7 
8 
9 
1 


Which would you like? [full-eng 





全 图 2-5 使 用 “lunch” 来 显示 所 有 产品 
Step3， 执 行 编译 命令 
最 直接 的 就 是 输入 如 下 命令 : 
$ make 


对 于 2. 3 以 下 的 版 本 ， 整 个 编译 过 程 在 一 台 普 通 计算 机 上 需要 3 小 时 
以 上 的 时 间 。 而 对 于 Je11yBean 以 上 的 项 目 ， 很 可 能 会 花费 5 小 时 以 上 的 
时 间 〈 这 取决 于 你 的 宿主 机 配置 ) 。 


如 果 和 希望 充分 利用 CPU 资源 ， 也 可 以 使 用 make 选 项 “-jN”。N 的 值 
取决 于 开发 机 器 的 CPU 数 、 每 颗 CPU 的 核心 数 以 及 每 个 核心 的 线程 数 。 


例如 ， 你 可 以 使 用 以 下 命令 来 加 快 编译 速度 : 
$ make -j4 


有 个 小 技巧 可 以 为 这 次 编译 轻松 地 打上 Bui 1d Number 标 签 ， 而 不 需 
要 特别 更 改 脚 本 文件 ， 即 在 make 之 前 输入 如 下 命令 : 


$ export BUILD NUMBER=${USER}-'date +%Y%m%d -%H%M%S ' 


在 定义 BUILD_NUMBER 变 量 值 时 要 特别 注意 容易 引起 错误 的 符号 ， 
aq “$” g” (13 . 7J “y” EA ae? ee = 


这 样 我 们 就 成 功 编译 出 Android 原 生态 系统 了 一 一 当然 ， 上 面 
的 “make” 指 令 只 是 选择 默认 的 产品 进行 编译 。 假 如 你 希望 针对 某 个 特 
Some 还 需要 先 通过 上 一 小 节 中 的 “1unch” 进 行 相应 的 选 
Fo 

接 下 来 看 看 如 何 编译 出 SOK。 这 是 很 多 开发 者 ， 特 别 是 应 用 程序 研 
发 人 员 所 关心 的 。 因 为 很 多 时 候 通 过 SDK 所 市 的 模拟 器 来 调试 APK 应 用 ， 
比 在 真 机 上 操作 要 来 得 高 效 且 便 捷 ; 而 且 模拟 器 可 以 配置 出 各 种 不 同 的 
屏幕 参数 ， 用 以 验证 应 用 程序 的 “ 适 本 ”能 


SDK 是 运行 于 Host 机 之 上 的 ， 因 而 编译 过 程 根 据 宿主 操 作 系 统 的 不 
同 会 有 所 区 别 。 详 细 步 骤 如 下 : 


Mac 0S 和 Linux 
(1) 下载 源码 ， 和 前 面 已 经 讲 过 的 源码 下 载 过 程 没有 任何 区 别 。 
(2) 执行 envsetup. sh. 
(3) 选择 SDK 对 应 的 产品 。 
$ lunch sdk-eng 


提示 : 如 果 通 过 “lunch” 没 有 出 现 “sdk” 这 个 种 类 的 产品 也 没有 
关系 ， 可 以 直接 输入 上 面 的 命令 。 


(4) 最 后 ， 使 用 以 下 命令 进行 SDK 编 译 : 
$ make sdk 


Windows 


运行 于 Windows 环 境 下 的 SDK 编 译 需 要 基于 上 面 Linux 的 编译 结果 
(注意 只 能 是 Linux 环 境 下 生成 的 结果 ， 而 不 支持 Mac0S) 。 


(1) 执行 Linux 下 SDK 编 译 的 所 有 步骤 ， 生 成 Linux 版 的 SDK。 
(2) 安装 额外 的 支持 包 。 


$ sudo apt-get install mingw32 tofrodos 


(3) 再 次 执行 编译 即 : 


$ . ./build/envsetup.sh 
$ lunch sdk-eng 
$ make win_sdk 


这 样 我 们 就 完成 Wi ndows 版 本 SDK 的 编译 了 。 
当然 上 面 编译 SDK 的 过 程 也 同样 可 以 利用 多 核心 CPU 的 优势 。 例 如 : 
$ make -j4 sdk 


面向 Host 和 Target 的 编译 结果 都 存放 在 源码 工程 out 目 录 下 ， 分 为 
两 个 子 目 录 。 


e host: SDK 生 成 的 文件 存放 在 这 里 。 例 如 : 
e MacOS 


out/host/darwin-x86/sdk/android-sdk_eng. <bui Id- 
id>_mac—x86. zip 


° Windows 


out/host/windows/sdk/android- 
sdk_eng. $ {USER} windows/ 


° target: 通过 make 命 令 生成 的 文件 存放 在 这 
另外 ， 局 动 一 个 模拟 器 可 以 使 用 以 下 命令 。 


$ emulator [OPTIONS] 


ae ee 3 提供 的 启动 选项 非常 丰富 ， 读 者 可 以 参见 本 书 工具 篇 中 的 详 
ZHAI o 


2.3 ERIP mes ER 

上 一 小 节 我 们 学 习 了 原生 态 Android 系 统 的 编译 步骤 ， 为 大 家 进 一 
步 理解 定制 设备 的 编译 流程 打下 了 基础 。Android 系 统 发 展 到 今天 ， 已 
经 在 多 个 产品 领域 得 到 了 广泛 的 应 用 。 相 信 有 一 个 问题 是 很 多 人 都 想 了 
解 的 ， 那 就 是 如 何在 原生 态 Android 系 统 中 添加 自己 的 定制 产品 。 


2.3.1 定制 新 产品 


仔细 观察 整个 Android 源 码 项 目 可 以 发 现 ， 它 的 根 目录 下 有 一 个 
devi ce 文件 夹 ， 其 中 又 包含 了 诸如 samsung、moto、google 等 厂商 名 
录 ， 如 图 2-6 所 示 。 


asus common generic 
google Ige sample 
samsung samsunqg_slsi ti 


全 图 2-6 device 文 件 夹 下 的 厂商 目录 
在 Android 编 译 系 统 中 新 增 一 款 设备 的 过 程 如 下 。 


Step 1. 和 图 2-6 所 列 的 各 厂商 一 样 ， 我 们 也 最 好 先 在 device 目 录 
下 添加 一 个 以 公司 命名 的 文件 来。 当然 ，Android 系 统 本 身 并 没有 强制 
这 样 做 (后 面 会 看 到 vendor 目 录 也 是 可 以 的 ) ， 只 不 过 规范 的 做 法 有 利 
于 项 目的 统一 管理 。 

然后 在 这 个 公司 名 目录 下 为 各 产品 分 别 建立 对 应 的 子 文件 夹 。 以 
samsung 为 例 ， 其 文件 夹 中 包含 的 产品 如 图 2-7 所 示 。 





Date Moain 


lype Le MICU 
Fri 26 Jul 2013 


15 items folder 





att 





+ | maguro 


+ j Manta 51 items folder Fri 26 Jul 2013 
+ | toro 18 items folder Fri 26 Jul 2013 
+ gj toroplus 19 items folder Fri 26 Jul 2013 
+ jg tuna 45 items folder Fri 26 Jul 2013 


全 图 2-7 一 个 厂商 通常 有 多 种 产品 


完成 产品 目录 的 添加 后 ， 和 此 项 目 相关 的 所 有 特定 文件 都 应 该 优先 
放置 到 这 里 。 一 般 的 组 织 结构 如 图 2-8 所 示 。 


COMPANY 2 COMPANY N 
PRODUCT 3 









COMPANY | 
PRODUCT PRODUCT 















AndroidProducts mk BoardContig.mk device.mk 


全 图 2-8 device A R44 2022 RH 


由 图 2-8 最 后 一 行 可 以 看 出 ， 一 款 新 产品 的 编译 需要 多 个 配置 文件 
(sh、mk 等 ) 的 支持 。 我 们 按照 这 些 文件 所 处 的 层级 进行 一 个 系统 的 分 
K, 如 表 2-5 所 示 。 


表 2-5 ”定制 新 设备 所 需 的 配置 文件 分 类 


已 三 淋 构 层 “| 各 所 采用 的 硬件 架构 ， 如 ARM、X86 等 
( Architecture) 


核心 板 层 硬件 电路 的 核心 板 层 配置 


(Board ) 


设备 层 外 围 设 备 的 配置 ， 如 有 没有 键盘 


(Device) 


SHE 最 终生 成 的 系统 需要 包含 的 软件 模块 和 配置 ， 
( Product) 





也 就 是 说 ， 一 款 产品 由 底层 往 上 的 构建 顺序 是 : 芯片 架构 一 核心 板 
一 设备 一 产品 。 这 样 讲 可 能 有 点 抽象 ， 给 大 家 举 个 具体 的 例子 。 我 们 知 
道 ， 当 前 能 入 式 领 域 市 场 占 有 率 最 高 的 当 属 ARM 系 列 芯 片 。 但 是 首先 ， 
ARM 公 司 本 身 并 不 生产 具体 的 芯片 ， 而 只 授权 其 他 合作 伙伴 来 生产 和 销 
售 半导体 芯片 。ARM 架 构 就 是 属于 最 底层 的 硬件 体系 ， 需 要 在 编译 时 配 
置 。 其 次 ， 很 多 芯片 设计 商 〈 如 三 星 ) 在 获得 授权 后 ， 可 以 在 ARM 架 构 
的 基础 上 设计 出 具体 的 核心 板 ， 如 S5PV210。 接 下 来 ， 三 星 会 将 其 产品 
进一步 销售 给 有 需要 的 下 一 级 厂商 ， 如 某 手 机 生产 商 。 此 时 就 要 考虑 整 
个 设备 的 硬件 配置 了 ， 如 这 款 手 机 是 否 要 带 有 按键 、 触 摸 屏 等 。 最 后 ， 


在 确认 了 以 上 3 个 层次 的 硬件 设计 后 ， 我 们 还 可 以 指定 产品 的 一 些 具体 
属性 ， 如 默认 的 国家 或 地 区 语言 、 是 否 带 有 某 些 应 用 程序 等 。 


eT og gre 
文件 。 


Step 2. vendorsetup. sh 


虽然 我 们 已 经 为 新 产品 创建 了 目录 ， 但 Android 系 统 并 不 知道 它 的 
存在 一 一 所 以 需要 主动 告知 Android 系 统 新 增 了 一 个 “家 庭 成 员 ”。 以 
三 星 toro 为 例 ， 为 了 让 它 能 被 正确 添加 到 编译 系统 中 ， 首 先 就 要 在 其 目 
录 下 新 建 一 个 vendorsetup. sh 脚本 。 这 个 脚本 通常 只 需要 一 个 语句 。 具 
体 范例 如 下 : 


add_lunch_combo full toro-userdebug 


大 家 应 该 还 记得 前 一 小 节 编 译 原生 态 系统 的 第 一 步 是 执行 
envsetup. sh， 鸳 数 add_lunch_combo 就 是 在 这 个 文件 中 定义 的 。 此 子 数 
的 作用 是 将 其 参数 所 描述 的 产品 〈 如 ful1_toro-userdebug) 添加 到 系 
统 相关 变量 中 后 续 1unch 提 供 的 选单 即 基于 这 些 变 量 产 生 的 。 


那么 ，vendor setup. sh 在 什么 时 候 会 被 调用 呢 ? 

答案 也 是 envsetup. sh。 这 个 脚本 的 大 部 分 内 容 是 对 各 种 函数 进行 
定义 与 实现 ， 末 尾 则 会 通过 一 个 for 循 环 来 扫描 工程 中 所 有 可 用 的 
vendorsetup. sh， 并 执行 它们 。 有 具体 源码 如 下 : 


# Execute the contents of any vendorsetup.sh files we can find. 
for f in 'test -d device && find device -maxdepth 4 -name 'vendor 








‘test -d vendor && find vendor -maxdepth 4 -name 'vendor 
do 
echo "including $f" 
«$f 
Done 


unset f 


可 见 ， 默 认 情 况 下 编译 系统 会 扫描 如 下 路 径 来 查找 


vendor setup. sh: 


/vendor/ 
/device/ 


注 : vendor 这 个 目录 在 4. 3 版 本 的 Android 工 程 中 已 经 不 存在 了 ， 建 
议 开发 者 将 产品 目录 统一 放 在 device 中 。 


打 一 个 比方 ， 上 述 步骤 有 点 类 似 于 超市 的 工作 流程 : LAR Gh 
译 系统 ) 首先 要 扫描 仓库 〈vendor 和 device 目 录 ) ， 统 计 出 有 哪些 商品 
(由 vendorsetup. sh 负责 记录 ) ， 并 通过 一 定 的 方式 
(add_lunch_combo@envsetup. sh) 将 物品 上 架 ， 然 后 消费 者 才能 在 货 
架 上 挑选 (lunch) 自己 想 要 的 商品 。 


Step 3. 添加 AndroidProducts. mk。 消 费 者 在 货架 上 选择 
(lunch) 了 某 样 “商品 ”后 ， 工 作 人 员 的 后 续 操作 〈 如 结账 、 售 后 
F) 就 完全 基于 这 个 特定 商品 来 展开 。 编 译 系统 会 先 在 商品 所 在 目录 下 
寻找 AndroidProducts. mk 文件 ， 这 里 记录 着 针对 该 款 商 品 的 一 些 具体 属 
性 。 不 过 ， 通 常 我 们 只 在 这 个 文件 中 做 一 个 “转向 ”。 如 : 


/*device/samsung/toro/AndroidProducts.mk*/ 

PRODUCT_MAKEFILES := \ 
$(LOCAL_DIR)/aosp_toro.mk \ 
$(LOCAL_DIR)/full_toro.mk 


因为 AndroidProducts. mk 对 于 每 款 产品 都 是 通用 的 ， 不 利于 维护 管 
理 ， 所 以 可 另外 新 增 一 个 或 者 多 个 以 该 产品 命名 的 makefi le 〈 如 
full toro. mk 和 aosp_toro. mk) ， 有 再 让 前 者 通过 
PRODUCT_MAKEF1LES“ 指 向 ”它们 。 


Step4， 实 现 上 一 步 所 提 到 的 某 产 品 专用 的 makefi le 文件 〈 如 
full_toro. mk 和 aosp_toro. mk) 。 可 以 充分 利用 编译 系统 已 有 的 全 局 变 
量 或 者 函数 来 完成 任何 需要 的 功能 。 例 如 ， 指 定编 译 结束 后 需要 复制 到 
设备 系统 中 的 各 种 文件 、 设 置 系统 属性 〈 系 统 属 性 最 终 会 写 入 设 
备 /system 目 录 下 的 bui ld. prop 文 件 中 ) 等 。 以 ful1_toro. mk 为 例 : 


/*device/samsung/toro/full_toro.mk*/ 

# 将 apns 等 配置 文件 复制 到 设备 的 指定 目录 中 

PRODUCT_COPY_FILES += \ 
device/samsung/toro/bcmdhd.cal:system/etc/wifi/bcmdhd.cal \ 
device/sample/etc/apns-conf_verizon.xml:system/etc/apns-conf. 


# 继承 下 面 两 个 nk 文件 


$(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telep 
$(call inherit-product, device/samsung/toro/device_vzw.mk ) 

# 下 面 重 载 编译 系统 中 已 经 定义 的 变量 

PRODUCT_NAME :=full_toro  # 产 品名 称 

PRODUCT_DEVICE := toro # 设 备 名 称 

PRODUCT_BRAND := Android  # 品 牌 名称 


常用 的 一 些 变量 做 统一 讲解 。 


表 2-6 PRODUCT 相 关 变 量 


称 ， 最 终 会 显示 在 
PRODUCT NAME 系统 设置 中 的 “关于 设 
备 ” 选 项 卡 中 


产品 所 属 品 牌 


系统 需要 预 装 的 一 系列 程 
PRODUCT_PACKAGES 序 ， 如 APKs 


PRODUCT_MODEL 








所 文 持 的 国家 语言 。 格 式 
如 下 : 


PRODUCT_LOCALES [两 字 节 语言 码 ]-[ 两 字 节 国 
家 码 ] 


各 语言 间 以 空格 分 隔 


本 产品 遵循 的 “策略 ”， 
如 : 
android.policy_phone 
android.policy_mid 


PRODUCT_POLICY 


一 系列 以 空格 分 隔 的 产品 
PRODUCT_TA Aree 
ODUCT_TAGS 标签 措 述 


用 于 重 载 系统 属性 。 

格式 : key=value 

示例 : 

ro.product.firmware=v0.4rc1 
PRODUCT_PROPERTY_OVERRIDES}dalvik.vm.dexopt-data- 


only=1 
终 会 被 存储 在 


的 /system/build.prop 文 件 中 





Step 5. 添加 BoardConfig. mk 文件 。 这 个 文件 用 于 填写 目标 架构 、 
硬件 设备 属性 、 编 译 器 的 条 件 标志 、 分 区 布局 、boot 地 址 、ramdi sk 大 
小 等 一 系列 参数 (参见 下 一 小 节 对 系统 映像 文件 的 讲解 〉。 下 面 是 一 个 
范例 〈 因 为 toro 中 的 BoardConf iig 主 要 引用 了 tuna 的 BoardConf ig 实 现 ， 
所 以 我 们 直接 讲解 后 者 的 实现 ) : 
#/*device/samsung/tuna/BoardConfig.mk*/ 

TARGET_CPU_ABI := armeabi-v7a ## eabi 即 Embedded application binar\ 
TARGET_CPU_ABI2 := armeabi 


TARGET_NO BOOTLOADER := true ## 不 编译 bootloader 


BOARD_SYSTEMIMAGE_PARTITION_SIZE := 685768704#system,.img 分 区 大 小 
BOARD_USERDATAIMAGE_PARTITION_SIZE := 14539537408#userdata.img 的 分 
BOARD_FLASH_BLOCK_SIZE := 4096 #flash 块 大 小 


BOARD_WLAN_DEVICE := bemdhd #wifi 设 备 


可 以 看 到 ， 这 个 makefi le 文件 中 涉及 的 变量 大 部 分 
以 “TARGET_ ”和 “BOARD_ ”开头 ， 且 数量 众多 。 相 信 对 于 第 一 次 编写 
BoardConfig. mk 的 开发 者 来 说 ， 这 是 一 个 不 小 的 挑战 。 那 么 ， 有 没有 一 
些小 技巧 来 加 速 学 习 呢 ? 


答案 是 肯定 的 。 


各 大 厂商 在 自己 产品 目录 下 存放 的 BoardConf ig. mk 样本 就 是 我 们 学 
习 的 绝 佳 材 料 。 通 过 比较 可 发 现 ， 这 些 文件 大 部 分 都 是 雷同 的 。 所 以 我 
们 完全 可 以 先 从 中 复制 一 份 〈 最 好 选择 架构 、 主 忆 片 与 自己 项 目 相当 
的 ) ， 然 后 根据 产品 的 具体 需求 进行 修改 。 


Step 6. 添加 Android. mk。 这 是 Android 系 统 下 编译 某 个 模块 的 标 
准 makefi le。 有 些 读者 可 能 分 不 清楚 这 个 文件 与 前 面 几 个 步骤 中 的 
makefile 有 何 区 别 。 我 们 举例 说 明 ， 如 果 Step1-Step5 中 的 文件 用 于 决 
定 一 个 产品 的 属性 ， 那 么 Android. mk 就 是 生产 这 个 “产品 ” 某 个 “ 零 
件 ” 的 “生产 工序 ”。 要 特别 注意 ， 只 是 某 个 “零件 ”而 已 。 整 个 
产品 是 需要 由 很 多 Android. mk 生产 出 的 “零件 ”组 合 而 成 的 。 


Step7， 完 成 前 面 6 个 步骤 后 ， 我 们 就 成 功 地 将 一 款 新 设备 定制 到 编 
i nee 接 下 来 的 编译 流程 和 原生 态 系 统 是 完全 一 致 的 ， 这 里 不 再 
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值得 一 提 的 是 ，/system/bui ld. prop 这 个 文件 的 生成 过 程 也 是 由 编 
译 系 统 控制 的 。 具 体 处 理 过 程 在 /bui 1d/core/Makefile 中 ， 它 主要 由 以 
下 几 个 部 分 组 成 : 
e /build/tools/buildinfo.sh 


这 个 脚本 用 于 向 bui Id. prop 中 输出 各 种 key> 《value> 组 合 ， 实 现 
方式 也 很 简单 。 下 面 是 其 中 的 两 行 节选 : 


echo "ro. build. id=$BUILD ID" 


echo "ro. build. display. id=$BUILD DISPLAY 1D" 





e TARGET _ DEVICE_DIR 目 录 下 的 System.ptop 
e ADDITIONAL_BUILD_PROPERTIES 
e /build/tools/post_process_props.py 


清理 工作 ， 将 黑 名 单 中 的 项 目 从 最 终 的 bui1d. prop PRR. 


开发 人 员 在 定制 一 款 新 设备 时 ， 可 以 根据 实际 情况 将 自己 的 配置 信 
息 添 加 到 上 述 几 个 组 成 部 分 中 ， 以 保证 设备 的 正常 运行 。 


2.3.2 Linux 内 核 编译 


不 同 产品 的 硬件 配置 往往 是 有 差异 的 。 比 如 某 款 手机 配备 了 蓝牙 芯 
上 请， 而 另 一 款 则 没有 ; 即便 是 都 内 置 了 蓝牙 模块 的 两 款 手 机 ， 它 们 的 生 
产 商 和 型 号 也 很 可 能 不 一 样 一 一 这 就 不 可 避免 地 要 涉及 内 核 驱动 的 移 
植 。 前 面 我 们 分 析 的 编译 流程 只 针对 Android 系 统 本 身 ， 而 Linux 内 核 和 
Android 的 编译 是 独立 的 。 因 此 对 于 设备 开发 商 来 说 ， 还 需要 下 载 、 修 
改 和 编译 内 核 版 本 。 


接 下 来 以 Android 官 方 提供 的 例子 来 讲解 如 何 下 载 合 适 的 内 核 版 





这 个 范例 基于 Google 的 Panda 设 备 ， 具 体 步 骤 如 下 。 
Step1. 首先 通过 以 下 命令 来 获取 到 git log: 


git clone https://android.googlesource.com/device/ti/panda 
cd panda 
git log --max-count=1 kernel 


这 样 就 得 到 了 panda kerne1 的 提交 值 ， 在 后 续 步 又 中 会 用 到 。 
Step2. Google 针 对 Android 系 统 提供 了 以 下 可 用 的 内 核 版 本 : 


git clone https://android.googlesource.com/kernel/common.git 
git clone https://android.googlesource.com/kernel/exynos.git 
git clone https://android.googlesource.com/kernel/goldfish.git 
git clone https://android.googlesource.com/kernel/msm. git 

git clone https://android.googlesource.com/kernel/omap.git 


AAA 


AAA AH 


$ git clone https://android.googlesource.com/kernel/samsung.git 
$ git clone https://android.googlesource.com/kernel/tegra.git 


上 述 命令 的 每 一 行 都 代表 了 一 个 可 用 的 内 核 版 本 。 
那么 ， 它 们 之 间 有 何 区 别 呢 ? 


e exynos， 适 用 于 Samsung Exynos 芯 片 组 ; 

。goldfsh， 适 用 于 模拟 平台 

e msm， 适 用 于 ADP1，ADP2，Nexus One 以 及 Qualcomm MSM }% } 
组 ; 

。omap， 适 用 寺 PandaBoard 和 Galaxy Nexus 以 及 TI OMAP? 48; 

e samsung， 适 用 于 Nexus S K Samsung Hummingbird R} } 241 ; 

e tegra， 适 用 于 Xoom 以 及 NVIDIA Tegra 芯 片 组 ; 

e common， 则 是 通用 版 本 。 


由 此 可 见 ， 与 Panda 设 备 相 匹 配 的 是 omap. git 这 个 版 本 的 内 核 。 
Step3. 除了 Linux 内 核 ， 我 们 还 需要 下 载 prebui lt。 有 具体 命令 如 


git clone https://android.googlesource.com/platform/prebuilt 
export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/ 


Step4， 完 成 以 上 步骤 后 ， 就 可 以 进行 Panda 内 核 的 编译 了 : 


export ARCH=arm 

export SUBARCH=arm 

export CROSS_COMPILE=arm-eabi- 
cd omap 

git checkout < 第 一 步 获取 到 的 值 > 
make panda_defconfig 

make 


整个 内 核 的 编译 相对 简单 ， 读 者 可 以 自行 党 试 。 
2.3.3 烧 录 /升级 系统 


将 编译 生成 的 可 执行 文件 包 通 过 各 种 方式 写 入 硬件 设备 的 过 程 称 为 
烧 录 (flash) 。 烧 录 的 方式 有 很 多 ， 各 厂商 可 以 根据 实际 的 需求 自行 
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选择 。 常 见 的 有 以 下 几 种 。 
(1) SD 卡 工厂 烧 录 方式 


当前 市 面 上 的 CPU 主 必 片 通常 会 提供 多 种 跳 线 方式 ， 来 支持 佬 入 式 
设备 从 不 同 的 存储 介质 (如 Flash、SD Card) 中 加 载 引 导 程 序 并 启动 
系统 。 这 样 的 设计 显然 会 给 设备 开发 商 带 来 更 多 的 便利 。 研 发 人 员 只 需 
要 将 烧 录 文件 按 一 定 规则 先 写 入 SD 卡 ， 然 后 将 设备 配置 为 SD 卡 启动 。 一 
旦 设备 成 功 局 动 后 ， 处 于 烧 写 模式 下 的 BootLoader 就 会 将 各 文件 按照 要 
求 写 入 产品 存储 设备 〈 通 常 是 FLASH 芯 片 ) 的 指定 地 址 中 。 


由 此 可 见 Boot 1oader 的 主要 作用 有 两 个 :其 一 是 提供 下 载 模式 ， 将 
组 成 系统 的 各 个 Image 写 入 到 设备 的 永久 存储 介质 中 ; 其 二 才 是 在 设备 
开机 过 程 中 完成 引导 系统 正常 启动 的 重任 。 


一 个 完整 的 Android 烧 录 包 至 少 需 要 由 3 部 分 内 容 〈 即 Boot 
Loader, Linux Kerne1 和 Android System) 组 成 。 我 们 可 以 利用 某 种 方 
式 对 它们 先进 行 打包 处 理 ， 然 后 统一 写 入 设备 中 。 一 般 情 况 下 ， 芯 片 三 
商 〈 如 Samsung) 会 针对 某 款 或 某 系列 芯片 提供 专门 的 烧 录 工具 给 开发 
AREA; 否则 各 产品 开发 商 需 要 根据 实际 情况 自行 研发 合适 的 工具 。 


总 的 来 说 ，SD 卡 的 烧 录 手法 以 其 操作 简便 、 不 需要 PC 支持 等 优点 被 
广泛 应 用 于 工厂 生产 中 。 


(2) USB 方 式 

这 种 方式 需要 在 PC 的 配合 下 完成 。 设 备 首先 与 PC 通过 USB 进 行 连 
接 ， 然 后 运行 于 PC 上 的 客户 端 程序 将 辅助 Android 设 备 来 完成 文件 烧 
录 。 


(3) 专用 的 烧 写 工 具 
比如 使 用 J-Tag 进 行 系统 烧 录 。 
(4) 网 络 连 接 方式 


这 种 方式 比较 少见 ， 因 为 它 要 求 设备 本 身 能 接 入 网 络 〈 局 域 网 、 互 
联网 ) ， 这 对 于 很 多 吹 入 式 设备 来 说 过 于 苛刻 。 


(5) 设备 Bootloader+fastboot 的 模式 


这 也 就 是 我 们 俗称 的 “ 线 刷 ”。 需 要 特别 注意 的 是 ， 能 够 使 用 这 种 
升级 模式 的 一 个 前 提 是 设备 中 已 经 存在 可 用 的 Boot loader， 因 而 它 不 能 
被 运用 于 工厂 烧 录 中 〈 此 时 设备 中 还 未 有 任何 有 效 的 系统 程序 ) 。 


当然 ， 各 大 厂商 通常 还 会 在 这 种 模式 上 做 一 些 “ 易 用 性 的 封 
装 ”“【〔 壁 如 提供 带 GUI1 需 面 的 工具 ) ， 从 而 在 一 定 程 度 上 降低 用 户 的 使 
用 门槛 。 


迫使 Android 设 备 进 入 Boot1oader 模 式 的 方法 基本 上 大 同 小 异 ， 下 
面 这 两 种 是 最 常见 的 : 


通过 “fastboot reboot-bootloader” 命令 来 重启 设备 并 进入 
Boot loader 模 式 ; 


在 关机 状态 下 ， 同 时 按 住 设 备 的 “音量 减 ” 和 电源 键 进 入 
Boot loader 模 式 。 


(6) Recovery 模 式 


和 前 一 种 方式 类 似 ， Recovery 模 式 同 样 不 适用 于 设备 首次 烧 录 的 场 
景 。“Recovery” 的 字面 意思 是 “还 原 ”， 这 也 从 侧面 反映 出 它 的 初 袁 
是 帮助 那些 出 现 异 常 的 系统 进行 快速 修复 。 由 于 0TA 这 种 得 到 大 规模 应 
用 的 升级 方式 同样 需要 借助 于 Recovery 模 式 ， 使 得 后 者 逐步 超出 了 原先 
的 设计 范畴 ， 成 为 普通 消费 者 执行 设备 升级 操作 的 首选 方式 。 我 们 将 在 
后 续 小 节 中 对 此 做 更 详细 的 讲解 。 


2.4 Android Multilib Build 
早期 的 Android 系 统 只 支持 32 位 CPU 架构 的 编译 ， 但 随 着 越 来 越 多 的 
64 位 硬件 平台 的 出 现 ， 这 种 编译 系统 的 局 限 性 就 突显 出 来 了 。 因 而 
Android 系 统 推出 了 一 种 新 的 编译 方式 ， 即 Multilib build。 可 想 而 
知 ， 这 种 编译 系统 上 的 改进 需要 至 少 满足 两 个 条 件 : 
。 支持 64-bit 和 32-bit 


64 位 和 32 位 平台 在 很 长 一 段 时 间 内 都 需要 “和 谐 共 处 ”， 因 而 编译 
系统 必须 保证 以 下 几 个 场景 。 


Case1: 支持 只 编译 64-bit 系 统 。 

Case2: 支持 只 编译 32-bit 系 统 。 

Case3: 支持 编译 64 和 32bit 系 统 ，64 位 系统 优先 。 
Case4: 支持 编译 32 和 64 位 系统 ，32 位 系统 优先 。 
。 在 现 有 编译 系统 基础 上 不 需要 做 太 多 改动 


事实 上 Multilib Build 提 供 了 比较 简便 的 方式 来 满足 以 上 两 个 条 
件 ， 我 们 将 在 下 面 内容 中 学 习 到 它 的 具体 做 法 。 


(1) 平台 配置 


BoardConfig. mk 用 于 指定 目标 平台 相关 的 很 多 属性 ， 我 们 可 以 在 这 
个 脚本 中 同时 指定 Pr imary 和 Secondary 的 CPU Arch 和 AB1 : 


与 Pr imary Arch 相 关 的 变量 有 TARGET_ARCH、 
TARGET_ARCH_VARIANT、TARGET_CPU_VARIANT 等 ， 具 体 范 例如 下 : 


TARGET_ARCH := arm64 
TARGET_ARCH_VARIANT := armv8-a 
TARGET_CPU_VARIANT := generic 
TARGET_CPU_ABI := arm64-v8a 


Secondary Arch#8 42> =A TARGET 2ND ARCH, 
TARGET _2ND_ARCH_ VARIANT, TARGET 2ND CPU _VARIANT2$, BAF 7140 
F: 
TARGET_2ND_ARCH := arm 
TARGET_2ND_ARCH_VARIANT := armv7-a-neon 
TARGET_2ND_CPU_VARIANT := cortex-a15 


TARGET_2ND_CPU_ABI := armeabi-v7a 
TARGET_2ND_CPU_ABI2 := armeabi 


如 果 和 希望 默认 编译 32-bit 的 可 执行 程序 ， 可 以 设置 : 
TARGET_PREFER_32_BIT := true 


通常 1unch 列 表 中 会 针对 不 同 平台 提供 相应 的 选项 ， 如 图 2-9 所 示 。 





Lunch menu... pick a combo: 
. aosp_arm-eng 
. aosp_arm64-eng 
. a0Sp_mips-eng 


. aosp_mips64-eng 
. aosp_x86-eng 
. a0Sp_x86_64-eng 





全 图 2-9 相应 的 选项 


当 开 发 者 选择 不 同 平台 时 ， 会 直接 影响 到 TARGET_2ND_ARCH 等 变量 
的 赋值 ， 从 而 有 效 控制 编译 流程 。 比 如 图 2-10 中 左 、 右 两 侧 分 别 对 应 我 
们 使 用 lunch 1 和 lunch 2 所 产生 的 结果 ， 大 家 可 以 对 比 下 其 中 的 差异 。 


TARGET_PRODUCT=aosp_arm 
TARGET_BUILD_VARIANT=eng 
TARGET_BUILD_TYPE=release 
TARGET_BUILD_APPS= 
TARGET_ARCH=arm 
_ARCH_VARIANT=armv7-a 
_VARIANT=generic 


_2ND_CPU_VARIANT= 
HOST_ARCH=x86_64 
HOST_OS=linux 





TARGET_BUILD_TYPE= 
BUILD_APPS= 
ARCH=arm64 
ARCH_VARIANT=armv8-a 


_VARIANT=generic 
= _ARCH=arm 
_2ND_ARCH_VARIANT=armv7-a-neon 
_2ND_CPU_VARIANT=cortex-a1i5 
HOST_ARCH=x86_ 64 
HOST _OS=Linux 





全 图 2-10 控制 编译 流程 


另外 ， 还 可 以 设置 TARGET_SUPPORTS_32_B1IT_APPS 和 
TARGET_SUPPORTS_64_B1T_APPS 来 指明 需要 为 应 用 程序 编译 什么 版 本 的 
本 地 库 。 此 时 需要 特别 注意 : 


。 如 果 这 两 个 变量 被 同时 设置 ， 那 么 系统 会 编译 64-bit 的 应 用 程序 
一 一 除非 你 设置 了 TARGET_PREFER_32_BIT 或 者 在 Android.mk 中 
对 变量 做 了 重 载 ; 

。 如 果 只 有 一 个 变量 被 设置 了 ， 那 么 就 只 编译 与 之 对 应 的 应 用 程序 ; 

。 如 果 两 个 变量 都 没有 被 设置 ， 那 么 除非 你 在 Android.mk 中 做 了 变量 
重 载 ， 否 则 默认 只 编译 32-bit 应 用 程序 。 


那么 在 支持 不 同位 数 的 编译 时 ， 所 采用 的 Tool chain 是 否 有 区 别 ? 


答案 是 肯定 的 。 


如 果 你 希望 使 用 通用 的 GCC 工具 链 来 同时 处 理 两 种 Arch 架 构 ， 那 么 
可 以 使 用 TARGET_ GCC VERSION EXP; 反之 你 可 以 使 用 
TARGET_TOOLCHAIN_RO0OT 和 2ND_TARGET_TOOLCHAIN_R00T 来 为 64 和 32 位 编 
译 分 别 指定 不 同 的 工具 链 。 


(2) 单 模块 配置 
我 们 当然 也 可 以 针对 单个 模块 来 配置 Multilib。 


。 对 于 可 执行 程序 ， 编 译 系统 默认 情况 下 只 会 编译 出 64-bit 的 版 本 。 
除 4 E 我 们 指 证 JY TARGET_PREFER_32_ BITH 者 


LOCAL_32_BIT_ONLY. 

o 对 于 某 个 模块 依赖 的 库 的 编译 方式 ， 会 和 该 模块 有 紧密 关系 。 简 单 
来 讲 32-bit 的 库 或 者 可 执行 程序 依赖 的 库 ， 会 被 以 32 位 来 处 理 ;对 于 
64 位 的 情况 也 同样 如 此 。 
需要 特别 注意 的 是 ， 在 make 命 令 中 直接 指定 的 目标 对 象 只 会 产生 64 

位 的 编译 。 举 一 个 例子 来 说 ，“1unch aosp_arm64-eng” > “make 
libc” 只 会 编译 64-bit 的 1ibc。 如 果 你 想 编译 32 位 的 版 本 ， 需 要 执 
{T “make libc 32” > 


HE EIR AFAGI ÆAndroid. mk， 在 这 个 文件 里 我 们 可 以 
通过 指定 LOCAL_MULTIL1B 来 改变 默认 规则 。 各 种 取 值 和 释义 如 下 所 示 : 


e “first” 
只 考虑 Primary Arch 的 情况 
e “both” 
同时 编译 32 和 64 位 版 本 
e “32” 
只 编译 32 位 版 本 
e “64” 
只 编译 64 位 版 本 
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这 是 默认 值 。 编 译 系统 会 根据 其 他 配置 来 决定 需要 怎么 做 ， 如 
LOCAL_MODULE_TARGET_ARCH，LOCAL_32_B1T_ONLY 等 。 


如 果 你 需要 针对 茶 些 特定 的 架构 来 做 些 调整 ， 那 么 以 下 几 个 变量 可 


能 会 帮 到 你 : 


e LOCAL _ MODULE TARGET _ARCH 


可 以 指定 一 个 Arch 列 表 ， 例 如 “arm x86 arm64” 等 。 这 个 列表 用 
于 指定 你 的 模块 所 支持 的 arch 范 围 ， 换 名 话说， 如 果 当 前 正在 编译 的 
arch 不 在 列表 中 将 导致 本 模块 不 被 编译 : 
e LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH 
如 其 名 所 示 ， 这 个 变量 起 到 和 上 述 变 量 相反 的 作用 。 


e LOCAL_MODULE_TARGET_ARCH_WARN 
e LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN 


这 两 个 变量 的 末尾 多 了 个 “WARN”， 意 思 就 是 如 果 当 前 模块 在 编译 
时 被 忽略 ， 那 么 会 有 warning 打 印 出 来 。 


各 种 编译 标志 也 可 以 打上 与 Arch 相 应 的 标签 ， 如 以 下 几 个 例子 : 


e LOCAL SRC_FILES_atrm, LOCAL_SRC_FILES_x86 
e LOCAL CFLAGS arm, LOCAL_CFLAGS_arm64 
e LOCAL LDFLAGS arm, LOCAL_LDFLAGS_arm64 


我 们 再 来 看 一 下 安装 路 径 的 设置 。 对 于 库 文件 来 说 ， 可 以 使 用 
LOCAL_MODULE_RELATIVE_PATH 来 指定 一 个 不 同 于 默认 路 径 的 值 ， 这 样 32 
位 和 64 位 的 库 都 会 被 放置 到 这 里 。 对 于 可 执行 文件 来 说 ， 可 以 分 别 使 用 
以 下 两 类 变量 来 指定 文件 名 和 安装 路 径 : 

e LOCAL MODULE _STEM 32, LOCAL MODULE STEM 64 
分 别 指定 32 位 和 64 位 下 的 可 执行 文件 名 称 。 
。LOCAL MODULE PATH _ 32 LOCAL _ MODULE PATH 64 
分 别 指定 32 位 和 64 位 下 的 可 执行 文件 安装 路 径 。 
(3) Zygote 
支持 Multi1ib Bui1d 还 需要 考虑 一 个 重要 的 应 用 场合 ， 即 Zygote。 


可 想 而 知 ，Multi1ib 编 译 会 产生 两 个 版 本 的 Zygote 来 支持 不 同位 数 的 应 
用 程序 ， 即 Zygote64 和 Zygote32。 早 期 的 Android 系 统 中 ，Zygote 的 启 


动 脚本 被 直接 书写 在 init. rc 中 。 但 从 Lollipop 开 始 ， 这 种 情况 一 去 不 
复 返 了 。 我 们 来 看 一 下 其 中 的 变化 : 


/*system/core/rootdir/init.rc*/ 
import /init.${ro.hardware}.rc 
import /init.${ro.zygote}.rc 


根据 系统 属性 ro. zygote 的 不 同 ，init 进 程 会 调用 不 同 的 zygote 描 
述 脚本 ， 从 而 启动 不 同 版 本 的 “ 旷 化 器 ”。 以 ro. zygote 
为 “zygote64_32” 为 例 ， 具 体 脚 本 如 下 : 


/*system/core/rootdir/init.zygote64 32.rc*/ 
service zygote /system/bin/<strong>app_process64</strong> -Xzygot 
-Server --socket-name=zygote 
class main 
socket zygote stream 660 root system 
onrestart write /sys/android_power/request_state wake 
onrestart write /sys/power/state on 
onrestart restart media 
onrestart restart netd 


service zygote_secondary /system/bin/<strong>app_process32</stron 
socket -name=zygote_secondary 

class main 

socket zygote_secondary stream 660 root system 

onrestart restart zygote 


这 个 脚本 描述 的 是 Pr imary ArchA64, Secondary Arch 为 32 位 时 的 
情况 。 因 为 zygote 的 承载 进程 是 app_process， 所 以 我 们 可 以 看 到 系统 
同时 启动 了 两 个 Service， 即 app_process64 和 app_process32。 关 于 
zygote 启 动 过 程 中 的 更 多 细节 ， 读 者 可 以 参考 本 书 的 系统 启动 章节 ， 我 
们 这 里 先 不 进行 深入 分 析 。 


因为 系统 需要 有 两 个 不 同 版 本 的 zygote 同 时 存在 ， 根 据 前 面 内 容 的 
学 习 我 们 可 以 断定 ，zygote 的 Android. mk 中 一 定做 了 同时 编译 32 位 和 64 
位 程序 的 配置 : 


/*frameworks/base/cmds/app_process/Android.mk*/ 
LOCAL_SHARED_LIBRARIES := \ 

libcutils \ 

libutils \ 

liblog \ 

libbinder \ 


libandroid_runtime 


LOCAL_MODULE:= app_process 
LOCAL_MULTILIB := <strong>both</strong> 
LOCAL_MODULE_STEM_32 := app_process32 
LOCAL_MODULE_STEM_64 := app_process64 
include $(BUILD_EXECUTABLE ) 


上 面 这 个 脚本 可 以 作为 需要 支持 Multilib bui1d 的 模块 的 一 个 范 
例 。 其 中 LOCAL_MULTILIB 告 诉 系统 ， 需 要 为 zygote 生 成 两 种 类 型 的 应 用 
程序 ， 而 LOCAL MODULE STEM 32 和 LOCAL MODULE STEM _ 64 分别 用 于 指定 
两 种 情况 下 的 应 用 程序 名 称 。 


2.5 Android 系 统 映像 文件 


通过 前 面 几 个 小 节 的 学 习 ， 我 们 已 经 按照 产品 需求 编译 出 自 定 制 的 
Androidi ÆA T o WERA, RE 
out/target/product/[YOUR_PRODUCT_NAME]/ 目 录 下 生成 最 终 要 烧 录 到 
设备 中 的 映像 文件 ， 包 括 system. img, userdata. img, recovery. img, 
ramdi sk. img 等 。 初 次 看 到 这 些 文件 的 读者 一 定 想 知道 为 什么 会 生成 这 
么 多 的 映像 、 它 们 各 自 都 将 完成 什么 功能 。 


这 是 本 小 节 所 要 回答 的 问题 。 


Android 中 常见 image 文 件 包 的 解释 如 表 2-7 所 示 。 


表 2-7 Android 系 统 常 见 image 释 义 





包含 内 核 局 动 参数 、 内 核 等 多 个 元 素 〈 详 见 后 面 


小 节 的 描述 ) 





小 型 的 文件 系统 ， 是 Android 系 统 局 动 的 关键 





| 





METRE Android 系 统 的 运行 程序 包 (framework 就 在 这 
YStEM.IMS m) ， 将 被 挂 载 到 设备 中 的 /system 节 点 下 


userdata.img | 各 程序 的 数据 存储 所 在 ， 将 被 挂 载 到 /data 目 录 下 


ecovery.imgl 设 备 进入 “恢复 模式 ”时 所 需要 的 映像 包 











H 





misc.img |E} “miscellaneous”, BE KFD AY 


+ 


绥 冲 区 ， 将 被 挂 载 到 /cache 节 点 中 





它们 的 关系 可 以 用 图 2-11 来 表示 。 


接 下 来 对 boot 、ramdisk、system 三 个 重要 的 系统 image 进 行 深入 解 
析 。 








理解 boot. img 的 最 好 方法 就 是 学 习 它 的 制作 工具 一 一 mkboot img， 
源码 路 径 在 system/core/ mkbootimg 中 。 这 个 工具 的 语法 规则 如 下 : 


mkbootimg --kernel <filename> --ramdisk <filename> 

[ --second <2ndbootloader-filename>] [ --cmdline <kernel-command 
[ --board <boardname> ] [ --base <address> | 
[ --pagesize <pagesize> ] -0|--output <filename> 


—-kernel: 指定 内 核 程序 包 〈 如 zlmage) 的 存放 路 径 ; 
—-ramdisk: 指定 ramdisk. img (下 一 小 节 有 详细 分 析 〉 的 存放 路 


--second: 可 选 ， 指 第 二 阶段 文件 ; 
--cmdline: 可 选 ， 内 核 局 动 参数 ; 

一 board: 可 选 ， 板 名 称 ; 

--base: 可 选 ， 内 核 启 动 基地 址 ; 

--pagesize: 可 选 ， 页 大 小 ; 

—-output: 输出 名 称 。 

那么 ， 编 译 系统 是 在 什么 地 方 调 用 mkboot img 的 呢 ? 


其 一 就 是 droi dcore 的 依赖 中 ，INSTALLED BOOTI MAGE TARGET， 如 
图 2-1 2 所 示 。 


droidcore: files \ 
systemimage \ 
INSTALLED BOOTIMAGE TARGET 
$ (INSTALLED RECOVERYIMAGE TARGET) \ 
$ (INSTALLED USERDATAIMAGE TARGET) \ 





全 图 2-12 droidcore 的 依赖 


其 二 就 是 生成 INSTALLED BOOT IMAGE TARGET 的 地 方 
(build/core/Makefile) ， 如 图 2-13 所 示 。 


S (NEyY HN) : $ (MKBOOTIMG) $ (INTERNAL BOOTIMAGE FILES) 
$ (call pretty,"Target boot image: $@") 
$ (hide) $(MKBOOTIMG) $(INTERNAL BOOTIMAGE ARGS) $(BOARD MKBOOTIMG ARGS) --output $@ 
$(hide) $(call assert-max-imacge-size,$@,$§ (BOARD BOOTIMAGE PARTITION SIZE) ,raw) 
endif # TARGET BOOTIMAGE USE EXT2 


全 图 2-13 生成 INSTALLED_BOOTIMAGE_TARGET 的 地 方 
可 见 mkbootimg 程 序 的 各 参数 是 由 INTERNAL BOOT IMAGE _ARGS 和 
BOARD_MKBOOT1MG_ARGS 来 指定 的 ， 而 这 两 者 又 分 别 取 决 于 其 他 makefi le 
中 的 定义 。 如 BoardConfig. mk 中 定义 的 BOARD_KERNEL_CMDLINE 在 默认 情 
况 下 会 作为 --cmdl ine 人 参数 传 给 mkbootimg; BOARD_KERNEL_BASE 则 作为 - 
-base 人 参数 传 给 mkboot img. 


按照 Boot img. h 中 的 描述 ，boot. img 的 文件 结构 如 图 2-14 所 示 。 


| boot.img 
ram disk 





全 图 2-14 bootimg 的 文件 结构 


各 组 成 部 分 如 下 : 
1. boot header 
存储 内 核 启 动 “ 头 部 ”一 一 ARAMSAS ES, AHi—tTpage 


空间 ， 即 4KB 大 小 。Header 中 包含 的 具体 内 容 可 以 通过 分 析 Mkboot img. c 
中 的 main 函 数 来 获知 ， 它 实际 上 对 应 boot_img_hdr 这 个 结构 体 : 


/*system/core/mkbootimg/Bootimg.h*/ 

struct boot_img_hdr 

{ 
unsigned char magic[BOOT_MAGIC_SIZE]; 
unsigned kernel_size; /* size in bytes */ 
unsigned kernel_addr; /* physical load addr */ 
unsigned ramdisk_size; /* size in bytes */ 
unsigned ramdisk_addr; /* physical load addr */ 
unsigned second_size; /* size in bytes */ 
unsigned second_addr; /* physical load addr */ 
unsigned tags_addr; /* physical addr for kernel tags */ 
unsigned page_size; /* flash page size we assume */ 
unsigned unused[2]; /* future expansion: should be 0 */ 
unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */ 
unsigned char cmdline[BOOT_ARGS_SIZE]; 
unsigned id[8]; /* timestamp / checksum / shai / etc */ 


}; 


这 样 讲 有 点 抽象 ， 下 面 举 个 实际 的 boot. img 例 子 ， 我 们 可 以 用 
UltraEditor 或 者 WinHex 把 它 打 开 ， 如 图 2-15 所 示 。 


可 以 看 到 ， 文 件 最 起 始 的 8 个 字 节 是 “ANDR01D!”， 也 称 为 
BOOT MAGIC; 后 续 的 内 容 则 包括 kernel_size，kernel_addr 等 ， 与 上 述 
的 boot_img_hdr 结 构 体 完全 吻合 。 






00000000h: 3 
00000010h: D4 DE 10 00 00 00 00 41 00 00 00 00 00 00 FO 40 ; 更 ..... eee = 
00000020h: 00 01 00 40 00 08 00 00 00 00 00 00 00 00 00 00 ; ...@............ 
00000030h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F ................ 
00000040h: 63 6F 6E 73 6F 6C 65 3D 74 74 79 53 30 2C 31 31 ; console=ttyS0,11 
00000050h: 35 32 30 30 20 72 77 20 69 6E 69 74 3D 2F 69 6E ; 5200 rw init=/in 
00000060h: 69 74 20 6C 6F 67 6C 65 76 65 6C 3D 35 00 00 00 ; it loglevel=5... 
00000070h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F ................ 
nanannkon: nn nn nn NAA NAA AN AN nn AN AN AN nn nn AN AN AN : ---------------- 


全 图 2-15 boot header $4] 
2. kernel 


内 核 程 序 是 整个 android 系 统 的 基础 ， 也 被 “ 装 入 ”boot. img 
一 一 我 们 可 以 通过 --kerne1 选 项 来 指定 内 核 映 射 文件 的 存储 路 径 。 其 所 
占据 的 大 小 为 : 
n pages=(kernel_size + page_size - 1) / page_size 

由 此 可 以 看 出 ，boot. img 中 的 各 元 素 必 须 是 页 对 齐 的 。 
3. ramdisk 


不 仅 是 kerne1，boot. img 中 也 包含 了 ramdisk. img。 其 所 占据 大 小 
为 : 


m pages=(ramdisk_size + page_size - 1) / page_size 
可 见 也 是 页 对 齐 的 。 
其 他 关于 ramdi sk 的 详细 摘 述 请 参照 下 一 小 节 ， 这 里 先 不 做 解释 。 
4. second stage 
这 一 项 是 可 选 的。 其 占据 大 小 为 : 
o pages= (second_size + page_size - 1) / page_size 
这 个 元 素 通 常用 于 扩展 功能 ， 默 认 情 况 下 可 以 忽略 。 
2.5.2 ramdisk. img 


无 论 什么 类 型 的 文件 ， 从 计算 机 存储 的 角度 来 说 都 只 不 过 是 一 
堆 “0”“1” 数 字 的 集合 一 一 它们 只 有 在 特定 处 理 规则 的 解释 下 才能 
表现 出 意义 。 如 txt 文 本 用 Ultra Editor 打 开 就 可 以 显示 出 里 面 的 文 
FZ; jpg 图 像 文件 在 Photoshop 工 具 的 辅助 下 可 以 让 用 户 看 到 其 所 包含 的 
内 容 。 而 文本 与 jpeg 图 像 文件 本 质 上 并 没有 区 别 ， 只 不 过 存储 与 读 取 这 


一 文件 的 “规则 ”发 生 了 变化 一 一 正 是 这 些 “ 五 花 八 门 ”的 “ 规 
则 ” 才 创 造 出 成 干 上 万 的 文件 类 型 。 


另外 ， 文 件 后 缀 名 也 并 不 是 必需 的 ， 除 非 操 作 系 统 用 它 来 鉴别 文件 
的 类 型 。 而 更 多 情况 下 ， 后 缀 名 的 存在 只 是 为 了 让 用 户 有 个 直观 的 认 
识 。 如 我 们 会 认为 “*. txt” 是 文本 文档 、“*. jpg” 是 图 片 等 。 


Android 的 系统 文件 以 “. img” 为 后 缀 名 ， 这 种 类 型 的 文件 最 初 用 
来 表示 某 个 di sk 的 完整 复制 。 在 从 原理 的 层面 讲解 这 些 系统 映像 之 前 ， 
可 以 通过 一 种 方式 来 让 读者 对 这 些 文件 有 个 初步 的 感性 认识 〈 下 面 的 操 
作 以 ramdi sk. img 为 例 ， 其 他 映像 文件 也 是 类 似 的 ) 。 

首先 对 ramdi sk. img 执 行 file 命 令 ， 得 到 如 下 结果 : 


$file ramdisk.img 
ramdisk.img: gzip compressed data, from Unix 


这 说 明 它 是 一 个 gZip 的 压缩 文件 。 我 们 将 其 改名 为 
ramdisk. img. gz， 骨 进行 解压 。 具 体 命令 如 下 : 


$gzip -d ramdisk.img.gz 
这 时 会 得 到 另 一 个 名 为 ramdi sk. img 的 文件 ， 不 过 文件 类 型 变 了 : 


$file ramdisk.img 
ramdisk.img: ASCII cpio archive (SVR4 with no CRC) 


由 此 可 知 ， 这 时 的 ramdisk. img 是 CP10 文 件 了 。 
再 来 执行 以 下 操作 : 


$cpio -i -F ramdisk.img 
3544 blocks 


这 样 就 解压 出 了 各 种 文件 和 文件 夹 ， 范 例如 图 2-16 所 示 。 


一 一 一 一 =- 一 
# AD 
E E E E E E i 
data dev proc sbin sys system default prop 


on ea on ea impor on pr # The 
€ 5 4 Jde) 
[j on ea 4 Jde) 
į # cre exoor 0 Idel 


init init.goldfish.rc init.rc init.sun4i.rc init.sundi.usb.rc initlogo.rle ueventd.goldfish.rc 


ueventd.rc ueventd.sun4i.rc 
全 图 2-16 范例 


可 以 清楚 地 看 到 ， 常 用 的 system 目 录 、data 目 录 以 及 init 程 序 〈 系 
统 启 动 过 程 中 运行 的 第 一 个 程序 ) 等 文件 都 包含 在 ramdi sk. img 中 。 


这 样 我 们 可 以 得 出 一 个 大 致 的 结论 ，ramdisk. img 中 存放 的 是 root 


根 目录 的 镜像 〈 编 译 后 可 以 在 
out/target/product/[YOUR_PRODUCT_NAME] root 目录 下 找到 ) 。 


在 Android 系 统 的 启动 过 程 中 发 挥 重要 作用 。 


它 将 


2.5.3 system. img 


要 将 system. img 像 ramdi sk. img 一 样 解压 出 来 会 相对 麻烦 一 些 。 不 
过 万 法 比较 多 ， 除 了 以 下 提 到 的 方式 ， 读 者 还 可 以 尝试 使 用 
unyaffs (参考 http://code. google. com/p/unyaffs/ 或 者 http://code. 
google. com/p/yaffs2utils/) 来 实现 。 

这 里 我 们 采取 mount 的 方法 ， 这 是 目前 最 省 时 省 力 的 解决 方式 。 


步骤 如 下 : 


编译 成 功 后 ， 这 个 工具 的 可 执行 文件 在 out/host/1inux-x86/bin 


源码 目录 system/extras/ext4 utils. 


将 此 工具 复制 到 与 system. img 同 一 目录 人 下。 
执行 如 下 命令 可 以 查询 simg2img 的 用 法 : 


$ ./simg2img --h 
Usage: simg2img <sparse_image_file><raw_image_file> 


对 system. img 执 行 : 
$ ./simg2img system.img system.img.step1 
e mount 
将 上 一 步 得 到 的 文件 通过 以 下 操作 挂 载 到 system_extracted 中 : 


$ mkdir System_extracted 
$ sudo mount -o loop system.img.stepi system_extracted 


最 终 我 们 得 到 如 图 2-17 所 示 的 结果 。 


app bin etc fonts framework lib media 


= = = = = is 
aut 
ro, bu 
H E E E E 
preinstall tts usr vendor xbin build.prop 
全 图 2-17 结果 图 
这 说 明 该 image 文 件 包 含 了 设备 /system 节 点 中 的 相关 内 容 。 
2.5.4 Verified Boot 


Android 领 域 的 开放 性 众生 了 很 多 第 三 方 ROM 的 繁荣 例如 市 面 
上 “五 花 八 门 ” 的 Recovery、 定 制 的 Boot Image, System lmage 等 ) , 
同时 也 给 系统 本 身 的 安全 性 带 来 了 挑战 。 


M4. 4 版 本 开始 ，Android 结 合 Kerne1 的 dm-ver ity 驱 动能 力 实现 了 
一 个 名 为 “Verified Boot” 的 安全 特性 ， 以 期 更 好 地 保护 系统 本 身 免 


受 恶意 程序 的 侵害 。 我 们 在 本 小 节 将 向 大 家 讲解 这 一 特性 的 基本 原理 ， 
以 便 读者 们 在 无 法 成 功利 用 fastboot 写 入 image 时 可 以 清楚 地 知道 隐藏 
在 背后 的 真正 原因 。 


我 们 先 来 熟悉 表 2-8 所 示 的 术语 。 


当 设备 开机 以 后 ， 根 据 Boot State 和 Device State 的 状态 值 不 同 ， 
有 如 图 2-18 所 示 几 种 可 能 性 


表 2-8 Verified Boot 相 关 术 语 


Linux kernel 的 一 个 驱动 ， 用 于 在 运行 时 态 验 证 文件 系 
统 分 区 的 完整 性 (判断 依据 是 Hash Tree 和 Signed 


metadata) 


保护 等 级 ， 分 为 GREEN、YELLOW、ORANGE 和 
RED 四 种 


表明 设备 接受 软件 刷 写 的 程度 ， 通 常 有 LOCKED 和 
UNLOCKED 两 种 状态 


Kos 
a Bootloader 用 于 验证 boot image 的 key 






















Device 
in LOCKED 
state? 






Boot 









Boot partition 


partition verifies against 
verifies certificate 
against OEM embedded in 


key? signature? 


Display Display Display 
notification on warning on warning on 

loading loading loading 

screen screen screen 


Wait for timeout Or if user interaction 
wait until user agrees to continue 


全 图 2-18 Verified Boot 总 体 流 程 
(引用 自 Andtoid 官 方 文档 ) 


最 下 方 的 4 个 圆圈 颜色 分 别 为 : GREEN、YELLOW、RED 和 ORANGE。 例 
如 当前 设备 的 Devi ce State 是 LOCKED， 那 么 就 首先 需要 经 历 0EM KEY 
Verification 如 果 通 过 的 话 Boot State 是 GREEN， 表 示 系 统 是 安全 
的 ; 否则 需要 进入 下 一 轮 的 Signature Verification， 其 结果 决定 了 
Boot State 是 YELLOW 或 者 是 RED 〈 比 较 危险 ) 。 当 然 ， 如 果 当 前 设备 本 
身 就 是 UNLOCKED 的 ， 那 就 不 用 经 过 任何 检验 一 一 不 过 它 和 YELLOW、RED 
一 样 的 地 方 是 ， 都 会 在 屏幕 上 显 式 地 告诫 用 户 潜在 的 各 种 风险 。 部 分 
Android 设 备 还 会 要 求 用 户主 动 做 出 选择 后 才能 正常 启动 ， 如 图 2-19 所 
示 典 型 示例 。 


如 果 设 备 的 Device State 发 生 切 换 的 话 〈fastboot 就 提供 了 类 似 的 
命令 ， 只 不 过 大 部 分 设备 都 需要 解锁 码 才能 完成 ) ， 那 么 系统 中 的 data 
分 区 将 会 被 擦 除 ， 以 保证 用 户 数据 的 安全 。 





Your device has loaded a different Your device has loaded a different 
operating system operating system 


To learn more, visit To learn more, visit 


D: EFS6-D288-218 f 


Your device will boot in 5 seconds 





Your device has been unlocked and 
can't be trusted 


To learn more, visit 


D: EF D2 


Your device will boot in 5 seconds 


Your device has failed verification 
and may not work properly 


To learn more, visit 


Your device will boot in 5 seconds 





全 图 2-19 典型 示例 


我 们 知道 ，Android 系 统 在 局 动 过 程 中 要 经 过 Bootloader->Kerne1- 
>Android 三 个 阶段 ， 因 而 在 Verified Boot 的 设计 中 ， 它 对 分 区 的 看 护 
也 是 环 环 相 扣 的 。 具体 来 说 ，Bootloader 承 担 boot 和 recovery 分 区 的 完 
整 性 校 验 职 责 ; 而 Boot Partition 则 需要 保证 后 续 的 分 区 ， 如 system 的 


安全 性 。 另 外 ，Recovery 的 工作 和 Boot 是 基本 类 似 的 。 


不 过 ， 由 于 分 区 文件 大 小 有 差异 ， 具 体 的 检验 手段 也 是 不 同 的 。 结 
合 前 面 小 节 对 boot. img 的 描述 ， 其 在 增加 了 verified boot 后 的 文件 结 


构 变 化 如 图 2-20 所 示 。 


mkbooting 


Signature | boot signer 





全 图 2-20 文件 结构 变化 


除了 mkboot img 来 生成 原始 的 boot. img 外 ， 编 译 系 统 还 会 调用 另 一 
个 新 工具 ， 即 boot_signer (对 应 源码 目录 system/extras/verity) 来 
在 boot. img 的 尾部 附加 一 个 signature 段 。 这 个 签名 是 针对 boot. img 的 
Hash 结 果 展 开 的 ， 默 认 使 用 的 key 在 /bui 1d/target/product/secur ity 
目录 人 下。 


而 对 于 某 些 大 块 分 区 《如 System Image) ， 则 需要 通过 dm-verity 
来 验证 它们 的 完整 性 。 关 于 dm-ver ity 还 有 非常 多 的 技术 细节 ， 限 于 篇 
幅 我 们 不 做 过 多 讨论 ， 但 强烈 建议 读者 自行 查阅 相关 资料 做 进一步 深入 


学 习 。 


2.6 0DEX 流 程 


0DEX 是 Android 旧 系统 的 一 个 优化 机 制 。 对 于 很 多 开发 人 员 来 说 ， 
0DEX 可 以 说 是 既 熟 悉 又 卫生。 熟悉 的 原因 在 于 目前 很 多 手机 系统 ， 或 者 
APK 中 的 文件 都 从 以 前 的 格式 变 成 了 如 图 2-21 和 图 2-22 所 示 的 样子 。 


而 陌生 的 原因 在 于 有 关 0DEX 的 资料 并 不 是 很 多 ， 不 少 开发 人 员 对 于 
0DEX 是 什么 ， 能 做 什么 以 及 它 的 应 用 流程 并 不 清楚 一 一 这 也 是 我 们 本 小 
节 所 要 向 大 家 阐述 的 内 容 。 





"Oid.policy.jar 
"0id.policy.odex 
DOidtest -kunnek jar 
Did -test .runner.odex 
apache—-xml. jar 


apache—-xml.odex 
bngr. jar 

bmgr .odex 
bouncycastle.jar 
bounc ycast le .odex 


com.android.contacts.separated. jar 
com.android.contacts.separated.odex 





全 图 2-21 系统 目录 system/framewortk 下 的 文件 列表 


0DEX 是 0ptimized Dalvik Executable 的 缩写 ， 从 字面 意思 上 理 
解 ， 就 是 经 过 优化 的 Dalvik 可 执行 文件 。Dalvik 是 Android 系 统 《〈 目 前 
已 经 切换 到 Art 虚 拟 机 ) 中 采用 的 一 种 虚拟 机 ， 因 而 经 过 优化 的 0DEX 文 
件 让 我 们 很 自然 地 想到 可 以 为 虚拟 机 的 运行 带 来 好 处 。 


事实 上 也 的 确 如 此 一 一 0DEX 是 Goog1e 为 了 提高 Android 运 行 效率 做 
出 努力 的 成 果 之 一 。 我 们 知道 ，Android 系 统 中 不 少 代码 是 使 用 Java 语 
言 编写 的 。 编 译 系统 首先 会 将 一 个 Java 文 件 编译 成 class 的 形式 ， 进 而 
再 通过 一 个 名 为 dx 的 工具 来 转换 成 ex 文件， 最 后 将 dex 和 资源 等 文件 压 
缩 成 zip 格 式 的 APK 文 件 。 换 句 话 说， 一 个 典型 的 Android APK 的 组 成 结 
构 如 图 2-23 所 示 。 


Stk.odex 
StreamingProvider.apk 
StreamingProv ider.odex 
SystemUl .apk 

SystemUl .odex 

e lephonyProvider.apk 


e lephonyProv ider.odex 
ouchpalModuleOEM. apk 
ouchpalModuleOEM.odex 
serDict ionaryProvider.apk 





serDictionaryProvider.odex 


全 图 2-22 系统 目录 /system/app 下 的 文件 列表 


APK 组 成 结构 


dex Xf | | Resource(.arsc) 


Resource( 示 经 处 理 的 次 源 文件 ) 


AndroidManifest.xml 


A 2-23 APK 的 组 成 结构 


本 书 的 Android 应 用 程序 编译 和 打包 章节 将 做 更 为 详细 介绍 。 现 在 
大 家 只 要 知道 APK 中 有 哪些 组 成 元 素 就 可 以 了 。 当 应 用 程序 启动 时 ， 系 
统 需要 提取 图 2-23 中 的 dex “如果 之 前 没有 做 过 0DEX 优 化 的 话 ， 或 
者 /data/dalvik-cache 中 没有 对 应 的 0DEX 缓 存 ) ， 然 后 才能 执行 加 载 动 
作 。 而 0DEX 则 是 预先 将 DEX 提 取出 来 ， 并 针对 当前 具体 设备 做 了 优化 工 
作 后 的 产物 ， 这 样 做 除了 能 提高 加 载 速度 外 ， 还 有 如 下 几 个 优势 : 


。 加 大 了 破解 程序 的 难度 


0DEX 是 在 dex 基 础 上 针对 当前 具体 设备 所 做 的 优化 ， 因 而 它 和 生成 
时 所 处 的 具体 设备 有 很 大 关联 。 换 名 话说， 除非 破解 者 能 提供 与 0DEX 生 
成 时 相 匹 配 的 环境 文件 〈 比 如 core. jar, ext. jar, framework. jar, 
services. jar 等 ) ， 否 则 很 难 完成 破解 工作 。 这 就 在 无 形 中 提高 了 系统 
的 安全 性 。 

。 节省 了 存储 空间 

按照 Android 系 统 以 前 的 做 法 ， 不 仅 APK 中 需要 存放 一 个 dex 文 件 ， 

而 且 /data/dalvik-cache 目 录 下 也 会 有 一 个 dex 文 件 ， 这 样 显然 会 浪费 


一 定 的 存储 空间 。 相 比 之 下 ，0DEX 只 有 一 份 ， 而 且 它 比 dex 所 占 的 体积 
更 小 ， 因 而 自然 可 以 为 系统 节省 更 多 的 存储 空间 。 





2.7 0TA 系 统 升 级 
前 面 我 们 讨论 了 系统 包 烧 录 的 几 种 传统 方法 ， 而 Android 系 统 其 实 
还 提供 了 另 一 种 全 新 的 升级 方案 ， 即 0TA (Over the Air) 。0TA 非 常 
灵活 ， 它 既 可 以 实现 完整 的 版 本 升级 ， 也 可 以 做 到 增 量 升级 。 另 外 ， 用 
户 既 可 以 选择 通过 SD 卡 来 做 本 地 升级 ， 也 可 以 直接 采用 网 络 在 线 升级 。 
不 论 是 哪 种 升级 形式 ， 都 可 以 总 结 为 3 个 阶段 : 


。 生成 升级 包 ，; 

。 获取 升级 包 ; 

e 执行 升级 过 程 。 

下 面 我 们 来 逐一 分 析 这 3 个 阶段 。 
2.7.1 生成 升级 包 


升级 包 也 是 由 系统 编译 生成 的 ， 其 编译 过 程 本 质 上 和 普通 Android 
系统 编译 并 没有 太 大 区 别 。 如 果 想 生成 完整 的 升级 包 ， 具 体 命令 如 下 : 


$make otapackage 
9 注意 


生成 0TA 包 的 前 提 是 ， 我 们 已 经 成 功 编译 生成 了 系统 映像 文件 
(system. img 等 ) 。 


最 终 将 生成 以 下 文件 : 
out/target/product/[YOUR_ PRODUCT_NAME]/[YOUR_PRODUCT_NAME]-ota-en 


而 生成 差分 包 的 过 程 相对 麻烦 一 些 ， 不 过 方法 也 很 多 。 以 下 给 出 一 
种 常用 的 方式 : 


° 将 上 一 次 生成 的 完整 升级 包 复 制 并 更 名 到 某 个 目录 下 ， 如 
~/OTA_DIFF/old_target_file. zip; 


° 对 源 文件 进行 修改 后 ， 用 make otapackage 编 译 出 一 个 新 的 0TA 
版 本 ; 


° 将 本 次 生成 的 0TA 包 更 名 后 复制 到 和 上 一 个 升级 包 相 同 的 目录 
下 ， 如 ~ /0OTA_DIFF/ new_target_file. zip; 


e 调用 ota_from _target_files 脚 本 来 生成 最 终 的 差分 包 。 
这 个 脚本 位 于 : 
build/tools/releasetools/ota_from_target_files 


值得 一 提 的 是 ， 完 整 升级 包 的 生成 过 程 其 实 也 使 用 了 这 一 脚本 。 区 
分 的 关键 就 在 于 使 用 时 是 否 提 供 了 -i 参数 。 


其 具体 语法 格式 是 : 
ota_from_target_files [Flags] input_target_files output_ota_packa 
所 有 Flags 人 参数 释义 如 表 2-9 所 示 。 


表 2-9 ota_from target_files 人 参数 


<key> 用 于 包 的 签名 默认 使 用 input_target- 
files 中 的 META/misc_info.txt 文 件 如 果 此 文 
件 不 存在 ， 则 使 用 
build/target/product/security/testkey 





Ete I 生成 差分 包 | 
<file> 


由 此 生成 的 OTA 包 在 安装 时 会 自动 擦 除 user 





data 分 区 


-n (--no_prereq) 忽略 时 间 惟 检查 


Cextra_script) lg <file> py AHE A update IA K ERE 


<file> 


a (maslr_mode) | 是 否 开启 ASLR 技 术 默认 为 开 


<onloff> 





在 这 个 例子 中 ， 我 们 可 以 采用 以 下 命令 生成 一 个 0TA 差 分 包 : 
./build/tools/releasetools/ota_from_target_files-i ~/OTA DIFF/ol 


这 样 生 成 的 update. zip 就 是 最 终 可 用 的 差分 升级 包 。 一 方面 ， 差 分 
升级 包 体 积 较 小 ， 传 输 方 便 ; 但 另 一 方面 ， 它 对 升级 的 设备 有 严格 要 
求 ， 即 必须 是 安装 了 上 一 升级 包 版 本 的 那些 设备 才能 正常 使 用 本 次 的 
0TA 差 分 包 。 


2.7.2 获取 升级 包 


如 图 2-24 所 示 ， 有 两 种 常见 的 渠道 可 以 获取 到 0TA 升 级 包 ， 分 别 是 
在 线 升级 和 本 地 升级 。 





全 图 2-24 获取 OTA 升 级 包 的 两 种 方式 
1. 在 线 升 级 
开发 者 将 编译 生成 的 0TA 包 上 传 至 网 络 存储 服务 器 上 ， 然 后 用 户 可 
以 直接 通过 终端 访问 和 下 载 升 级 文件 。 通 常 我 们 把 下 载 到 的 0TA 包 存储 
在 设备 的 SD 卡 中 。 
在 线 升 级 的 方式 涉及 两 个 核心 因素 。 
。 服务 器 端的 架构 


设备 厂商 需要 架构 服务 器 来 存放 、 管 理 0TA 包 ， 并 为 客户 端 提供 包 
括 查询 在 内 的 多 项 服务 。 


o 客户 端 与 服务 器 的 交互 方式 


客户 终端 如 何 与 服务 器 进行 交互 ， 是 否 需要 认证 ，0TA 包 如 何 传输 
等 都 是 需要 考虑 的 。 


由 此 可 见 ， 在 线 升级 方式 要 求 厂商 提供 较 好 的 硬件 环境 来 解决 用 户 
大 规模 升级 时 可 能 引发 的 问题 ， 因 而 成 本 较 高 。 不 过 这 种 方式 对 消费 者 
来 说 比较 方便 ， 而 且 可 以 实时 掌握 版 本 的 最 新 动态 ， 所 以 对 凝聚 客户 有 
很 大 帮助 。 目 前 很 多 主流 设备 生产 商 〈 如 HTC) 和 第 三 方 的 ROM 开 发 商 
(如 MIUI) 都 提供 了 在 线 升级 模式 。 


服务 器 和 客户 端的 一 种 理论 交互 方案 可 以 参见 图 2-25 所 示 的 图 例 。 
步骤 如 下 : 

在 手动 升级 的 情况 下 ， 由 用 户 发 出 升级 的 指令 ; 而 在 自动 升级 
的 情况 下 ， 则 由 程序 根据 一 定 的 预 设 条 件 来 局 动 升级 流程 。 比 如 设 
定 了 开机 自动 检查 是 否 有 可 用 的 更 新 ， 那 么 每 次 机 器 局 动 后 都 会 去 
服务 器 取得 最 新 的 版 本 信息 。 


无 论 是 手动 还 是 自动 升级 ， 都 必须 通过 服务 器 查询 信息 。 与 服 
务 器 的 连接 方式 是 多 种 多 样 的 ， 由 开发 人 员 自 行 决定 。 在 必要 的 情 


况 下 ， 还 应 该 使 用 加 密 连 接 。 


如 果 一 切 顺 利 ， 我 们 就 得 到 了 服务 器 上 最 新 升级 文件 的 版 本 
号 。 接 下 来 需要 将 这 个 版 本 号 与 本 地 安装 的 系统 版 本 号 进行 比较 ， 
决定 是 否 进 入 下 一 步 操作 。 


如 果 服 务 器 上 的 升级 文件 要 比 本 地 系统 新 在 制定 版 本 号 规则 
时 ， 应 尽量 考虑 如 何 可 以 保证 新 旧版 本 的 快速 比较 ) ， 那 么 升级 继 
续 ; 否则 中 止 升级 流程 一 一 且 若 是 手动 升级 的 情况 ， 一 定 要 提示 用 
户 中 止 的 原因 ， 避 免 造 成 不 好 的 用 户 体 验 。 


升级 文件 一 般 都 比较 大 《Android 系 统 文件 可 能 达到 几 百 
MB) 。 这 么 大 的 数据 量 ， 如 果 是 通过 移动 通信 网 络 
(GSM\WCDMA\CDMA\TD-SCDMA=$) 来 下 载 ， 往 往 不 现实 。 因 此 如 果 
没有 事先 知 会 用 户 而 自动 下 载 的 话 ， 很 可 能 会 引起 用 户 的 不 
满 。“ 提 示 框 ”的 设计 也 要 尽 可 能 便利 ， 如 可 以 让 用 户 快捷 地 局 用 
Wi-Fi 通 道 进 行 下 载 。 


下 载 后 的 升级 文件 需要 存储 在 本 地 设备 中 才能 进入 下 一 步 的 升 
级 。 通 常 这 一 文件 会 直接 被 放置 在 SD 卡 的 根 目 录 下 ， 命 名 为 
update. zip。 


接 下 来 系统 将 自动 重启 ， 并 进入 RecoveryMode 进 行 升级 。 





版 本 检查 \ 
ii ~, 
Yes 


O FENA 
Ge Recovery 模式 


全 图 2-25 在 线 升级 图 例 
2. 本 地 升级 
0TA 升 级 包 并 非 一 定 要 通过 网 络 在 线 的 方式 才 可 以 下 载 到 一 一 只 
条 件 允 许 ， 就 可 以 从 其 他 梁 道 获取 到 升级 文件 update. zip， 并 复制 到 SD 
卡 的 根 目录 下 ， 然 后 手动 进入 升级 模式 〈 见 下 一 小 节 ) 。 


在 线 升 级 和 本 地 升级 各 有 利弊， 开发 商 应 根据 实际 情况 来 提供 最 佳 
的 升级 方式 。 


2.7.3 0TA 升 级 一 一 Recovery 模 式 
经 过 前 面 小 节 的 讲解 ， 现 在 我 们 已 经 准备 好 系统 升级 文件 了 〈 不 论 
是 在 线 还 是 本 地 升级 ) ， 接 下 来 就 进入 0TA 升 级 最 关键 的 阶段 一 一 
Recovery 模 式 ， 也 就 是 大 家 俗称 的 “ 卡 刷 ”。 
Recovery 相 关 的 源码 主要 在 工程 项 目的 如 下 目录 中 : 


\bootable\recovery 


因为 涉及 的 模块 比较 多 ， 这 个 文件 夹 显得 有 点 杂乱 。 我 们 只 挑选 与 
Recovery 刷 机 有 关联 的 部 分 来 进行 重点 分 析 。 









lu Recoverykey 


a 





RecoveryMode 


站 人 指定 进入 
ERRA? 


A 2-26 进入 RecoveryMode 的 流程 


图 2-26 所 示 是 Android 系 统 进 入 RecoveryMode 的 判断 流程 ， 可 见 在 
如 下 两 种 情况 下 设备 会 进入 还 原 模式 。 


o 开机 过 程 中 检测 到 RecoveryKey 按 下 


很 多 Android 设 备 的 RecoveryKey 都 是 电源 和 Volume+ 的 组 合 键 ， 


为 这 两 个 按键 在 大 部 分 设备 上 都 是 存在 的 。 
° 系统 指定 进入 RecoveryMode 

系统 在 茶 些 情况 下 会 主动 要 求 进入 还 原 模式 ， 如 我 们 前 面 讨论 
的 “在 线 升级 ”方式 一 一 当 0TA 包 下 载 完 成 后 ， 系 统 需要 重启 然后 进入 
RecoveryMode 进 行文 件 的 刷 写 。 

当 进 入 RecoveryMode 后 ， 设 备 会 运行 一 个 名 为 “Recovery” 的 程 
序 。 这 个 程序 对 应 的 主要 源码 文件 是 /bootable/recovery/ 
recovery. cpp， 并 且 通 过 如 下 几 个 文件 与 Android 主 系统 进行 沟通 。 

(1) /cache/recovery/command | NPUT 


Android 系 统 发 送 给 recovery 的 命令 行文 件 ， 具 体 命 令 格 式 见 后 面 
的 表格 。 


(2) /cache/recovery/log OUTPUT 
recovery 程 序 输出 的 log 文 件 。 
(3) /cache/recovery/intent OUTPUT 
recovery 传 递 给 Android 的 intent。 
当 Android 系 统 希 望 开 机 进入 还 原 模式 时 ， 它 会 
在 /cache/recovery/command 中 描述 需要 由 Recovery 程 序 完成 的 “ 任 
务 ”。 后 续 Recovery 程 序 通 过 解析 这 个 文件 就 可 以 知道 系统 的 “ 意 
图 ”， 如 表 2-10 所 示 。 


表 2-10 CommandL ine 人 参数 释义 





--Send_intent=anystring 将 text 输 出 到 recovery.intent 中 


ee eee iis | 


擦 除 user data， 然 后 重启 


擦 除 cache (不 包括 user data) , 


l rem 7 
set_encrypted_filesystem=on]|off enable/disable IH i C1 At 


直接 退出 ， 然 后 重启 





由 表格 所 示 的 参数 可 以 知道 Recovery 不 但 负责 0TA 的 升级 ， 而 且 也 
是 “恢复 出 三 设置 ”的 实际 执行 者 ， 如 图 2-27 所 示 。 


Factory data reset 


This will erase all data from your phone's internal storage, 


\cluding 


. Your Google account 


* System and app data and settings 


- Downloaded apps 


Reset phone 





“恢复 出 厂 设置 ” 


中 的 处 理 流程 。 


5 


全 图 2-27 系统 设置 中 的 


接 下 来 分 别 讲解 这 两 个 功能 在 Recovery 程 序 


恢复 出 三 设置 。 
(1) 用 户 在 系统 设置 中 选择 了 “恢复 出 广 设置 ”。 


(2) Android 系 统 在 /cache/recovery/command 中 写 入 “一 - 
wipe data” . 


(3) 设备 重启 后 发 现 了 command 命 令 ， 于 是 进入 recovery。 


(4) recovery 将 在 BCB (bootloader control block) PS 
A “boot-recovery” JA “--wipe data”， 具 体 是 在 get_args 0 HAH 
一 一 这 样 即便 设备 此 时 重启 ， 也 会 再 进入 erase 流 程 。 


(5) 通过 erase volume 来 重新 格式 化 /data。 
(6) 通过 erase_volume 来 重新 格式 化 /cache。 


(7) finish_recovery 将 擦 除 BCB， 这 样 设备 重启 后 就 能 进入 正常 
的 开机 流程 了 。 


(8) maine Wis ArebootKHE. 


上 述 过 程 中 的 BCB 是 专门 用 于 recovery 和 bootloader 间 互相 通信 的 
一 个 flash 块 ， 包 含 了 如 下 信息 : 


struct bootloader_message { 
char command[32]; 
char status[32]; 
char recovery[1024]; 


}; 
依据 前 面 对 Android 系 统 几 大 分 区 的 讲解 ，BCB 数 据 应 该 存放 在 哪个 


image HWe? 没 错 ， 是 mi sc。 
0TA 升 级 具体 如 下 。 


(1)〉0TA 包 的 下 载 过 程 参见 前 一 小 节 的 介绍 。 假 设 包 名 是 
update. zip， 存 储 在 SDCard 中 。 


(2) 系统 在 /cache/recovery/command 中 写 入 "--update package= 


[路 径 名 ] "。 

(3) 系统 重启 后 检测 到 command 命 令 ， 因 而 进入 recovery。 

(4) get_args 将 在 BCB 中 写 入 "boot-recovery” 和 “一 
update_package=..." —— 这 样 即便 此 时 设备 重启 ， 也 会 党 试 重 新 安 
装 0TA 升 级 包 。 

(5) install package 开始 安装 0TA 升 级 包 。 


(6) finish_recovery 擦 除 BCB， 这 样 设备 重启 后 就 可 以 进入 正常 
的 开机 流程 了 。 


(7) WR instal | AMA: 


e prompt_and_wait 显 示 错 误 ， 并 等 待 用 户 响应 ; 
。 用 户 重 启 (比如 拨 掉 电池 等 方式 ) o 


(8) main 调 用 maybe_install_firmware_update，0TA 包 中 还 可 能 
包含 radio/hboot firmware 的 更 新 ， 具 体 过 程 略 。 


(9) main 调 用 reboot 重 启 系 统 。 


总 体 来 说 ， 整 个 Recovery. cpp 源 文件 的 逻辑 层次 比较 清晰 ， 读者 可 
以 基于 上 述 流程 的 描述 来 对 照 并 阅读 代码 。 


2.8 Android 反 编译 


目前 我 们 已 经 学 习 了 Android 原 生态 系统 及 定制 产品 的 编译 和 烧 录 
过 程 。 和 编译 相对 的 ， 却 同样 重要 的 是 反 编译 。 比 如 ， 一 个 优秀 的 “用 
毒 ”高 手 往往 也 会 是 卓越 的 “解毒 ”大 师 ， 反 之 亦 然 。 大 自然 的 一 个 奇 
e ee “相生 相克 ”的 ， 只 有 在 竞争 中 才能 不 断 地 进步 
TE Ro 


首先 要 纠正 不 少 读者 可 能 会 持 有 的 观点 一 一 “ 反 编 译 ” 就 是 去 “ 破 
解 ” 软 件 。 应 该 说 ， 破 解 一 款 软件 的 确 需要 用 到 很 多 反 编 译 的 知识 ， 不 
过 这 并 不 是 它 的 全 部 用 途 。 比 如 笔者 就 曾经 在 开发 过 程 中 利用 反 编 译 畏 
助 解决 了 一 个 bug， 在 这 里 和 读者 分 享 一 下 。 


问题 是 这 样 的 : 开发 人 员 A 修 改 了 framework 中 的 某 个 文件 ， 然 后 通 
过 正常 的 编译 过 程 生 成 了 image， 再 将 其 烧 录 到 了 机 器 上 。 但 奇怪 的 
是 ， 文 件 的 修改 并 没有 体现 出 来 〈 连 新 加 的 1og 也 没有 打印 出 来 ) 。 显 
然 ， 出 现 问 题 的 可 能 是 下 列 步 骤 中 的 任何 一 个 ， 如 图 2-28 所 示 。 





全 图 2-28 可 能 出 现 问题 的 几 个 步骤 
可 疑点 为 : 
o 程序 没有 执行 到 打印 log 的 地 方 


因为 加 1og 的 那个 函数 是 系统 会 频繁 调用 到 的 ， 而 且 1og 就 放 在 函数 
开头 没有 加 任何 判断 ， 所 以 这 个 可 能 性 被 排除 。 


elog 被 屏蔽 


打印 log 所 用 的 方法 与 此 文件 中 其 他 地 方 所 用 的 方法 完全 一 致 ， 而 
且 其 他 地 方 的 1og 确 实 成 功 输 出 了 ， 所 以 也 排除 这 一 可 能 性 。 


。 修改 的 文件 没有 被 编译 到 


虽然 Android 的 编译 系统 非常 强大 ， 但 是 难免 会 有 bug， 因 而 这 个 可 
能 性 还 是 存在 的 。 那 么 如 何 确定 我 们 修改 的 文件 真 的 被 编译 到 了 呢 ? 此 
时 反 编 译 融 有 了 用 武之 地 了 。 


。 文件 确实 被 编译 到 ， 但 是 烧 录 时 出 现 了 问题 


这 并 不 是 空 从 来 风 ， 确 实 发 生 过 开发 人 员 因 为 粗心 大 意 烧 错 版 本 
的 “事故 ”《“ 对 于 采 些 细微 修改 ， 编 译 系统 不 会 主动 产生 新 的 版 本 
号 ) 。 通 过 反 编 译 机 器 上 的 程序 ， 然 后 和 原始 文件 进行 比较 ， 我 们 可 以 
清楚 地 确认 机 器 中 运行 的 程序 是 不 是 预期 的 版 本 。 


由 上 述 分 析 可 知 ， 反 编译 是 确定 该 问题 最 直接 的 方式 。 
Android 反 编译 过 程 按照 目标 的 不 同 分 为 如 下 两 类 〈 都 是 基于 Java 
语言 的 情况 ) 。 
。 APK 应 用 程序 包 的 反 编译 。 
e Android 系 统 包 (如 本 例 中 的 framework) 的 反 编 译 。 
不 论 针 对 哪 种 目标 对 象 ， 它 们 的 步骤 都 可 以 归纳 为 如 图 2-29 所 示 。 


APK 应 用 安装 包 实 际 上 是 一 个 Zip 压 缩 包 ， 使 用 Zip 或 WinRAR 等 软件 
打开 后 里 面 有 一 个 “classes. dex ”文件 一 一 这 是 Dalvik JVM 虚 拟 机 支 
持 的 可 执行 文件 (Dalvik Executable) 。 关 于 这 个 文件 的 生成 过 程 ， 
可 以 参见 本 书 应 用 篇 中 对 APK 编 译 过 程 的 介绍 。 换 名 话说 ，classes. dex 
这 个 文件 包含 了 所 有 的 可 执行 代码 。 





全 图 2-29 反 编 译 的 一 般 流程 


由 前 面 小 节 的 学 习 我 们 知道 ，odex 是 classes. dex 经 过 dex 优 化 
(optimize) 后 产生 的 。 一 方面 ，Dalvik 虚 拟 机 会 根据 运行 需求 对 程序 
进行 合理 优化 ， 并 缓存 结果 ; 另 一 方面 ， 因 为 可 以 直接 访问 到 程序 的 
odex， 而 不 是 通过 解压 缩 包 去 获取 数据 ， 所 以 无 形 中 加 快 了 系统 开机 及 
程序 的 运行 速度 。 


针对 反 编译 过 程 ， 我 们 首先 是 要 取得 程序 的 dex 或 者 odex 文 件 。 如 
果 是 APK 应 用 程序 ， 只 需要 使 用 Zip 工 具 解 压缩 出 其 中 的 classes. dex 即 
可 《有 的 APK 原 始 的 classes. dex 会 被 删除 ， 只 保留 对 应 的 odex 文 件 ) ; 
而 如 果 是 包含 在 系统 image 中 的 系统 包 〈 如 framework 就 是 在 system. img 
中 ) ， 就 需要 通过 其 他 方法 间接 地 将 其 原始 文件 还 原 出 来 。 具 体 步 又 可 
以 参见 前 一 小 节 的 介绍 。 


取得 dex/odex 文 件 后 ， 我 们 将 它 转化 成 Jar 文 件 。 
e odex 


目前 已 经 有 不 少 研究 项 目 在 分 析 Android 的 逆向 工程 ， 其 中 最 著名 
的 就 是 smali/baksmali。 可 以 在 这 里 下 载 到 它 的 最 新 版 本 : 


http://code.google.com/p/smali/downloads/list 


“smali” #0 “baksmali” 475 Xt yak Siz 
中 “assembler” 和 “disassembler”。 为 什么 要 用 冰岛 语 命名 呢 ? = 
案 就 是 Dalvik 这 个 名 字 实 际 上 是 冰岛 的 一 个 小 渔村 。 


如 果 是 odex， 需 要 先 用 baksmal i 将 其 转换 成 dex。 具 体 语法 如 下 : 


$ baksmali -a <api_level> -x <odex_file> -d <framework_dir> 


-ajg Œ [API Leve1，-x 表 示 目 标 odex 文 件 ，-d 指 明了 framework 路 
径 。 因 为 这 个 工具 需要 用 到 诸如 core. jar, ext. jar, framework. jar 等 
一 系列 framework 包 ， 所 以 建议 读者 直接 在 Android 源 码 工程 中 out 目 录 
下 的 system/framework 中 进行 操作 ， 或 者 把 所 需 文件 统一 复制 到 同一 个 
目录 下 。 


范例 如 下 《1. 4. 1 版 本 ) : 


$ java -jar baksmali-1.4.1.jar -a 16 -x example.odex 


如 果 是 要 反 编译 系统 包 中 的 odex (如 services. odex) ， 请 参考 以 


下 命令 : 


$java -Xmx512m -jar baksmali-1.4.1.jar -a 16 -c:core.jar:bouncyca 
jar:android.policy.jar:services.jar:core-junit.jar -d framework/ 


更 多 语法 规则 可 以 通过 以 下 命令 获取 : 
$ java -jar baksmali-1.4.1.jar --help 


执行 结果 会 被 保存 在 一 个 out 目 录 中 ， 里 面包 含 了 与 odex 相 应 的 所 
有 源码 ， 只 不 过 由 smali 语 法 描述 。 读 者 如 果 有 兴趣 的 话 ， 可 以 阅读 以 
下 文档 来 了 解 smal i 语法 : 


http://code.google.com/p/smali/wiki/TypesMethodsAndFields 


当然 对 于 大 部 分 开发 人 员 来 说 ， 还 是 希望 能 反 编 译 出 最 原始 的 Java 
语言 文件 。 此 时 就 要 再 将 smal i 文件 转化 成 dex 文 件 。 具 体 命令 如 下 : 


$ java -jar smali-1.4.1.jar out/ -o services.dex 


于 是 接 下 来 的 流程 就 是 dex 一 Java， 请 参考 下 面 的 说 明 。 
e dex 


前 面 我 们 已 经 成 功 将 odex“ 去 优化 ”成 dex 了 ， 离 胜利 还 有 一 步 之 
遥 一 一 将 dex 转 化 成 jar 文 件 。 目 前 比较 流行 的 工具 是 dex2jar， 可 以 在 
这 里 下 载 到 它 的 最 新 版 本 : 


http://code. google. com/p/dex2 jar /downloads/| ist 


使 用 方法 也 很 简单 ， 具 体 范 例如 下 : 
$ ./dex2jar.sh services.dex 


上 面 的 命令 将 生成 services_dex2jar. jar， 这 个 Jar 包 中 包含 的 就 
是 我 们 想 要 的 原始 Java 文 件 。 那 么 ， 选 择 什么 工具 来 阅读 Jar 中 的 内 容 
E? 在 本 例 中 ， 我 们 只 是 希望 确定 所 加 的 1og 是 否 被 正确 编译 进 目标 文 
件 中 ， 因 而 可 以 使 用 任何 常用 的 文本 编辑 器 查阅 代码 。 而 如 果 希 望 能 更 
方便 地 阅读 代码 ， 推 荐 使 用 jd-gui， 它 是 一 款 图 形 化 的 反 编译 代码 阅读 
工具 。 


这 样 ， 整 个 反 编译 过 程 就 完成 了 。 


顺便 提 一 下 ， 目 前 ， 几 乎 所 有 的 Android 程 序 在 编译 时 都 使 用 
了 “代码 混淆 ”技术 ， 反 编译 后 的 结果 和 原始 代码 还 是 有 一 定 差距 ， 但 
“影响 我 们 理解 程序 的 主体 架构 。“ 代 码 混淆 ”可 以 有 效 地 保护 知识 产 
权 ， 防 止 某 些 不 法 分 子 恶 意 旭 窃 ， 或 者 自 改 源码 〈 如 添加 广告 代码 、 植 
入 木马 等 ) ， 建 议 大 家 在 实际 的 项 目 开发 中 尽量 采用 。 


2.9 NDK Build 


我 们 知道 Android 系 统 下 的 应 用 程序 主要 是 由 Java 语 言 开 发 的 ， 但 
这 并 不 代表 它 不 支持 其 他 语言 ， 比 如 C++ 和 C。 事 实 上 ， 不 同类 型 的 应 用 
程序 对 编程 语言 的 诉求 是 有 区 别 的 一 一 普通 App1ication 的 U1 界面 基本 
上 是 静态 的 ， 所 以 ， 利 用 Java 开 发 更 有 优势 ; 而 游戏 程序 ， 以 及 其 他 需 
要 基于 0penGL (或 基于 各 种 Game Engine) 来 绘制 动态 宽 面 的 应 用 程序 
则 更 适合 采用 0 或 者 C++ 语言 。 


伴随 着 Android 系 统 的 不 断 发 展 ， 开 发 者 对 于 C/C++ 语言 的 需求 越 来 
越 多 ， 也 使 得 Goog1e 需 要 不 断 完善 它 所 提供 的 NDK 工 具 链 。NDK 的 全 称 是 
Native Development Kit， 可 以 有 效 支 撑 Android 系 统 中 使 用 C/C++ 等 
Native 语 言 进行 开发 ， 从 而 让 开发 者 可 以 : 


。 提高 程序 运行 效率 
完成 同样 的 功能 ，Java 虚 拟 机 理论 上 来 说 比 C/C++ 要 耗费 更 多 的 系 


统 资 源 。 因 而 ， 如 果 程 序 本 身 对 运行 性 能 要 求 很 高 的 话 ， 建 议 利用 NDK 
进行 开发 。 


。 复 用 已 有 的 C 和 和 C+ 十 库 
好 处 是 显而易见 ， 即 最 大 程度 地 避免 重复 性 开发 。 
NDK 的 官方 网 址 是 : 


https://developer.android.com/ndk/index. html 


它 的 安装 很 简单 ， 在 Wi ndows 下 只 要 下 载 一 个 几 百 MB 的 自 解 压 包 然 
后 双击 打开 它 就 可 以 了 。NDK 文 件 夹 可 以 被 放置 到 磁盘 中 的 任何 位 置 ， 
不 过 为 了 操作 方便 ， 建 议 开发 者 可 以 设置 系统 环境 变量 来 指向 其 中 的 关 
键 程序 。NDK 既 支持 Java 和 0/C++ 混 合 编程 的 模式 ， 也 允许 我 们 只 开发 纯 
Native 实 现 的 程序 。 前 者 需要 用 到 JN1 技 术 ( 即 Java Native 
Interface) ， 它 的 神奇 之 处 在 于 可 以 让 两 种 看 似 没有 瓜葛 的 语言 间 进 行 
无 颖 的 调用 。 例 如 下 面 是 一 个 JN1 的 实例 : 


public class MyActivity extends Activity { 
类 大 


* Native method implemented in C/C++ 
*/ 
public <strong>native</strong> void jniMethodExample( ); 


MyActivity 是 一 个 Java 类 ， 它 的 内 部 包含 一 个 声明 为 Native 的 成 员 
变量 ， 即 jniMethodExample。 这 个 函数 的 实现 是 通过 C/C++ 完 成 的 ， 并 
被 编译 成 so 库 来 供 程 序 加 载 使 用 。 更 多 JN1 的 细节 ， 我 们 将 在 后 续 章节 
进行 详细 介绍 。 


本 小 证 我 们 将 通过 一 个 具体 实例 来 着重 讲解 如 何 利 用 NDK 来 为 应 用 
程序 执行 Cb/C++ 的 编译 。 


在 此 之 前 ， 请 确保 你 已 经 下 载 并 解压 了 NDK 包 ， 并 为 它 设置 了 正确 
jean ae 这 个 例子 中 将 包含 如 下 几 个 文件 ， 我 们 统一 放 在 一 个 
NILH i 


e Android.mk; 
e Application.mk; 
e testNative.cppo 


Android. mk 用 于 描述 一 个 Android 的 模块 ， 包 括 应 用 程序 、 动 态 
库 、 静 态 库 等 。 它 和 我 们 本 章节 讲解 的 用 法 基本 一 致 ， 因 而 不 再 袭 述 。 


Appl ication. mk 用 于 描述 你 的 程序 中 所 用 到 的 各 个 Native 模 块 〈 可 
以 是 静态 或 者 动态 库 ， 或 者 可 执行 程序 ) 。 这 个 脚本 中 常用 的 变量 不 
多 ， 我 们 从 中 挑选 几 个 核心 的 来 讲解 : 


1. APP_PROJECT_PATH 


指向 程序 的 根 目 录 。 当 然 ， 如 果 你 是 按照 Android 系 统 默 认 的 结构 
来 组 织 工程 文件 的 话 ， 这 个 变量 是 可 选 的 。 


2. APP_OPTIM 


用 于 指示 当前 是 release 或 者 debug 版 本 。 前 者 是 默认 的 值 ， 将 会 
成 优化 程度 较 高 的 二 进 制 文件 ; 调试 模式 则 会 生成 未 优化 的 版 本 ， 以 便 
保留 更 多 的 信息 来 帮助 开发 者 追踪 问题 。 在 AndroidManifest. xml Ay 
《app1lication》 标 签 中 声明 android:debuggable 会 将 默认 值 变 更 为 


debug， 不 过 APP_0PTIM 的 优先 级 更 高 ， 可 以 重 载 debuggable 的 设置 。 
3. APP_CFLAGS 

设置 对 全 体 module 有 效 的 0/C++ 编 译 标志 。 
4. APP_LDFLAGS 


用 于 描述 一 系列 链接 器 标志 ， 不 过 只 对 动态 链接 库 和 可 执行 程序 有 
效 。 如 果 是 静态 链接 库 的 情况 ， 系 统 将 忽略 这 个 值 。 


5. APP_ABI 


用 于 指示 编译 所 针对 的 目标 Application Binary Interface, RATA 
值 是 armeabi。 可 选 值 如 表 2-11 所 示 。 


表 2-11 可 选 值 


APP ABI := arm64- 
v8a 





Ws (r6) we := mips64 


All supported instruction sets APP_ABI := all 





文件 testNative. cpp 中 的 内 容 就 是 程序 的 源码 实现 ， 对 此 NDK 官 方 
提供 了 较为 完整 的 Samp les 供 大 家 人 参考， 涵盖 了 0penGL、Audio、Std 等 
多 个 方面 ， 有 兴趣 的 读者 可 以 自行 下 载 分 析 。 

那么 有 了 这 些 文件 后 ， 如 何 利 用 NDK 把 它们 编译 成 最 终 产 物 呢 ? 

最 简单 的 方式 就 是 采用 如 下 的 命令 : 


cd <project> 
$ <ndk>/ndk-build 


其 中 ndk-bui 1d 是 一 个 脚本 ， 等 价 于 : 


$GNUMAKE -f <ndk>/build/core/build-local.mk 
<parameters> 


<ndk> 指 的 是 NDK 的 安装 路 径 。 


可 见 使 用 NDK 来 编译 还 是 相当 简单 的 。 另 外 ， 除 了 常规 的 编译 外 ， 
ndk-bui1d 还 支持 多 种 选项 ， 璧 如 


“clean” 表 示 清 理 掉 之 前 编译 所 产生 的 各 种 中 间 文 件 ; 
“-B” 会 强制 发 起 一 次 完整 的 编译 流程 ; 
“NDK_L0G=1” 用 于 打开 NDK 的 内 部 1og 消 息 ; 


2.10 第 三 方 ROM 的 移植 


除了 本 章 所 描述 的 Android 原 生 代 码 外 ， 开 发 人 员 也 可 以 选择 一 些 
知名 的 第 三 方 开源 ROM 来 进行 学 习 ， 和 譬如 CyanogenMod。 


CyanogenMod (FROM) 的 官方 网 址 如 下 : 
http://www. cyanogenmod. org/ 


它 目前 的 最 新 版 本 是 基于 Android 6. 0 的 CM 13， 并 同时 支持 Google 
Nexus、HTC、Huawei 、L6G 等 多 个 品牌 的 众多 设备 。CyanogenMod 的 初衷 
是 将 Android 系 统 移植 到 更 多 的 没有 得 到 Google 官 方 支持 的 设备 中 ， 所 
ie 时 候 CM 针 对 某 特 定 设备 的 版 本 更 新 时 间 可 能 比 设备 厂商 来 得 还 要 


那么 cyanogenMod 是 如 何 做 到 针对 多 种 设备 的 移植 和 适 配 工作 的 呢 ? 
我 们 将 在 接 下 来 的 内 容 中 为 大 家 揭 开 这 个 问题 的 答案 。 图 2-30 是 CM 的 整 
体 摘 述 图 。 
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从 图 2-30 CM 的 整体 档 述 
下 面 我 们 分 步骤 进行 讲解 。 
Step1， 前 期 准备 
在 做 Porting 之 前 ， 有 一 些 准备 工作 需要 我 们 去 完成 。 


(1) 获取 设备 的 Product Name, Code Name, Platform 
Architecture, Memory Size, Internal Storage Size 等 信息 


这 些 数据 有 很 多 可 以 从 /system/bui1d. prop 文 件 中 获得 ， 不 过 前 提 
条 件 是 手机 需要 被 root 。 


(2) 收集 设备 对 应 的 内 核 源 码 


根据 GPL 开源 协议 的 规定 ，Android 厂 商 必 须 公 布 受 GPL 协议 保护 的 
内 容 ， 包 括 内 核 源 码 。 因 而 实现 这 一 步 是 可 行 的 ， 只 是 可 能 会 费 些 周 
折 。 


(3) 获取 设备 的 分 区 信息 


Step2， 建 立 3 个 核心 文件 夹 


e device/ [vendot]/[codename]/ 
设备 特有 的 配置 和 代码 将 保存 在 这 个 路 径 下 。 
e vendor/[vendor] /[codename]/ 


这 个 文件 夹 中 的 内 容 是 从 原始 设备 中 拉 取 出 来 的 ， 由 此 可 见 主要 是 
那些 没有 源 代 码 可 以 生成 的 部 分 ， 例 如 一 些 二 进 制 文 件 。 


e kernel/[vendor]/[codename]/ 
专门 用 于 保存 内 核 版 本 源码 的 地 方 。 


CM 提 供 了 一 个 名 为 mkvendor. sh 的 脚本 来 帮助 创建 上 述 文件 夹 
的 “雏形 ”， 有 兴趣 的 读者 可 以 参见 bui 1d/tools/device/mkvendor. sh 
文件 。 不 过 很 多 情况 下 还 需要 开发 者 手工 修改 其 中 的 部 分 文件 ， 例 如 
device H  FAYBoardConfig.mk, device _[codename].mk, cm. mk, 
recovery. fstab 等 核心 文件 。 


Step3. 编译 一 个 用 于 测试 的 recovery image 


编译 过 程 和 普通 CM 编译 的 最 大 区 别 在 于 选择 make recoveryimage. 
如 果 在 recovery 模 式 下 发 现 Android 设 备 的 硬件 按键 无 法 使 用 ， 那 么 可 
以 尝试 修改 /device/ [vendor]/[codename|/recovery/ 
recovery_ui. cpp 中 的 GP10 配 置 。 


Step4. 为 上 述 的 device 目 录 建 立 github 仓 库 ， 以 便 其 他 人 可 以 访 
问 到 。 


Step5. 填充 vendor 目 录 


可 以 参考 CM 官网 上 成 熟 的 设备 范例 提供 的 extract-files. sh 和 
setup-makefiles. sh， 并 据 此 完成 适合 自己 的 这 两 个 脚本 。 


Step6， 通 过 CM 提供 的 编译 命令 最 终 编译 出 ROM 升 级 包 ， 并 利用 前 面 
生成 的 recovery 来 将 其 刷 入 到 设备 中 。 这 个 过 程 很 可 能 不 是 “一 距 而 
就 ”的 ， 需 要 不 断 调试 和 修改 ， 直 至 成 功 。 


当然 ， 限 于 篇 幅 我 们 在 本 小 节 只 是 讲解 了 CM 升级 包 的 核心 制作 过 
程 ， 读 者 如 果 有 兴趣 的 话 可 以 查阅 http://www. cyanogenmod. org/ 来 获 
取 更 多 细节 详情 。 
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3.1 MakefileAT] 


如 果 读 者 曾 在 Linux 环 境 下 开发 过 程序 ， 那 么 对 Makefi le 一 定 不 会 
陌生 。 简 单 而 言 ，Makefi le 提供 了 一 种 机 制 ， 让 使 用 者 可 以 有 效 地 组 
织 “ 工 作 ”。 注 意 这 里 只 使 用 “工作 ”这 个 词 ， 而 不 是 “编译 ”。 这 是 
因为 Makefi le 并 不 一 定 是 用 来 完成 编译 工作 。 事 实 上 它 本 身 只 是 一 
种 “规则 ”的 执行 者 ， 而 使 用 者 具体 通过 它 来 做 什么 则 没有 任何 限制 。 
如 既 可 以 用 它 来 架构 编译 系统 ， 也 能 用 来 生成 文档 ， 或 者 单纯 地 打印 


log 等 。 


从 中 可 以 看 出 ， 理 解 Makefi le 的 “规则 ” 才 是 我 们 学 习 的 重点 。 只 
要 学 会 了 “ 渔 ”， 自 然 就 什么 “ 鱼 ” 都 不 缺 了 。 


和 shel11、python 等 类 似 ，Makefile 也 是 一 个 脚本 ， 由 make 程 序 来 
解析 。 目 前 软件 行业 有 多 款 优秀 的 make 解 析 程 序 ， 如 GNU 
make (Android 中 采用 的 ) 、Visual Studio 中 的 nmake 等 。 尽 管 在 表现 
形式 上 会 有 些 差 异 ， 但 “万 变 不 离 其 宗 ”， 它 们 都 是 通过 以 下 基础 规则 
扩展 起 来 的 : 


TARGET: PREREQUISITES 
COMMANDS 


每 个 COMMAND 前 都 必须 有 一 个 TAB 制 表 符 。 

这 个 看 起 来 简单 得 不 能 再 简单 的 规则 ， 在 经 过 一 次 次 的 扩展 修饰 
后 ， 便 构建 成 最 终 我 们 看 到 的 各 种 庞大 工程 的 编译 系统 。 在 Makefi led 
则 中 ，TARGET 是 需要 生成 的 目标 文件 ，PREREQUISITES 代 表 了 目标 所 依 
赖 的 所 有 文件 。 当 PREREQUISITES 文 件 中 有 任何 一 个 比 TARGET 新 时 ， 那 
么 都 会 触发 下 面 COMMAND 命 令 的 执行 。COMMAND 的 具体 内 容 取决 于 使 用 者 
的 需求 ， 如 调用 GCC 编译 器 、 生 成 某 个 文档 等 。 


下 面 我 们 通过 一 个 简单 的 例子 (Linux 环 境 下 ， 采 用 GCC 编 译 器 来 生 
成 一 个 可 运行 程序 ) 来 讲解 这 个 规则 的 使 用 方法 。 


范例 项 目 包 括 的 主要 工程 文件 和 说 明 如 表 3-1 所 示 。 
表 3-1 ”工程 文件 和 说 明 


| | 
ee Ei FEE 
ty ty 提供 了 一 个 测试 函数 〈getNumber) 的 声明 


提供 了 子 数 getrNumber 的 实现 。getrNumber 函 数 只 是 简 
单 地 返回 一 个 值 ， 没 有 其 他 特别 的 功能 


Makefilel| 用 于 编译 整个 工程 


我 们 先 来 看 一 下 各 工程 文件 中 主要 的 源码 节选 
(1) main. c 中 将 打印 一 条 语句 ， 输 出 getNumber () 函数 的 返回 值 。 





#include <stdio.h> 
#include “utility.h" 


int main(int argc, char *argv[]) 


printf("Hello, getNumber=%d\n", getNumber()); 
return 0; 
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(2) utility. hB, MME getNumberi#7F T eA AGAR. 


1 hnt getNumber(); 
2 


(3) utility.c 中 ， 给 出 了 getNumber 的 函数 实现 。 


#include “utility.h" 


int getNumber() 


{ 
return 2; 


(4) Makefi le 文件 ， 是 编译 过 程 的 “规划 者 ”。 


“DPIWN 


1 SimpleMakefile:main.o utility.o 

2 gcc -o SimpleMakefile main.o utility.o 
3 

4 main.o:main.c 

5 gcc -c main.c 

6 

7 utility.o:utility.c 

8 gcc -c utility.c 

9 

10 


根据 前 面 提 到 的 “基础 规则 ”， 这 个 脚本 共有 3 个 TARGET， 即 
SimpleMakefile、main.o 及 utility.o。 其 中 SimpleMakefile 依 赖 于 后 
两 者 ， 而 main. offuti lity. o 则 又 分 别 由 对 应 的 C 文 件 编译 生成 。 


最 后 我 们 通过 调用 make 命 令 来 生成 SimpleMakefi le 可 执行 文件 。 运 


行 结果 如 下 : 


ding/Foundation Ex01 SimpleMakefile$ ./SimpleMakefile 





Hello, getNumber=2 


这 是 一 个 非常 简单 的 Makefi le 示例 ， 但 “ 麻 八 哩 小 ， 五 脏 俱 全 ”， 
它 向 我 们 清晰 地 展示 了 一 个 Makefi1e 的 编写 过 程 。Make 工 具 本 身 是 非常 
强大 的 ， 有 很 多 隐 含 规则 来 帮助 开发 者 快速 构建 一 个 复杂 的 编译 体系 。 
如 利用 它 的 自动 推导 功能 ， 可 以 简化 对 象 间 的 依赖 关系 ; 还 可 以 加 入 各 
种 变量 以 避免 多 次 重复 输入 。 如 下 面 就 是 Simp leMakefi le 程序 的 另 一 个 
Makefile 版 本 ， 和 前 一 个 相 比 显然 更 简洁 明了 。 


1 OBJECT = main.o utility.o 
2 
3 SimpleMakefile:$(OBJECT) 
4 gcc -o SimpleMakefile $(OBJECT) 
5 
6 
另外 ， 我 们 还 需要 不 断 熟 悉 Android 编 译 系统 中 常见 的 一 些 


Makefi le 的 高 级 用 法 。 例 如 下 面 这 两 种 。 
(1) Target-Specific Variable 


这 是 一 种 局 部 作用 域 的 变量 ， 它 只 对 特定 的 目标 起 效果 。 壁 如 下 面 
这 个 例子 中 的 PRIVATE_DEX_F1LE 变 量 : 


/*build/core/package_internal.mk*/ 
ifdef LOCAL_DEX_PREOPT 
$(built_odex): <strong>PRIVATE_DEX_FILE</strong> := $(built_dex) 
# Use pattern rule - we may have multiple built odex files. 
$(built_odex) : $(dir $(LOCAL_BUILT_MODULE) )% : $(built_dex) 
$(hide) mkdir -p $(dir $Q) && rm -f $@ 
$(add-dex-to-package) 
$(hide) mv $@ $@.input 
$(call dexpreopt-one-file, $@.input, $@) 
$(hide) rm $@. input 
endif 


我 们 知道 ，Make 会 首先 构建 出 依赖 树 ， 然 后 才 会 根据 用 户 选 择 目标 
来 执行 相应 的 编译 操作 。 换 句 话 说， 当 Make 执 行 到 上 述 脚本 语句 时 ， 并 
不 会 触发 COMMANDS 部 分 的 执行 。 那 么 如 果 我 们 直接 在 COMMANDS 《在 这 个 


场景 中 ，add-dex-to-package 会 调用 到 PRIVATE_DEX_FILE) 中 使 用 
$ (bui1t_dex) 这 种 全 局 变量 会 发 生 什 么 事 呢 ? 


因为 package_internal. mk 是 APK 编 译 模 板 的 内 部 实现 〈 可 以 参考 后 
续 小 节 的 介绍 ) ， 所 以 它 在 整个 系统 编译 过 程 中 会 被 多 次 调用 。 换 句 话 
it, $(built_dex) 的 值 是 不 断 在 变化 中 的 。 而 当 原 先 的 $ (bui 1t_odex) 
在 执行 自己 的 COMMANDS 时 ，$ (bui 1t_dex) 的 值 早 已 经 “ 物 是 人 非 ” 了 ， 
所 以 ， 在 COMMANDS 中 直接 调用 它 有 可 能 导致 不 可 预期 的 错误 。 例 如 
PRIVATE_DEX_F1LE 就 是 属于 $ (bui 1t_odex) 规则 中 的 特定 私有 变量 (这 
也 是 变量 名 中 “PRIVATE” 所 表达 的 含义 ) 。 因 而 ， 无 论 外 宽 环 境 如 何 
变化 ，PRIVATE_DEX_FILE 的 值 在 定义 它 的 目标 规则 中 都 是 不 变 的 ， 这 样 
一 来 就 有 效 保证 了 编译 执行 阶段 的 准确 性 。 


(2) Static Pattern Rules 


另 一 个 Android 编 译 脚本 中 常见 的 Makefi le 语法 是 Static Pattern 


Rules。 它 的 典型 格式 中 带 有 两 个 “:”， 如 下 所 示 : 
TARGETS ...: TARGET-PATTERN: DEP-PATTERNS ... 
COMMANDS 


nee ee 目标 的 场景 。 如 下 所 示 就 是 一 个 简单 
的 范例 : 


foo.o tcc.o bar.o : %.0 : %.c 


在 这 个 例子 中 ，TARGET-PATTERN 带 有 一 个 “%”， 它 与 TARGETS 集 合 
中 的 元 素 进 行 匹 配 ， 便 可 以 得 到 词 干 (STEM) : foo tcc bar ;得 到 的 词 
干 再 和 DEP-PATTERNS 中 的 “%” 进 行 组 合 ， 从 而 为 不 同 目标 生成 正确 的 
依赖 对 象 (foo. c tcc.c bar.c) o 


除 此 之 外 ，WMakef i le 实际 上 还 有 很 多 高 级 用 法 和 规则 ， 和 希望 读者 能 
自行 查阅 相关 资料 做 进一步 了 解 ， 以 便 为 后 续 更 好 地 理解 Android 编 译 
系统 打下 坚实 的 基础 。 


3.2 Android 编译 系统 


很 多 人 在 初次 分 析 Android 的 编译 系统 时 ， 都 会 有 一 种 感觉 一 一 这 
是 一 头 让 人 “胆寒 的 怪兽 ”。 因 为 它 正 好 符合 怪兽 的 两 个 特点 ， 即 功力 
深厚 且 体 积 庞大 ， 甚 至 可 以 说 有 点 妥 肿 。 这 在 一 定 程度 上 也 加 重 了 我 们 
分 析 它 内 部 结构 的 难度 。 就 如 同 漫 步 在 崇山峻岭 或 深山 野 林 一 般 ， 如 果 
缺乏 很 明确 的 指引 ， 那 么 稍 有 不 愤 便 会 迷失 方向 。 


事实 上 Android 编 译 系统 也 是 经 过 了 数 次 不 断 地 迭代 演进 ， 才 成 长 
为 今天 大 家 所 看 到 的 “怪兽 ”。 特 别 是 在 Google 收 购 Android 系 统 不 久 
后 的 2006 年 ， 他 们 曾 对 编译 系统 动 过 一 次 “大 手术 ”。 核 心目 标 有 两 
D: 


。 让 依赖 关系 分 析 更 为 可 靠 ， 以 保证 可 以 正确 判断 出 需要 被 编译 的 模 
KR; 
。 让 不 必要 被 编译 的 模块 也 可 以 被 准确 判断 出 来 ， 以 提高 编译 效率 。 


在 那 次 重 构 中 ，Android 遵 循 了 多 个 设计 原则 和 策略 ， 包 括 但 不 限 
于 : 


(1) 同一 套 代码 支持 编译 出 不 同 的 构建 目标 。 例 如 既 可 以 编译 出 
运行 于 设备 端的 软件 包 ， 也 可 以 编译 出 Host 平 台 上 的 各 种 工具 模拟 
器 、 辅 助 工 具 等 ) 。 


(2) Non-Recursive Make: 1997 年 的 时 候 有 一 篇 非常 有 名 的 论 
文 ， 名 为 《Recursive Make Considered Harmful》， 其 核心 思想 是 我 
们 在 大 型 项 目 中 应 该 采用 唯一 的 Makefi le 来 组 织 所 有 文件 的 自动 化 编 
译 ， 并 对 比 了 它 和 传统 的 多 Makefi le 的 优势 。 相 信 这 篇 论文 对 当年 重 构 
过 程 起 到 了 很 大 的 影响 ， 可 以 说 直到 今天 ，Android 编 译 系 统 的 主体 框 
架 还 是 采用 Non-Recursive 的 方式 。 有 兴趣 的 读者 可 以 阅读 一 下 这 篇 论 
Mo 

(3) 可 以 对 项 目 中 的 任意 模块 进行 单独 的 编译 验证 。 比 如 我 们 只 
更 改 了 Art 虚 拟 机 所 对 应 的 1ibart. so， 那 么 就 应 该 能 做 到 只 以 这 个 so 库 
为 中 心 来 开展 编译 工作 ， 而 不 需要 每 次 都 是 整个 项 目 编译 。 


(4) 编译 所 产生 的 中 间 过 程 文 件 ， 以 及 最 终 的 编译 结果 和 源 代码 


需要 在 存储 目录 上 分 离 等 。 


在 本 节 内 容 的 组 织 上 ， 我 们 将 采取 由 上 而 下 、 由 整体 到 局 部 的 方式 
将 Android 编 译 系 统 所 涉及 的 各 个 重要 方面 一 一 理 顺 。 和 希望 通过 这 种 分 
析 手 法 ， 让 读者 可 以 逐步 摸 清 整个 编译 机 制 的 内 部 架构 ， 而 不 致 牵 绊 于 
各 种 宏 、 函 数 、 变 量 、 目 录 结 构 等 细 枝 末节 。 另 外 ， 和 希望 读者 在 阅读 接 
下 来 内 容 的 过 程 中 还 可 以 同步 思考 一 下 编译 系统 的 几 个 设计 原则 具体 是 
如 何 实现 的 ， 以 期 达到 触 类 旁 通 的 效果 。 


3.2.1 Makefile 依 赖 树 的 概念 

细心 的 读者 应 该 已 经 注意 到 了 ， 前 一 小 节 的 SimpleMakefile 中 各 
TARGET 的 依赖 关系 实际 上 可 以 组 成 一 棵 树 ， 本 书 将 其 称 为 “Makefile 依 
赖 树 ”。 


”我 们 仍 以 上 一 小 布 的 工程 项 目 为 例 ， 给 出 它 的 依赖 树 ， 如 图 3-1 所 
示 。 





SimpleMaketile 





全 图 3-1 SimpleMakefile 的 依赖 树 


这 种 树 型 结构 为 我 们 按照 由 上 而 下 的 顺序 分 析 Android 编 译 系 统 提 
供 了 可 能 ， 接 下 来 几 个 小 市 的 内 容 就 是 由 此 展开 的 。 


3.2.2 Android 编译 系统 抽象 模型 
我 们 对 Android 编 译 系 统 进 行 抽象 ， 其 顶层 模型 如 图 3-2 所 示 。 


We a 





全 图 3-2 Andtoid 编 译 系统 的 抽象 模型 


因为 是 基于 Makefi le 实现 的 ， 所 以 ， 整 个 编译 系统 的 核心 仍然 是 如 
何 有 效 地 构建 出 依赖 树 ; Android 系 统 的 编 i FEH M Java, C/C++ 等 多 
种 语言 ， 而 且 还 分 为 Host 和 Target 等 不 同 的 目标 平 因而 它 的 运行 环 
境 相对 复杂 ， 需 要 我 们 在 初始 化 环节 做 好 环境 的 搭建 工作 《例如 当前 的 
JDK 和 Make 的 版 本 是 否 满足 要 求 ) ; 编译 的 执行 过 程 本 质 上 和 传统 的 
Make 实 现 没 有 太 大 差异 ， 只 不 过 因为 Android 工 程 非常 庞大 ， 所 以 初学 
者 往往 很 难 在 短 时 间 内 全 部 掌握 ; 编译 系统 的 另 一 个 重要 任务 则 是 打 
包 ， 包 括 system. img, boot. img, userdata. img 等 ， 我 们 在 后 续 小 节 会 
有 更 深入 的 分 析 。 
3.2.3 树 根 节 点 droid 
树 根 节点 一 定 是 整个 编译 系统 的 最 终 目标 产物 吗 ? 
答案 既 可 能 是 肯定 的 ， 也 可 能 是 否定 的 。 
定 的 一 面 ， 是 因为 有 些 树 根 节点 〈 比 如 SimpleMakefile) 确实 是 
en Tne 目标 产物 ” 一 一 它 是 真实 存在 的 “生成 物 ”; 而 更 多 
RAT, 特别 是 对 Android 系 统 这 种 庞然大物 而 言 ， 它 的 树 根 节 点 往往 


只 是 一 个 “ 伪 目 标 ” 一 一 它 的 确 是 代表 了 编译 系统 的 “终极 目标 意 
ka” , 本 身 I 不 是 一 个 真正 的 “TARGET”。 


我 们 先 从 Android 源 码 工 程 的 根 目录 分 析 起 ， 其 下 的 Makefi1e 文 件 


是 其 编译 系统 的 起 点 。 可 以 看 到 ， 它 只 是 一 个 简单 的 文件 转向 ， 直 接 引 
用 了 另 一 个 Makefile 文 件 (build/core/main. mk) 。 具 体 如 下 所 示 : 


/*Makefile*/ 

### DO NOT EDIT THIS FILE ### 
include build/core/main.mk 
### DO NOT EDIT THIS FILE ### 


这 个 被 引用 的 main. mk 文件 有 上 和 于 行 代 码 ， 对 于 Makefi le 文档 来 说 

是 比较 大 的 。 另 外 ， 它 又 进一步 引用 了 很 多 其 他 脚本 文件 ， 使 得 整个 文 

件 的 由 部 结构 看 起 来 杂乱 无 草 。 即便 有 不 少 注释 ， 仍 让 很 多 初学 者 “ 望 
AJ o 

基于 这 个 原因 ， 如 果 一 开始 我 们 就 照 着 Makef i le 文件 一 行 行 解释 ， 

很 可 能 会 “事倍功半 ”。 建 议 大 家 牢记 Makef i le 依赖 树 的 概念 ， 以 树 根 


节点 作为 切入 点 寻求 突围 。 当 然 ，Androi d 系 统 的 依赖 树 可 不 像 
SimpleMakef i le 例子 那样 一 目 了 然 。 如 何 找 出 它 的 根 节 点 ， 并 以 此 为 基 


础 逐步 构建 出 一 棵 完整 的 依赖 树 还 是 需要 花 点 工夫 的 。 这 要 求 我 们 对 
Make 的 工作 原理 有 一 定 程 度 的 理解 。 所 需 知 识 点 总 结 如 下 : 


(1) 需要 强调 的 是 ， 编 译 系统 中 往往 有 不 止 一 棵 依赖 树 存在 。 比 
如 我 们 在 Android 系 统 下 使 用 “make” 命 令 和 “make sdk” 的 编译 结果 
会 馆 然 不 同 ， 这 是 因为 它们 分 别 执行 了 两 棵 不 同 的 依赖 树 。 


在 没有 显 式 指定 编译 目标 的 情况 下 使 用 不 带 任何 参数 
的 “make” 命 令 来 执行 编译 ) ， 那 么 第 一 个 符合 要 求 的 目标 会 被 Make 作 
为 默认 的 依赖 树 根 节 点 。 这 条 规则 也 同样 提醒 我 们 在 书写 Makefi le 时 一 
定 要 注意 各 Target 的 排放 顺序 。 如 果 不 愤 将 clean 等 目标 放 在 最 开始 的 
位 置 ， 很 可 能 会 导致 异常 情况 。 

(2) 原则 上 Make 程 序 会 对 makefi le 中 的 内 容 按照 顺序 进行 逐条 解 
析 。 一 个 典型 的 解析 过 程 分 为 三 大 步骤 ， 即 : 


变量 赋值 、 环 境 检测 等 初始 化 操作 ; 
按照 规则 生成 所 有 依赖 树 ; 
根据 用 尸 选择 的 依赖 树 ， 从 叶 到 根 逐 步 生成 目标 文件 。 


掌握 了 上 面 Makefi le 的 基本 规则 后 ， 对 照 main. mk 就 可 以 很 快 找 
出 ，“make” 命 令 对 应 的 依赖 树 的 根 节点 是 droid。 它 是 这 样 定义 的 : 


/*build/core/Main.mk*/ 

# This is the default target. It must be the first declared targ 
.PHONY: droid 

DEFAULT_GOAL := droid 

$(DEFAULT_GOAL) : 


从 注释 中 也 可 以 佐证 我 们 的 猜测 ， 即 droid 就 是 “default 
target” , MHA “It us} be the first declared target” —— BR 
过 这 里 的 droid 还 是 一 空 的 “规则 ”， 相当 于 是 我 们 预先 占 了 个 位 置 
以 保证 它 是 第 一 人 


那么 ，droid 的 真正 “规则 ”是 在 哪里 定义 的 呢 ? 


仔细 观察 的 话 ， 会 发 现 main. mk 后 续 内 容 还 有 多 个 地 方 对 droid 进 行 
了 定义 。 而 且 根 据 TARGET_BUILD_APPS 值 的 不 同 ， 出 现 了 两 个 分 支 。 如 
下 源码 所 示 : 


ifneq ($(TARGET_BUILD_APPS),) ## 只 编译 APP， 而 不 是 整个 系统 
„PHONY: apps_only 


apps_only: $(unbundled_build_modules) 
droid: apps_only ## 这 种 情况 下 droid 只 依赖 于 apps_only 








else # 非 TARGET_BUILD_APPS 的 情况 ， 此 时 需要 编译 整个 系统 
$(call dist-for-goals, droidcore, \ 
$(INTERNAL_UPDATE_PACKAGE_TARGET) \ 
$( INTERNAL_OTA_PACKAGE_TARGET) 和 
$(SYMBOLS_ZIP) \ 
$(INSTALLED_FILES FILE) \ 
$( INSTALLED _BUILD_PROP_TARGET) 和 
$(BUILT_TARGET_FILES_ PACKAGE) 和 
$(INSTALLED_ANDROID_INFO_TXT_TARGET) \ 
$(INSTALLED_RAMDISK_TARGET) \ 
$(INSTALLED_FACTORY_RAMDISK_TARGET) \ 
$(INSTALLED_FACTORY_BUNDLE_TARGET) \ 


) 


droid: droidcore dist _files## 当 编译 整个 系统 时 ，droid 的 依赖 关系 
endif # TARGET_ BUILD APPS 


从 上 面 这 段 代 码 可 以 看 出 ， 我 们 既 可 以 编译 整个 系统 ， 也 可 以 选择 
只 编译 App。 第 二 种 情况 使 用 的 场景 比较 少 此 时 droid 只 依赖 于 
apps_only， 而 后 者 又 进一步 取决 于 $ (unbundled build_ modules) 变 
量 ， 有 兴趣 的 读者 可 以 自行 分 析 。 











编译 整个 系统 是 我 们 的 首选 ， 即 上 述 代 码 中 “else” 部 分 的 内 容 。 
很 显然 ， 这 时 候 dqroid 有 两 个 PREREQUISITES: droidcore 和 
dist_ files， 如 图 3-3 所 示 。 


我 们 将 在 后 续 几 个 小 节 具 体 分 析 droidcore 和 dist=-files。 


Hie PRA 


apps onl 


a ENDARA S(sunbundled build 


modules) 





全 图 3-3 dtoid 的 依赖 树 
3.2.4 main. mk 解析 


讲解 droidcore 和 dist_files 之 前 ， 我 们 先 完整 分 析 下 main. mk 脚本 
文件 的 架构 。 除 了 构建 droid 等 依赖 树 外 ，main. mk 有 一 大 半 的 内 容 是 大 


了 完成 以 下 几 点 。 
。 对 编译 环境 的 检测 


比如 Java 版 本 是 否 符 合 要 求 ， 当 前 机 器 上 的 make 环 境 必须 高 于 特定 
版 本 等 。 如 果 这 些 检查 没有 通过 ， 一 般 情 况 下 系统 会 终止 编译 。 


。 进行 一 些 必 要 的 前 期 处 理 
比如 说 整个 项 目 工程 是 否 需要 先进 行 清理 工作 ， 部 分 工具 的 安 才 


o 


。 引用 其 他 Makefile 文 件 


这 点 在 整个 main. mk 中 处 处 可 见 ， 如 引用 config. mk, 
cleanbui Id. mk 等 。 


。 议 置 全 局 变量 

这 些 全 局 变量 决定 了 编译 的 具体 实现 过 程 。 

。 各 种 函数 的 实现 

Android 编 译 系统 中 定义 了 不 少 函数 ， 它 们 提供 了 各 种 问题 的 统一 
解决 方案 。 比 如 print-vars 国 数 用 于 打印 一 串 变 量 列表 ，my-dir 可 以 知 
道 当 前 所 处 的 路 径 等 。 这 些 范 数 对 我 们 自己 编写 Makefi le 文件 也 有 一 定 
的 指导 意义 。 

根据 前 一 章节 内 容 的 讲解 ， 为 Android 系 统 添加 一 款 定 制 设 备 需要 
涉及 如 下 几 个 脚本 文件 。 
vendorsetup ,sh 
AndroidProducts.mk 


BoardConfig.mk 
Android.mk 


其 中 vendorsetup. sh 是 在 envsetup. sh 中 被 调用 的 ， 其 他 几 个 
Makefile 的 调用 时 序 图 及 调用 关系 如 图 3-4 所 示 。 


从 图 3-4 中 可 以 清楚 地 看 到 ，Android. mk 是 最 后 才 被 main. mk 调用 
的 。 换 名 话说， 前 面 的 步骤 都 是 在 决定 选择 “什么 产品 ”以 及 “产品 的 
属性 ”， 而 最 后 才 是 考虑 该 产品 的 “零件 ”组 成 一 一 每 个 “零件 ”都 由 
一 个 Android. mk 描述 。 比 如 我 们 生产 一 台电 视 机 ， 先 是 通过 读 取 配置 来 
获知 电视 的 具体 属性 〈 多 大 尺寸 、 是 否 LCD、 是 否 壁 挂 等 ) ， 最 后 才 是 
考虑 它 的 具体 “零件 ”组 成 〈 某 品牌 的 屏幕 、 螺 丝 、 支 架 等 ) 。 


整个 编译 过 程 中 起 主导 作用 的 是 main. mk， 我 们 从 它 的 文件 名 就 可 
以 看 出 来 。 和 main. mk 同样 重要 的 还 有 config. mk， 这 个 专职 “配置 ”的 
脚本 可 以 说 是 “产品 的 设计 师 ” 除了 BoardConfig. mk 和 
AndroidProducts. mk 这 两 个 “定制 设备 ” 必 备 的 文件 外 ， 其 他 诸如 
javac. mk 《用 于 选取 合适 的 java 编 译 器 ) 、envsetup. mk (负责 环境 变 
量 的 定义 ) 等 Makefi le 也 都 属于 其 管辖 范围 。 另 外 ，BUILD 系 列 变 量 

( 即 BUILD_HOST_STATIC_ LIBRARY、BUILD_STATIC_ LIBRARY) 也 是 在 这 
里 赋值 的 。 





mall mk || conti eup. version _ 
| | ‘mk |) detaults.mk 











全 图 3-4 各 主要 Makefile 的 调用 时 序 图 


表 3-2 所 示 是 对 Android 编 译 系 统 中 涉及 的 主要 Makefi le 文件 的 统一 
解释 ， 可 供 有 需要 的 读者 参考 。 


表 3-2 主要 Makefi le 文件 释义 





pon pon 整个 编译 系统 的 主导 文件 





i 品 配置 的 主导 文件 


octal 统 需 要 遵循 的 基础 规则 定义 。 其 中 最 重要 也 
将 
Android.mk 中 的 LOCAL_MODULE 添 加 到 全 局 依 理 
整个 系统 的 编译 中 。 

另 两 个 起 到 关键 作用 的 变量 是 LOCAL_BUILT_MC 
LOCAL_INSTALLED_ MODULE 

(添加 到 ALL_MODULES 的 是 my_register_name， 
赋值 如 下 : 
LOCAL_BUILT_MODULE=out/target/product/gener 
intermediates/javalib.jar 
LOCAL_INSTALLED_MODULE*=out/target/product 


g ease 定义 
pent 作 的 定义 


清空 以 LOCAL 开 头 的 相关 系统 变量 ， 下 一 小 节 会 








提供 了 大 量 实用 函数 的 定义 


配置 编译 时 的 环境 变量 ， 注 意 要 与 envsetup.sh 区 分 





负责 BUILD_ EXECUTABLE 的 具体 实现 


人 负 贡 与 java 语 言 相关 的 编译 实现 ， 是 java_library.ml 
参见 表 后 面 的 示意 图 


java.mk 
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MRO | 负责 BUILD_ HOST_EXECUTABLE 的 具体 实现 


负责 BUILD_HOST_STATIC_LIBRARY 的 具体 实 蕊 
另外 ， 其 他 类 型 的 BUILD_ XX 变量 也 都 有 其 对 应 好 


pine comemk | 属于 congg 的 一 部 分 


负责 生成 版 本 信息 ， 默 认 格 式 为 : 
version_detaults.mk |eurD NUMBER := eng.$(USER).$(shell date +%Y 









编译 生成 Java 库 的 典型 依赖 关系 如 图 3-5 所 示 。 


ALL MODULES+= (范例 ,framework、ext) 
LOCAL BUILT MODULE} |LOCAL INSTALLED MODULE 


jackenabled 
common Javalibjar | — | full classes jack 


static java lib 


not static java Lib 


full classes proguard jar/ull classes. jar 


java resource sources 





全 图 3-5 典型 依赖 关系 
Java. mk 中 定义 了 多 个 中 间 和 最 终 产 物 的 生成 规则 ， 包 括 : 
LOCAL_INTERMEDIATE_TARGETS += \ 


$(full_classes_compiled_jar) \ 
$(full_classes_jarjar_jar) \ 


$(full_classes_emma_jar) \ 
$(full_classes_jar) \ 
$(full_classes_proguard_jar) \ 
$(built_dex_intermediate) \ 
$(full_classes_jack) \ 
$(noshrob_classes_jack) \ 
$(built_dex) \ 
$(full_classes_stubs_jar) 


上 述 这 些 变量 的 具体 摘 述 如 表 3-3 所 示 。 


表 3-3 具体 的 描述 





$(full_classes_compiled_j 
$(java_sources) \ 
$(java_resource_: 
$(full_java_lib_d 
$(jar_manifest_fi 
$(layers_file) \ 
$(RenderScript_f 
$(proto_java_sou 
$(LOCAL_MOD 

\ 


$(LOCAL_ADDITIONAL. 
$(transform-java-to-c 


当 存 在 JarJar 规 则 时 : 
$(full_classes_jarjar_jar): 
$(full_classes_compiled_j 
full_classes_jarjar_jar classes-jarjar.jar (LOCAL_JARJAR_RULE: 
@echo JarJar: $@ 
$(hide) java -jar $JA. 
(PRIVATE_JARJAR_RUL 








$(full_classes_emma_jar): 
$(full_classes_jarjar_jar) 


full_classes_emma_jar _ |lib/ classes-jarjar.jar $(transform-classes.ja 


$(full_classes_jar): $(full_ 
| $(ACP) 
@echo Copying: $@ 
$(hide) $(ACP) -fp $< 


full_classes_jar 


$(full_classes_proguard_j 
$(full_classes_jar) $(extra_ 
$(my_support_library_sdk_ 
$(proguard_flag_files) | $(/ 
$(PROGUARD) 


$(call transform-jar-tc 


H 
一 


full _classes_proguard_jarl 者 
noproguard.classes. jar 


i i $(built_dex_intermediate` 
no-local 《或 者 with- $(full_classes_proguard_j 
$(transform-classes.ja 


built_dex_intermediate local) / classes.dex 


$(full_classes_jack): $(jac 
full_classes_jack Jj @echo Building with 
$(java-to-jack) 





$(built_dex): $(built_dex_ 
$(ACP) 
@echo Copying: $@ 
$(hide) mkdir -p $(dir 
$(hide) rm -f $(dir $@ 
$(hide) $(ACP) -fp $( 
$(dir $@) 


built_dex classes.dex 


ifneq ($(GENERATE_DE? 
$(install-dex-debug) 
endif 





请 六 家 注意 观察 表 3- 3 中 的 黑色 加 粗 字 体 ， 不 难 发 现 java. mk 中 的 这 
几 个 变量 之 间 存 在 着 相互 依赖 关系 ， 可 以 说 是 “ 环 环 相 扣 ” : 


built dex-> built dex_intermediate 一 > 
full classes proguard jar -> full classes jar- 
>full classes emma jar->full classes jar jar_jar- 
>full_classes_compiled_jar- 
>java_sources+ java_resource_sourcest+ 
full java lib deps+jar manifest file… 


当然 ， 如 果 开 局 了 Jack 编 译 ， 那 么 依赖 关系 会 有 所 不 同 。Jack 与 传 
统 编译 方式 一 个 重要 的 区 别 就 是 ， 它 会 直接 生成 最 终 的 dex 文 件 一 一 不 
过 在 Static Java Library 的 情况 下 它 还 需要 生成 . jack 文 件 。 


3.2.5 droidcore 节 点 


在 编译 整个 Android 系 统 〔 而 不 是 只 有 App〉 的 情况 下 ，droid 依 赖 
于 droidcore 和 dist files。 这 一 小 节 先 来 分 析 下 droidcore 节 点 的 生成 
过 程 。 其 规则 定义 如 下 : 


# Build files and then package it into the rom formats 
-PHONY: droidcore 
droidcore: files \ 

systemimage \ 

$ (INSTALLED BOOTIMAGE TARGET) \ 
(INSTALLED | RECOVERYIMAGE _ TARGET) \ 
INSTALLED _ USERDATAIMAGE TARGET) \ 
INSTALLED | CACHEIMAGE | TARGET) \ 
INSTALLED | VENDORIMAGE _ TARGET) \ 
INSTALLED_ FILES FILE) 


Ah A te a 


可 以 看 到 ，droidcore 依 赖 于 如 表 3-4 所 示 的 几 个 Prerequisites。 


表 3-4 droidcore 的 prerequisites 





代表 其 所 依赖 


$(INSTALLED_CACHEIMAGE_TARGET) 


$(INSTALLED_VENDORIMAGE_TARGET) 


$(INSTALLED_FILES_FILE) 记录 当前 系统 
中 预 安装 的 程 
序 、 库 等 模块 





这 几 个 “先决 条 件 ” 的 产生 原理 都 类 似 ， 因 而 我 们 只 挑选 前 几 个 来 
做 重点 分 析 。 


1. files 
定义 如 下 : 


= All the droid stuff, in directories 
-PHONY: files 
files: prebuilt \ 
$ (modules to install) \ 
$ (INSTALLED ANDROID INFO TXT TARGET) 


(1) prebuilt。“prebuilt” 也 是 一 个 伪 目 标 ， 它 依赖 于 
$(ALL_PREBUILT) 变量 。ALL_PREBUILT 机 制 只 用 于 早期 的 版 本 ， 目 前 已 
经 被 废弃 ， 建 议 大 家 使 用 它 的 替代 品 PRODUCT_COPY_FILES。 


s 


(2) modules_to_instal1。 如 其 名 称 所 示 ， 这 个 变量 描述 了 系统 
需要 安装 的 模块 。 


modules pad -= $ (sort \ 
$ (ALL_DEFAULT_INSTALLED_MODULES) \ 
$(product_FILES) \ 
$ (foreach tag,$(tags_to_install),$($(tag)_MODULES)) \ 
$(call get-tagged-modules, shell_$(TARGET _SHELL)) \ 
$(CUSTOM_MODULES) \ 








由 此 可 见 ， 这 些 模 块 被 分 为 五 部 分 ， 最 核心 的 是 下 面 两 种 。 
e product_FILES 
编译 该 产品 涉及 的 相关 文件 。 与 product_FILES 有 直接 联系 的 是 


product_MODULES， 后 者 则 是 基于 PRODUCT_PACKAGES 的 处 理 结果 。 简 而 
言 之 ，product_FILES 是 各 modules 〈 比 如 framework，Browser) 需要 安 


装 文件 的 列表 。 
e tags_to_install 所 对 应 的 Modules 


在 Android 编 译 机 制 中 ， 模 块 是 可 以 指定 编译 标志 的 ， 如 user、 
debug、eng、tests。 通 过 给 各 模块 打上 相应 标志 ， 可 以 在 编译 时 有 选 


择 地 避 开 茶 些 无 用 的 功能 部 件 。 


比如 开发 人 员 在 当 次 编译 时 特别 指定 了 eng 标 志 ， 那 么 所 有 与 此 无 
关 的 模块 都 将 被 排除 在 最 终生 成 的 系统 之 外 。 具 体 而 言 ， 
$ (tag)_MODULES 变 量 赋值 后 得 到 的 是 eng_MODULES， 后 者 又 由 函数 get- 
tagged-modules 来 进一步 填充 : 


eng MODULES := $(sort \ 
$ (call get-tagged-modules,eng) \ 
$(call module-installed-files, $(PRODUCTS.$ INTERNAL PRODUCT ) .PRODUCT_PACKAGES ENG) ky 
) 
debug MODULES := $ (sort \ 
$ (call get-tagged-modules, debug) \ 
$ {call module-installed-files, $(PRODUCTS.$ INTERNAL_PRODUCT ) . PRODUCT_PACKAGES DEBUG) LA 


| 
接 下 来 我 们 分 析 get-tagged-modules 的 函数 实现 : 


# Given an accept and reject list, find the matching 

# set of targets. If a target has multiple tags and 

# any of them are rejected, the target is rejected. 

# Reject overrides accept. 

# $(1): list of tags to accept 

# $(2): list of tags to reject 

#TODO(dbort): do $(if $(strip $(1)),$(1),$(ALL_MODULE_TAGS)) 
#TODO(jbq): as of 20100106 nobody uses the second parameter 
define get-tagged-modules 


$ (filter-out \ 
$ (call modules-for-tag-list,$(2)), \ 


$ (call modules-for-tag-list,$(i))) 
endef 


可 以 看 到 ， 这 个 函数 并 不 只 单纯 寻找 符合 tag 要 求 的 候选 者 ， 而 是 
综合 考虑 了 “可 接受 ”和 “拒绝 ”两 种 情况 。 简 单 来 说 ， 当 一 个 目标 既 
有 “可 接受 ”标签 又 有 “拒绝 ”标签 时 ， 它 仍然 会 被 淘汰 。 


“可 接受 ”对 象 的 查找 则 由 modules-for-tag-1ist 来 实现 。 其 定义 
如 下 : 


# Given a list of tags, return the targets that specify 
# any of those tags. 

# $(1): tag list 

define modules-for-tag-list 


$ (sort $ (foreach tag,$(i),$(ALL_MODULE_TAGS.$(tag)) ) ) 
endef 


需要 注意 的 是 ，ma in. mk 在 后 续 编 译 过 程 中 还 会 对 
modules_to_instal1 进 行 若干 次 过 滤 ， 目 的 就 是 去 掉 不 符合 条 件 和 重复 
无 效 的 部 分 。 


(3) $ (INSTALLED ANDROID_1INFO_TXT_TARGET) 的 生成 流程 和 前 两 
个 变量 相似 ， 读 者 可 以 作为 练习 自行 分 析 。 


2. systemimage 


systemimage 的 规则 定义 在 bui 1d/core/Makefile 中 : 


$ (INSTALLED SYSTEMIMAGE): $ (BUILT SYSTEMIMAGE) $ (RECOVERY FROM BOOT PATCH) | $ (ACP) 

Gecho "Install system fs image: $@" 

$ (copy-file-to-target) 

$(hide) $(call assert-max-image-size, $@ $ (RECOVERY FROM BOOT PATCH) ,$(BOARD SYSTEMIMAGE PARTITION SIZE), yaffs) 
systemimage: $ (INSTALLED SYSTEMIMAGE) 

不 难看 出 ， 这 个 规则 中 最 重要 的 Prerequi site 是 

$(BUILT_SYSTEMIMAGE) ， 它 和 systemimage 一 样 也 是 在 同一 个 Makefi le 
š mo y f : ot BE ogot sk > 7 
文件 中 定义 的 。 最 终 system. img 文 件 就 是 通过 它 来 生成 的 ， 采 用 的 
COMMAND 是 : 


$(call build-systemimage-target, $@) 


参数 “$@ ”是 Makefi le 定义 的 一 个 自动 化 变量 ， 代 表 所 有 targets 
的 集合 。 


这 样 就 可 以 成 功 编译 出 system. img 了 。 
总 的 来 说 ，droidcore 负 责 生 成 系统 的 所 有 可 运行 程序 包 ， 包 括 


system. img, boot. img, recovery. img 等 。 


3.2.6 dist files 


根 节点 droid 还 有 另 一 个 依赖 ， 即 dist_files。 它 在 整个 编译 项 目 
中 只 出 现 了 一 次 ， 如 : 


# dist_files only for putting your library into the dist directory with a full build. 
.PHONY: dist_files 


按照 Android 的 设计 ， 当 这 个 目标 节点 起 作用 时 ， 会 在 out 目 录 下 产 
生 专门 的 di st 文件 夹 ， 用 于 存储 多 种 分 发 包 。 而 通常 情况 下 ， 它 既 不 做 
任何 工作 ， 也 不 会 对 我 们 理解 整个 编译 系统 产生 影响 ， 因 此 读者 可 以 半 
Epi 


3.2.7 Android. mk 的 编写 规则 


一 棵 大 树 的 繁茂 和 校 叶 的 多 究 是 息息相关 的 。 一 方面 ， 只 有 站 壮 的 
村 干 才能 提供 足够 的 养分 来 供给 它 的 众多 细 枝 林 叶 ; 男 一 方面 ， 树 叶 的 
光合 作用 同样 可 以 滋养 整 棵 大 树 ， 从 而 使 其 呈现 出 欣欣 同 荣 之 态 。 


我 们 曾 不 止 一 次 地 提 到 过 ，Android 系 统 是 由 非常 多 的 子 项 目 组 成 
的 。 一 款 优秀 的 开放 式 操作 系统 ， 除 了 要 能 在 原生 态 系 统 中 预先 兼容 庄 
多 第 三 万 模块 外 ， 还 应 该 具有 民 好 的 后 期 动态 扩展 性 。 比 如 一 家 互联 网 
厂商 希望 将 其 自行 研发 的 采 个 APK 应 用 程序 集成 进 Android 系 统 中 ; 或 者 
“音乐 概念 ”的 手机 公司 打算 把 某 个 音频 解析 库 编译 进 系 统 版 


那么 ， 良 好 的 动态 扩展 性 对 这 两 家 公司 而 言 就 意味 着 不 需要 花 太 多 
时 间 去 关心 整个 Android 编 译 体系 的 运作 原理 ， 就 能 完成 以 上 两 个 需求 
这 就 像 驾 驶 员 适 当地 了 解 发 动机 内 部 结构 能 让 他 们 在 道路 上 更 得 心 
应 手 ， 但 我 们 不 能 因此 就 强制 要 求 大 家 必须 理解 发 动机 原理 才能 开车 。 


这 就 是 Android. mk 的 一 大 意义 所 在 。 


Android. mk 在 整个 源码 工程 中 随处 可 见 ， 保 守 估 计 其 总 体 数 量 在 一 
TTPAE: 


那么 如 此 之 多 的 文件 ， 又 是 如 何 整合 进 庞大 的 编译 系统 而 保证 不 会 
出 错 的 呢 ? 下 面 的 代码 是 将 源码 工程 中 所 有 Android. mk 添加 进 编 译 系 统 
的 处 理 过 程 〈 在 main. mk 中 定义 ) : 





ifneg ($(ONE SHOT MAKEFILE), ) 

include $(ONE_SHOT MAKEFILE) 

CUSTOM MODULES := $(sort $(call get-tagged-modules, $ (ALL MODULE TAGS) ) ) 
FULL BUILD := 

# Stub out the notice targets, which probably aren't defined 

# when using ONE_SHOT_MAKEFILE. 

NOTICE-HOST-$: ; 

NOTICE-TARGET-$: ; 


else # ONE_SHOT_MAKEFILE 


# 
# Include all of the makefiles in the system 
# 
# Can't use first- makefiles- under here because 
# --mindepth=2 makes the prunes not work, 
subdir makefiles := \ 
$(shell build/tools/findleaves.py --prune=out --prune=.repo --prune=.git $(subdirs) Android.mk) 


include $(subdir_makefiles) 


endif # ONE_SHOT_MAKEFILE 


变量 ONE_SHOT_MAKEF1ILE 和 编译 选项 有 关 。 如 果 选 择 了 编译 整个 工 
程 项 目 ， 那 么 这 个 变量 就 是 空 的 ; 否则 如 果 使 用 了 诸如 "make mm" 之 类 
的 部 分 编译 命令 时 ， 那 么 在 mm 的 实现 里 会 对 ONE_SHOT_MAKEF 1LE 进 行 必 
要 的 赋值 。 


在 编译 整个 工程 的 情况 下 ， 系 统 所 找到 的 所 有 Android. mk 将 会 先 存 
入 subdir_makefiles 变 量 中 ， 随 后 一 次 性 include 进 整个 编译 文件 中 。 


接 下 来 ， 我 们 选取 adb 项 目 作 为 例子 详细 解释 Android. mk 的 编写 规 
则 及 一 些 注 意 事 项 。 之 所 以 挑选 adb 程 序 ， 是 因为 本 书 的 工具 篇 中 还 会 
对 其 内 部 原理 进行 剖析 一 一 理解 一 个 程序 很 重要 的 前 提 就 是 读 懂 它 的 
Makefile， 这 将 为 我 们 后 期 的 学 习 打下 一 定 的 基础 。 


Adb 的 源码 路 径 在 system/core/adb 中 ， 我 们 只 摘抄 其 Android. mk 中 
的 核心 实现 。 具 体 如 下 所 示 : 
LOCAL_PATH:= $(call my-dir) /*LOCAL_PATH 的 位 置 先 于 CLEAR_VARS*/ 


include $(CLEAR_VARS) 
/*CLEAR_VARSH xc X7E/build/core/clear_vars.mk#, jake S_ERSBELOCAL 


USB_SRCS := 
EXTRA_SRCS := 
/x*adb 内 部 定义 的 两 个 变量 ， 将 在 不 同 的 操作 系统 环境 下 赋予 不 同 的 文件 值 。 因 为 不 同 的 
ifeq ($(HOST_OS), linux) /*Linux 环 境 下 */ 
USB_SRCS := usb_linux.c 
EXTRA_SRCS := get_my_path_linux.c 
LOCAL_LDLIBS += -lrt -ldl -lpthread 
LOCAL_CFLAGS += -DWORKAROUND_BUG6558362 
endif 
…/* 省 略 其 他 操作 系统 下 的 类 似 处 理 */ 
LOCAL_SRC_FILES := \ 
adb.c \ 





























$(EXTRA_SRCS) \ 
$(USB_SRCS) \ 
utils.c \ 
usb_vendors.c 
/*LOCAL_SRC_FILES 是 一 个 很 重要 的 变量 ， 它 定义 了 本 模块 编译 所 涉及 的 所 有 源 文件 。 
的 两 个 变量 ， 即 USB_SRCS 和 EXTRA_SRCS 也 在 这 里 被 加 入 到 了 编译 列表 中 */ 





























ifneq ($(USE_SYSDEPS_WIN32), ) 

LOCAL_SRC_FILES += sysdeps_win32.c/* 根 据 实际 情况 来 扩展 LOCAL_SRC_FI 
else 

LOCAL_SRC_FILES += fdevent.c 
endif 





LOCAL_CFLAGS += -02 -g -DADB_HOST=1 -Wall -Wno-unused-parameter 
LOCAL_CFLAGS += -D_XOPEN_SOURCE -D_GNU_SOURCE 

/* 上 面 两 行 用 于 添加 编译 标志 ， 这 在 编译 过 程 中 会 起 作用 */ 

LOCAL_MODULE := adb/* 所 要 生成 的 模块 的 名 称 */ 





LOCAL_STATIC_LIBRARIES := libzipfile libunz libcrypto_static $(EX 


include $(BUILD_HOST_EXECUTABLE) 
/* 这 个 语句 是 整个 Android ,mk 的 重点 。BUILD_HOST_EXECUTABLE 表 示 我 们 希望 生成 - 


/* 到 目前 为 止 的 语句 仅 定义 了 adb host 工 具 的 生成 过 程 ， 这 个 程序 将 运行 于 开发 环境 所 


/* 以 下 内 容 是 adbd 的 编译 配置 ， 这 个 程序 运行 于 设备 端 */ 
include $(CLEAR_VARS)/* 第 二 个 模块 编译 的 开始 标志 */ 
LOCAL_SRC_FILES := \ 

adb.c \ 








Utils.c 
/* 从 LOCAL_SRC_FILES 变 量 可 以 发 现 ，adb daemon 和 adb host 所 涉及 的 文件 是 有 重 
.…/* 省 略 和 第 一 个 模块 中 类 似 的 语句 */ 
LOCAL_MODULE := adbd/* 模 块 名 称 */ 








LOCAL_STATIC_LIBRARIES := libcutils libc libmincrypt 
include $(BUILD_EXECUTABLE) /* #ix # Aik, 第 二 个 模块 的 编译 配置 结束 ， 最 终 千 


通过 以 上 对 Android. mk 文件 的 分 析 ， 我 们 了 解 到 ADB 工 具 分 为 两 部 
分 ， 即 ADB Host (Client 和 Server) 和 ADB Daemon。 前 者 将 和 开发 环境 
运行 于 同一 机 器 平台 中 ， 后 者 则 面向 设备 本 身 。 


人 eee eee 
我 们 都 特别 标注 了 出 来 。 从 中 可 以 看 到 ， 通 过 Android. mk 添加 一 个 编译 
模块 到 系统 中 的 顺序 如 下 : 


e LOCAL PATH; 

CLEAR_VARS; 

LOCAL_SRC_FILES; 

LOCAL_CFLAGS (#2) ; 

LOCAL_MODULE; 

LOCAL_STATIC_LIBRARIES (可 选 ) ; 
BUILD_HOST_EXECUTABLE/BUILD_EXECUTABLE  . 








最 后 ， 总 结 下 Android. mk 的 几 个 使 用 要 点 。 


(1) 我 们 可 以 把 Android. mk 的 处 理 步 又 与 食品 制作 过 程 做 个 类 
bes 





。 准备 食材 。 包 括 LOCAL SRC_FILES，LOCAL MODULE, 
LOCAL STATIC_LIBRARIES 的 收集 。 虽 然 每 道 菜 都 会 有 不 同 的 原 
料 需 求 ， 但 细心 的 厨师 (Androida k RRA) 事先 都 考虑 到 了 。 他 
做 好 了 合理 的 分 类 (调味 类 、 肉 类 、 蔬 菜 类 等 ) ， 并 提供 了 完整 的 
清单 。 我 们 所 要 做 的 工作 就 是 按照 这 些 清 单 逐 项 采购 。 

亮 饪 菜肴 。 准 备 好 食材 以 后 ， 就 可 以 开始 佳 着 的 亮 饪 了 。 得 益 于 
Android 编 译 系统 的 用 心 ， 这 个 过 程 比 我 们 想象 中 的 简单 很 多 。 因 

为 同一 道 菜 的 烧 制 工序 是 一 样 的 ， 所 以 Google 事 先 就 把 这 些 步骤 集 
合 起 来 ， 并 做 好 了 各 种 模板 ， 如 BUILD_STATIC_LIBRARY， 
BUILD_SHARED_LIBRARY，BUILD_EXECUTABLE 等 。 一 旦 顾客 
点 了 哪 道 菜 ， 我 们 只 要 调用 这 些 固 有 模板 就 可 以 轻松 完成 整个 亮 饪 
过 程 ， 非常 方便 。 














(2) 每 个 Android. nk 都 允许 同时 者 几 道 菜 ， 每 个 清单 将 以 下 面 的 
语句 开始 : 


include $(CLEAR_VARS) 
并 以 如 下 语句 结束 : 


include $(BUILD_XXX) 
YE: BUILD_XXX 代 表 上 面 所 提 及 的 各 个 编译 模板 


(3) 表 3-5 所 示 是 在 编写 Android. mk 时 所 涉及 的 常用 重要 变量 ， 供 
读者 参考 。 


表 3-5 Android. mk 中 常用 的 重要 变量 解析 





用 于 确定 源码 所 在 的 目录 ， 最 好 把 
它 放 在 CLEAR_VARS 变 量 引 用 的 
前 面 。 因 为 它 不 会 被 清除 ， 每 个 
Android.mk 只 需要 定义 一 次 即 可 





它 清空 了 很 多 以 “LOCAL ”开头 的 
变量 (LOCAL PATH 除外 ) > H 
于 所 有 的 Makefile 都 是 在 一 个 编译 
iis sine lame 环境 中 执行 的 ， 因 此 变量 的 定义 理 
论 上 都 是 全 局 的 ， 在 每 个 模块 编译 
开始 前 进行 清理 工作 是 必要 的 








模块 名 ， 需 保证 在 整个 编译 系统 中 





LOCAL MODULE 


Locat MODULE. para liss 的 输出 路 径 





模块 编译 过 程 所 涉及 的 源 文 件 。 如 

果 是 Java 程 序 ， 可 以 考虑 调用 all- 

subdir-java-files 来 一 次 性 添加 目录 
(包括 子 目 录 ) 下 所 有 的 Java 文 件 








LOCAL_SRC_FILES 为 有 LOCAL PATH, XERE 


要 给 出 文件 名 《相对 路 径 ) 即 可 ; 
而 且 编 译 系统 有 比较 强 的 推导 功 
能 ， 可 以 自动 计算 依赖 关系 


Locau cre pxrenson fi 于 指定 特殊 的 C++ 文件 后 缀 名 
koa oxincs erie 


编译 C 和 C++ 程序 所 需 的 额外 头 文 





LOCAL_C_INCLUDES 件 











LOCAL. STATIC LIBRARIES 编译 所 雷 的 静态 库 列表 


LOCAL SHARED LIBRARIES 编译 所 需 的 共享 库 列 表 
vA | 






Loca tops pocar.tpups stra 的 链接 选项 


必用 程序 时 所 需 复制 的 头 文件 
列表 ， 

LOCAL_COPY_ HEADERS TO# 
量 配合 使 用 


FocAT COPY_HEADERS_TO | Psxxfplaann 


BUILD_ HOST _ STATIC_LIBRARY 
BUILD_ HOST_ SHARED LIBRARY 

BUILD_STATIC_LIBRARY 各 种 形式 的 编译 模板 ， 如 生成 设备 
BUILD_RAW_STATIC_ LIBRARY | 端 或 者 Host 端 的 静态 、 动 态 库 文件 
BUILD_SHARED LIBRARY (Java 和 C/C++ 等 ) ， 可 执行 文 
BUILD_EXECUTABLE 件 ， 文 档 等 
BUILD_RAW_EXECUTABLE 需要 大 家 特别 注意 的 是 
BUILD_HOST_EXECUTABLE BUILD_JAVA_LIBRARY fill 
BUILD_PACKAGE BUILD_STATIC JAVA_LIBRARY 
BUILD _ HOST PREBUILT 之 间 的 区 别 。 后 者 生成 的 Java 
BUILD_PREBUILT Library 既 不 会 被 安装 ， 也 不 会 被 放 
BUILD_MULTI_PREBUILT 到 Java 的 Classpath 中 。 而 

BUILD JAVA LIBRARY BUILD _ JAVA_LIBRARY 得 到 的 
BUILD_ STATIC _ JAVA_LIBRARY ava 库 是 具有 “共享 性质 的 ， 可 以 
BUILD_ HOST JAVA LIBRARY 为 多 个 程序 所 共用 (会 被 复制 
BUILD_DROIDDOC 到 /systemy/framework 中 ) 
BUILD_ COPY HEADERS 

BUILD_ KEY_CHAR_MAP 


LOCAL _COPY_HEADERS 

















在 本 章 的 学 习 中 ， 我 们 先 从 最 基础 的 Makef i le 语法 规则 入 手 ， 导 出 
了 依赖 树 的 概念 ; 然后 按照 由 上 而 下 的 顺序 ， 逐 步 杭 理 出 编译 一 个 完整 
的 Android 版 本 所 ; 涉及 的 几 个 重要 节点 = 


Android 编 译 系统 是 非常 庞大 的 ， 所 包括 的 节点 和 文件 数量 远 不 止 
本 章 所 描述 的 。 不 过 ， 我 们 的 目的 是 让 读者 掌握 一 种 有 效 的 分 析 编 译 系 
统 的 方法 一 一 相信 和 只 要 按照 本 章 的 分 析 方 法 ， 再 一 步 步 地 进行 推导 论 
断 ， 整 个 Android 编 译 体 系 就 会 “水 落石 出 ”了 。 





3.3 Jack Toolchain 


从 6. 0 版 本 开始 ，Android 编 译 系 统 中 一 个 比较 大 的 变化 是 采用 了 全 
新 的 Java 编 译 链 ， 即 Jack (Java Android Compiler Kit) 。 


Jack 的 主要 任务 是 取代 以 前 版 本 中 的 javac、ProGuard、jarjar、 
dx 等 诸多 工具 ， 以 一 种 全 新 的 方式 来 将 Java 源 文件 编译 成 Android 的 Dex 
字 节 码 。 它 的 优势 在 于 可 以 加 快 编译 速度 ， 具 有 内 建 的 shr inking, 
obfuscation、repackaging 和 multidex 等 功能 ， 并 且 完 全 开源 ， 如 图 3- 
6 所 示 。 


Shrinking 
| Obfuscation 
| Repackaging 


| Multidex 
lL > 
a) Dey 
file(s) 


Java 


source 
file(s) 





Jack 
library 
file(s) 





A 3-6 Jack 简 图 
(引用 自 source.android.com) 


Jack 有 自己 的 文件 格式 ， 这 就 不 可 避免 地 需要 利用 一 个 工具 来 将 它 


与 传统 的 .jar 文件 进行 转换 即 Ji1l1 (Jack Intermediate Library 
Linker) 。 如 图 3-7 所 示 。 








jar JACK used to generate 
a pro-dexed library 
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ic 
| JACK H 
-Imporl-tesource 


Extract Select 
— > Resources 


directory 


Resources Resources 








全 图 3-7 ] 训 工作 流程 
(引用 自 source.android.com) 


接 下 来 我 们 重点 讲解 一 下 Jack 在 Android 系 统 工程 编译 中 的 一 些 特 
点 ， 以 便 大 家 可 以 学 以 致 用 。 虽 然 Android 官 方 承诺 使 用 Jack 的 情况 和 
以 往 的 编译 过 程 没有 任何 区 别 ， 但 事实 上 总 还 是 会 出 现 因为 Jack 而 导致 
编译 失败 的 情况 。 辟 如 笔者 就 曾 在 W 版 本 编译 中 遇 到 过 如 图 3-8 所 示 的 问 


题 。 


Building with Jack: out/target/common/obj/JAVA_LIBRARIES/core-libart_intermedia 
es/with-local/classes.dex 


Launching background server java -Dfile.encoding=UTF-8 -Xms2560m -XX:+TieredComp 
ilation -jar out/host/linux-x86/framework/jack-launcher.jar -cp out/host/linux-x 
86/framework/jack.jar com.android. jack.server.JackSimpleServer 


out/host/lLinux-x86/bin/jack: line 131: 24820 Killed SSERVER_PR 
SSERVER_PORT_SERVICE SSERVER_PORT_ADMIN SSERVER_COUNT S$SERVER NB COMPILE SSERVE 

R_TIMEOUT >> SSERVER_LOG 2>&1 

ERROR: Cannot launch Jack server 

make: *** [out/target/common/obj/JAVA_LIBRARIES/core-libart_intermediates/with-l 

ocal/classes.dex] Error 41 





全 图 3-8 编译 时 出 现 的 问题 


想 要 解决 上 述 这 个 错误 ， 首 先 就 得 理解 Jack 在 编译 系统 中 的 工作 过 


程 。 


Jack 可 以 加 快 编译 速度 的 一 个 重要 原因 是 提供 了 一 个 能 随时 待命 的 
Server， 与 以 往 的 JRE JVM 相 比 ， 这 种 方式 显然 可 以 节省 启动 和 初始 化 
的 时 间 “这 有 点 类 似 于 Grad1e 的 做 法 ) 。 当 然 ， 如 果 一 直 没 有 新 的 编译 
任务 到 达 ， 一 定时 长 后 ，Jack Server 也 会 自动 关闭 ， 以 避免 对 系统 资 
源 的 无 端 消 耗 。 


Jack Server 对 应 的 配置 文件 是 $HOME/. jack， 其 中 包含 了 如 表 3-6 
所 示 的 一 些 重要 信息 。 


表 3-6 重要 的 信息 





Config Item Description 


SERVER=true 能 ， 默 认 


SERVER_PORT_SERVICE=8072 


SERVER_PORT_ADMIN=8073 


SERVER_COUNT=1 


并 行 编译 
SERVER_NB_COMPILE=4 的 最 大 数 


SERVER_TIMEOUT=60 时 间 后 
Server 应 该 


RAS 


= 





SERVER_LOG=${SERVER_LOG:=$SERVER_DIR/jack- ”| 运行 时 Log 
$SERVER_PORT_SERVICE.log} 文件 的 存 


JACK_VM_COMMAND=${JACK_VM_COMMAND:=java}|JVM3£ fji] 
的 默认 命 


4 





根据 前 述 问题 的 Log 描 述 ， 我 们 不 难 发 现 编译 失败 的 缘由 是 无 法 启 
动 Jack Server。 针 对 这 种 情况 最 可 疑 的 原因 就 是 Server 所 需 的 端口 已 
经 被 Host 机 中 其 他 程序 占用 了 。 所 以 解决 办 法 就 是 在 . jack 配 置 文 件 中 
对 Jack Server 的 端口 号 进行 重新 调整 (建议 选 一 个 高 位 不 常用 的 端口 
号 ， 避 免 冲 突 ) 。 

不 过 很 遗憾 ， 更 改 端 口号 对 笔者 的 这 个 编译 错误 没有 产生 任何 效 
果 。 再 仔细 观察 一 下 编译 过 程 输出 的 Log， 可 以 发 现 男 一 个 可 疑点 〈 开 
发 人 员 也 可 以 查看 Jack Server 输 出 的 Log 文 件 来 定位 问题 ) ， 如 图 3-9 
所 示 。 


Launching background server java -Dfile.encoding=UTF-8 -Xms2560m 





全 图 3-9 发 现 问 题 


可 以 看 到 Jack Server 为 虚拟 机 申请 了 高 达 2560m 的 堆 内 存 ， 而 笔者 
给 编译 Android 系 统 的 虚拟 机 环境 只 配置 了 26GB 的 内 存 ， 所 以 显然 也 会 导 
致 失败 。 解 决 的 办 法 也 很 简单 ， 就 是 扩大 内 存 配额 ， 然 后 重 试 一 一 这 次 
问题 确实 得 到 了 解决 ， 并 成 功 完成 了 整个 编译 过 程 ， 参 见 图 3-12。 


我 们 再 来 观察 一 下 Jack 编 译 链 下 的 中 间 文 件 。 


其 中 BUILD_JAVA_LIBRARY 的 中 间 文 件 状 态 如 图 3-10 所 示 。 


am_intermediates 





1 


10 


101 
1010 





jack-rsc with-local classes.dex 
frame 
w | ani 
classes.jack jack-rsc.java-source- javalib.jar 
list 


全 图 3-10 Jack 不 再 输出 旧版 本 中 的 classes.jat 等 文件 
而 BUILD_STATIC_JAVA_LIBRARY 的 中 间 文 件 状态 如 图 3-11 所 示 。 
classes emma_out jack-rsc 


classes.jack classes.jar 


frame 


src 
LE frame 
frame 
[frame | 


classes-jarjar.jar jack-rsc.java-source- 


jar list 
# vie 
LS -keep / 
\# vie | | 
javalib.jar proguard_options public_resources. 
xml 


全 图 3-11 中 间 文 件 夹 状态 


不 难 发 现 ，Jack 并 不 输出 中 间 状 态 的 jar 文 件 ， 而 是 直接 得 到 最 终 
的 dex 产 物 一 一 这 也 是 它 会 导致 一 些 分 析 工 具 失 效 的 原因 ， 例 如 著名 的 


Jacoco 代 码 履 盖 率 工具 。 








= 
Android Emulator - Android7.1;5554 


一 Phone status 


Status 


Phone number, signal, et 
Legal information 


Model number 
Android SDK built for x86_64 


Android version 
7.0 wa da a a iala iola daii) 


pp PE pera PP ps rg P 
Android security patch level pran paeng per pree das pe pegy EY FET p 


September 6, 2016 Pr 一 一 一 一 天 


roll Fey Pe pee 
Baseband version ALT ALT 


Unknown 


Kernel version 





全 图 3-12 Android 7.x 模 拟 器 运行 效果 


由 于 Jack 是 一 项 exper imental 的 特性 ， 或 多 或 少 都 存在 着 一 些 
bug， 所 以 ， 大 家 在 开发 过 程 中 ， 包括 应 用 程序 和 系统 开发 ) 如 果 遇 
到 了 确实 是 由 于 Jack 所 引发 的 问题 ， 而 且 这 个 问题 暂时 还 无 法 得 到 解决 
的 话 ， 那 么 可 以 选择 不 用 Jack 来 进行 编译 注意 : 并 不 是 所 有 情况 下 都 
i 。 有 具体 做 法 是 在 Android. mk 中 添 
H ITER : 


LOCAL_JACK_ENABLED := disabled 


3.4 SDK 的 编译 过 程 


采用 Android 系 统 的 设备 厂商 越 来 越 多 ， 不 少 公司 便 开始 考虑 如 何 
编译 出 具有 自己 特色 的 扩展 SDK。 这 种 做 法 除了 满足 开发 人 员 的 需求 
外 ， 还 可 以 通过 SDK 来 开放 设备 自身 的 优势 ， 从 而 吸引 更 多 的 用 户 ， 提 
高 市 场 竞争 力 。 因 而 我 们 觉得 很 有 必要 分 析 一 下 SDK 的 生成 过 程 ， 以 便 
大 家 可 以 根据 自己 的 需求 来 进行 定制 修改 。 


简单 来 说 ，SDK 是 Android 系 统 提 供给 开发 人 员 的 一 个 “工具 集 ”。 
它 的 典型 文件 结构 大 致 如 图 3-13 所 示 。 


J add-ons 

用 build-tools 

J docs 

出 extras 

d| platforms 

县 platform-tools 

d sources 

dE system-images 
出 temp 

J tools 

=] AVD Manager.exe 
=] SDK Manager.exe 
EE SDK Readme.txt 





A 43-13 Android SDK 的 典型 文件 结构 


接 下 来 我 们 按照 编译 Android SDK 的 步骤 来 进行 讲解 ， 并 从 编译 脚 
本 内 部 实现 的 角度 来 分 析 它 的 整个 生成 过 程 ， 同 时 也 希望 可 以 让 读者 借 
此 更 深入 地 理解 Android 编 译 系 统 。 


3.4.1 envsetup. sh 


相信 通过 前 面 章节 的 学 习 ， 大 家 都 知道 在 编译 Android 系 统 之 前 ， 
首先 需要 执行 bui 1d 目 录 下 的 envsetup. sh 脚本 。 这 个 脚本 中 除了 包含 后 
续 步 又 所 需 的 水 数 定义 外 ， 还 会 做 很 多 准备 工作 。 具 体 如 下 所 示 : 


function hmm() { 


cat <<EOF 
Invoke ". build/envsetup.sh" from your shell to add the following 
- lunch: lunch <product_name>-<build_variant> 
- tapas: tapas [<App1> <App2> ...] [arm|x86|mips|armv5|arm64|x8 
userdebug|user | 
- croot: Changes directory to the top of the tree. 
- m: Makes from the top of the tree. 
- mm: Builds all of the modules in the current directory, but n 
- mmm: Builds all of the modules in the supplied directories, b 
To limit the modules being built use the syntax: mmm dir/:targe 
- mma: Builds all of the modules in the current directory, and 
- mmma: Builds all of the modules in the supplied directories, 
- cgrep: Greps on all local C/C++ files. 
- ggrep: Greps on all local Gradle files. 
- jgrep: Greps on all local Java files. 
- resgrep: Greps on all local res/*.xml files. 
- mangrep: Greps on all local AndroidManifest.xml files. 
- sepgrep: Greps on all local sepolicy files. 
- sgrep: Greps on all local source files. 
- godir: Go to the directory containing a file. 
Environemnt options: 
- SANITIZE_HOST: Set to 'true' to use ASAN for all host modules 
ASAN_OPTIONS=detect_leaks=0 will be set by default until the 
build is leak-check clean. 
Look at the source to view more functions. The complete list is 
EOF 
T=$(gettop) 
local A 
A=" 
for i in ‘cat $T/build/envsetup.sh | sed -n "/A[ \t]*function / 
A="$A $i" 
done 
echo $A 


Mhm Ay LAA Henvsetup. sh 所 提供 的 功能 ， 如 表 3-7 所 


表 3=7 envsetup. sh 脚本 提供 的 主要 函数 释义 





从 树 根 节点 开始 执行 make 


m 


m make 当 前 目录 下 的 所 有 模块 ， 但 是 不 包括 它们 的 依赖 


HH 


mm “|make 指 定 目录 下 的 模块 ， 但 是 不 包括 它们 的 依赖 


z 


ma make 当 前 目录 下 的 所 有 模块 ， 以 及 它们 的 依赖 


z 


make 指 定 目录 下 的 模块 ， 以 及 它们 的 依赖 


mmma 


cgrep 只 针对 所 有 C/C++ 文件 执行 grep 命 令 


ggrep ”只 针对 所 有 gradle 文 件 执行 grep 命 令 


jgrep 用 只 针对 所 有 Java 文 件 执行 grep 命 令 


只 针对 所 有 res/*.xml 文 件 执行 grep 命 令 


=p 
“> 


ay 


只 针对 所 有 AndroidManifest.xml 文 件 执行 grep 合 


N 
1 


只 针对 所 有 sepolicy 文 件 执 行 grep 命 令 


针对 所 有 源 代 码 文 件 执行 grep 命 令 


四 办 = 
© ga D B F 
A pet as) 中 JW 
= io) ga = ga 
= I 四 ga T 
3 ai] 

go) 


转 到 包含 指定 文件 的 目录 下 


| | | 


除了 提供 很 多 实用 的 函数 外 ，envsetup. sh 在 文件 的 最 后 还 会 扫描 
和 和 加载 device 和 vendor 目 录 下 的 vendorsetup. sh 文件 ， 具 体 如 下 所 示 : 


for f in 'test -d device && find -L device -maxdepth 4 -name 'ven 
‘test -d vendor && find -L vendor -maxdepth 4 -name 'ven 
do 
echo "including $f" 
. $f 
done 


需要 特别 注意 的 是 ， 上 述 脚本 对 vendorsetup. sh 文件 的 扫描 深度 为 
4。 由 前 面 章节 的 学 习 我 们 知道 ，vendorsetup. sh 会 通过 
add_1unch_combo 命 令 来 为 1unch 添 加 一 条 加 载 项 ， 如 图 3-14 是 #* 星 手机 
的 一 个 实例 。 


etup.sh (~/Android5.X/device/samsung/manta) - gedit 





Re 险 open ~- Basave =" 


‘| vendorsetup.sh x 


Copyright (C) 2011 The Android Open Source Project 


Licensed under the Apache License, Version 2.0 (the 
you may not use this file except in compliance with 
You may obtain a copy of the License at 


http://www. apache. org/licenses/LICENSE-2.0 


Unless required by applicable law or agreed to in wr 
distributed under the License is distributed on an " 
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either 
See the License for the specific Language governing 
Limitations under the License. 


HHRHHHHHHHHHHHH ， 


add_lunch_combo aosp_manta-userdebug| 


全 图 3-14 vendorsetup.sh 7 


当 envsetup. sh 执行 结束 后 ， 将 会 打印 出 搜寻 到 的 


vendorsetup. sh， 如 图 3-15 所 示 。 


s@ubuntu:~/Android5.x$ . ./build/envsetup.sh 
device/asus/deb/vendorsetup.sh 
device/asus/flo/vendorsetup.sh 
device/asus/fugu/vendorsetup.sh 
device/asus/grouper/vendorsetup.sh 
device/asus/tilapia/vendorsetup.sh 
device/generic/mini-emuLator -arm64/vendorsetup.sh 
device/generic/mini-emuLator-armv7-a-neon/vendorsetup.sh 
device/generic/mini-emuLlator-mips/vendorsetup.sh 
device/generic/mini-emuLlator-x86_64/vendorsetup.sh 
device/generic/mini-emuLator -x86/vendorsetup.sh 
device/htc/flounder/vendorsetup.sh 
device/1lge/hammerhead/vendorsetup.sh 
device/1lge/mako/vendorsetup.sh 
device/moto/shamu/vendorsetup.sh 
device/samsung/manta/vendorsetup.sh 
sdk/bash_compLetion/adb.bash 





全 图 3-15 ”打印 的 信息 
3.4.2 lunch sdk-eng 


完成 envsetup. sh 的 初始 化 后 ， 我 们 就 可 以 执行 下 一 步 命令 了 ， 即 


lunch sdk-eng。 


大 家 应 该 还 记得 lunch 命 令 的 用 法 : 要 么 在 lunch 后 加 上 product- 
variant 参 数 ， 要 么 不 带 任 何 参 数 ， 从 而 让 编译 系统 打印 出 当前 可 选 的 
产品 列表 ， 如 图 3-16 所 示 。 


You're building on Linux 


Lunch menu... pick a combo: 
aosp_arm-eng 
aosp_arm64-eng 
aosp_mips-eng 
aosp_ mips64-eng 
aosp_x86-eng 
aosp_x86_64-eng 
aosp_deb-userdebug 
aosp_flo-userdebug 
. full_fugu-userdebug 

. aosp_fugu-userdebug 

. aoSp_grouper-userdebug 

. aosp_tilapia-userdebug 

. Mini_emuLlator_arm64-userdebug 
. M_e_arm-userdebug 

. mini_emuLlator_mips-userdebug 
. Mini_emuLlator_x86_64-userdebug 
. mini_emuLlator_x86-userdebug 
. aosp_flounder-userdebug 

. aosp_hammerhead-userdebug 

. aosp_mako-userdebug 

. aosp_shamu-userdebug 

. aosp_manta-userdebug 


“wm 上 wh ee 





Which would you like? [aosp_arm-eng] fj 


全 图 3-16 产品 的 列表 


看 了 上 述 列表 ， 不 少 读者 可 能 会 有 疑惑 一 编译 SDK 使 用 的 命令 
lunch sdk-eng 并 没有 在 列表 中 ， 那 么 它 是 合法 的 吗 ? 


答案 是 肯定 的 。 实 际 上 |1unch 提 供 的 列表 是 由 开发 者 在 
vendorsetup. sh 或 其 他 文件 中 通过 add_1unch_combo 提 供 的 ， 并 不 是 必 
SHY; 而 真正 的 重点 在 于 lunch product-var iant 在 执行 过 程 中 如 何 验 
证 product 和 var iant 的 合法 性 。 


(1) lunch 针 对 product 的 合法 性 检查 


function lunch() 


{ 


local answer 


if [ "$1" ] ; then # 井 如 果 1 un ch 命令 带 参 数 ， 则 记录 下 来 
answer=$1 

else 
print_lunch_menu  ## 否 则 打印 出 产品 列表 供 开 发 者 选择 
echo -n "Which would you like? [aosp_arm-eng] " 
read answer  ## 读 取 用 户 的 选择 

fi 














local selection= 


if [ -z "$answer" ] ##MRAP HAE 
ONO T E E H HEU 
elif (echo -n $answer | grep -q -e "^ [0-9][0-9]*$")# # mR 
oe [ $answer -le ${#LUNCH_MENU_CHOICES[@]} ] # HATA RL 
Se ek Cee aieH HEN CLO A acta H HRH 








fi 
elif (echo -n $answer | grep -q -e "A[A\-][A\-]*-[A\-][A\-]*$ 
then 

selection=$answer 


fi 
if [ -z "$selection" ] HHIXINs e lection 不 应 该 为 空 了 
then 
echo 
echo "Invalid lunch combo: $answer" 
return 1 
fi 


export TARGET_BUILD_APPS= 


local product=$(echo -n $selection | sed -e "S/-.*$//")#H#MZ 
check_product $product  ## 检 验 p rodu c +t 是 否 合法 ， 下 面 我 们 会 有 
if [ $? -ne © ] 圭 4$?7 用 于 检查 上 一 个 函数 的 退出 码 ， 这 里 是 指 check_prod 
then 

echo 

echo "** Don't have a product spec for: '$product'" 

echo "** Do you have the right repo manifest?" 

product= 
fi 











local variant=$(echo -n $selection | sed -e "S/A[A\-]*-//")#: 
check_variant $variant  ## 检 验 va r i a nt 是 否 合法 ， 下 面 我 们 会 有 i 
if [ $? -ne © ]##“$?” 用 于 检查 上 一 个 函数 的 退出 码 ， 这 里 是 指 check_vari 
then 

echo 











echo "** Invalid variant: '$variant'" 
echo "** Must be one of ${VARIANT_CHOICES[@]}" 
variant= 

Fi 


if [ -z "$product" -o -z "$variant" | 
then 

echo 

return 1 
fi 





export TARGET_PRODUCT=$product č # HHR BERAE 
export TARGET_BUILD_VARIANT=$variant 
export TARGET_BUILD_TYPE=release 





echo 


set_stuff_for_environment 
printconfig 


可 以 看 到 ， 检 查 product 的 合法 性 主要 依靠 的 是 check_product 这 个 


function check_product() 


T=$(gettop) 
if [ ! "$T" ]; then 
echo "Couldn't locate the top of the tree. Try setting TO 
return 
fi 
TARGET_PRODUCT=$1 \ 
TARGET_BUILD_VARIANT= \ 
TARGET_BUILD_TYPE= \ 
TARGET_BUILD_APPS= \ 
get_build_var TARGET_DEVICE > /dev/null 
# hide successful answers, but allow the errors to show 


这 个 函数 看 起 来 很 简单 ， 什 么 也 没 做 ， 奥 妙 就 在 于 最 后 的 
get_build_var TARGET_DEV1CE。 我 们 接 下 来 看 一 下 get_bui 1d_var 又 做 
了 哪些 工作 。 要 特别 注意 的 是 ，TARGET_PRODUCT 被 赋予 了 第 1 个 参数 
值 ， 即 $product， 在 我 们 这 个 例子 中 就 是 sdk。 


function get_build_var() 


T=$(gettop )## 回 到 AOSP 工 程 根 目录 
if [ ! "$T" ]; then 
echo "Couldn't locate the top of the tree. Try setting TO 
return 
fi 
(\cd $T; CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ 
command make --no-print-directory -f build/core/config.mk du 


这 个 函数 百 先 回 到 工程 的 根 上 目录， 然后 为 几 个 变量 赋值 ， 它 们 都 将 
在 后 续 过 程 中 发 挥 作用 -最 后 ， 它 调用 了 "ef 命令， 执行 的 章 术 
是 /bui1ld/core/config. mk， 而 且 将 目标 对 象 设置 为 dumpvar-$1， 其 中 
$1 即 get build var 的 调用 参数 TARGET_DEVICE。 那 么 这 个 
TARGET_DEVICE 的 值 是 什么 呢 ? 


/*build/core/config.mk*/ 
include $(BUILD_SYSTEM) /envsetup.mk 
include $(BUILD_SYSTEM) /combo/javac.mk 


include $(BUILD_SYSTEM) /dumpvar .mk 


可 以 看 到 ，config. mk 的 主要 目的 如 其 名 所 示 ， 就 是 为 了 做 各 种 配 
置 工作 ， 而 这 其 中 非常 重要 的 一 步 配置 是 通过 envsetup. mk 这 个 脚本 完 
成 的 。 读 者 应 该 特别 注意 ， 将 这 个 envsetup. mk 与 之 前 提 到 的 
envsetup. sh 区 分 开 来 : 


/*build/core/envsetup.mk*/ 
include $(BUILD_SYSTEM) /product_config.mk 


board_config_mk := \ 
$(strip $(wildcard \ 
$(SRC_TARGET_DIR) /board/$(TARGET_DEVICE) /BoardConfig.mk 
$(shell test -d device && find device -maxdepth 4 -path 
$(shell test -d vendor && find vendor -maxdepth 4 -path 
)) 


从 上 面 的 脚本 可 以 清楚 地 看 到 ，BoardConfig. mk 的 赋值 与 
TARGET_DEV1CE 有 关系 ， 因 而 后 者 一 定 要 在 前 者 之 前 被 确定 下 来 ， 更 确 
切 来 讲 就 是 在 product config.mk 中 了 : 


/*build/core/product_config.mk*/ 


include $(BUILD_SYSTEM) /node_fns.mk 
include $(BUILD_SYSTEM)/product .mk 
include $(BUILD_SYSTEM) /device.mk 


ifneq ($(strip $(TARGET_BUILD_APPS) ), ) 

# An unbundled app build needs only the core product makefiles. 

all_product_configs := $(call get-product-makefiles, \ 
$(SRC_TARGET_DIR)/product/AndroidProducts.mk ) 

else 

# Read in all of the product definitions specified by the Android 

# files in the tree. 

all_product_configs := $(get-all-product-makefiles ) 

endif 


ifneq (,$(filter product-graph dump-products, $(MAKECMDGOALS) ) ) 

# Import all product makefiles. 

$(call import-products, $(all_product_makefiles) ) 

else 

# Import just the current product. 

ifndef current_product_makefile ## 如 果 出 现 错误 ， 编 译 脚本 就 会 停止 ， 这 也 
$(error Can not locate config makefile for product "$(TARGET_PROD 
endif 

ifneq (1,$(words $(current_product_makefile) ) ) 

$(error Product "$(TARGET_PRODUCT)" ambiguous: matches $(current_ 
endif 

$(call import-products, $(current_product_makefile) ) 

endif # Import all or just the current product makefile 
TARGET_DEVICE := $(PRODUCTS.$( INTERNAL_PRODUCT ) .PRODUCT_DEVICE) 


filzAXnode_fns.mk, product. mk 和 device. mk 引入 了 很 多 函数 定义 ， 
它们 会 在 后 续 查 找 产 品 定 义 的 操作 中 产生 作用 。 比 如 接 下 来 的 get- 
product-makefiles 和 get-al1-product-makefiles 的 定义 就 在 
product. mk 中 。 


如 果 TARGET_BUILD_APPS 不 为 空 ， 那 么 证 明 本 次 并 不 是 全 编译 ， 所 
以 只 要 把 核心 的 产品 定义 引用 进来 就 可 以 了 。 核 心 产品 是 由 
$ (SRC_TARGET_DIR) /product/AndroidProducts. mk 提供 的 ， 
BN/build/target/product/AndroidProducts. mk: 


ifneq ($(TARGET_BUILD_APPS), ) 
PRODUCT_MAKEFILES := \ 
$(LOCAL_DIR)/aosp_arm.mk \ 


$(LOCAL_DIR)/full.mk \ 
$(LOCAL_DIR)/generic_armv5.mk \ 
$(LOCAL_DIR)/aosp_x86.mk \ 
$(LOCAL_DIR)/full_x86.mk \ 
$(LOCAL_DIR)/aosp_mips.mk \ 
$(LOCAL_DIR)/full_mips.mk \ 
$(LOCAL_DIR)/aosp_arm64.mk \ 
$(LOCAL_DIR)/aosp_mips64.mk \ 
$(LOCAL_DIR)/aosp_x86_64.mk 

else 

PRODUCT_MAKEFILES := \ 
$(LOCAL_DIR)/core.mk \ 
$(LOCAL_DIR)/generic.mk \ 
$(LOCAL_DIR)/generic_x86.mk \ 
$(LOCAL_DIR)/generic_mips.mk \ 
$(LOCAL_DIR)/aosp_arm.mk \ 
$(LOCAL_DIR)/full.mk \ 
$(LOCAL_DIR)/aosp_x86.mk \ 
$(LOCAL_DIR)/full_x86.mk \ 
$(LOCAL_DIR)/aosp_mips.mk \ 
$(LOCAL_DIR)/full_mips.mk \ 
$(LOCAL_DIR)/aosp_arm64.mk \ 
$(LOCAL_DIR)/aosp_mips64.mk \ 
$(LOCAL_DIR)/aosp_x86_64.mk \ 
$(LOCAL_DIR)/full_x86_64.mk \ 
$(LOCAL_DIR)/sdk_phone_armv7.mk \ 
$(LOCAL_DIR)/sdk_phone_x86.mk \ 
$(LOCAL_DIR)/sdk_phone_mips.mk \ 
$(LOCAL_DIR)/sdk_phone_arm64.mk \ 
$(LOCAL_DIR)/sdk_phone_x86_64.mk \ 
$(LOCAL_DIR)/sdk_phone_mips64.mk \ 
$(LOCAL_DIR)/sdk.mk \ 
$(LOCAL_DIR)/sdk_x86.mk \ 
$(LOCAL_DIR)/sdk_mips.mk \ 
$(LOCAL_DIR)/sdk_arm64.mk \ 
$(LOCAL_DIR)/sdk_x86_64.mk 

endif 


可 以 看 到 ， 在 确定 产品 定义 时 仍然 会 区 分 当前 是 否 是 全 编译 的 情 
况 。 不 管 是 哪 种 情况 ， 收 集 到 的 产品 定义 项 都 会 放 到 
PRODUCT_MAKEF1LES 中 。 需 要 特别 注意 的 是 ，PRODUCT_MAKEF 1LES 实 际 上 
只 是 一 个 文件 列表 的 集合 ， 那 么 这 些 文件 的 具体 内 容 会 在 什么 时 候 进 行 
解析 呢 ? 答案 就 是 前 述 的 product_config. mk 中 的 get-product- 
makefiles 和 get-al1-product-makefiles。 这 两 个 国 数 会 逐一 取出 
PRODUCT_MAKEF1LES 列 表 中 的 每 一 个 文件 名 ， 组 成 一 个 路 径 ， 然 后 通过 


include 将 脚本 中 的 内 容 读 取 进 来 。 我 们 以 sdk. mk 这 个 列表 项 为 例 ， 它 
的 部 分 内 容 节 选 如 下 : 


/*sdk.mk*/ 
$(call inherit-product, $(SRC_TARGET_DIR)/product/sdk_phone_armv7 
PRODUCT_NAME := sdk 


/*sdk_phone_armv7.mk*/ 

$(call inherit-product, $(SRC_TARGET_DIR)/product/sdk_base.mk) 
# Overrides 

PRODUCT_BRAND := generic 

PRODUCT_NAME := sdk_phone_armv7 

PRODUCT_DEVICE := generic 


/*sdk_base.mk*/ 

PRODUCT_PROPERTY_OVERRIDES := 

PRODUCT_PACKAGES := \ 
ApiDemos \ 
CubeLiveWallpapers \ 
CustomLocale \ 
Development \ 
DevelopmentSettings \ 
Dialer \ 
EmulatorSmokeTests \ 


上 述 的 内 容 可 谓 “ 环 环 相 扣 ”， 颇 有 点 “继承 ”的 关系 。 这 种 实现 
方式 可 以 很 好 地 分 离 各 个 脚本 的 职责 ， 值 得 大 家 借鉴 。 


再 回 到 前 面 的 TARGET_DEV1CE 的 赋值 中 来 。 还 记得 
product_config. mk 中 的 最 后 一 行 是 怎么 给 TARGET_DEVI1CE 赋 值 的 吗 ? 我 
们 再 把 它 列 出 来 : 


TARGET_DEVICE := $(PRODUCTS.$( INTERNAL_PRODUCT ) .PRODUCT_DEVICE ) 


大 家 肯定 会 有 疑问 ， 这 个 PRODUCTS 又 是 从 何 而 来 的 呢 ? 它 是 对 所 有 
产品 的 一 个 记录 集 。 具 体 而 言 ， 就 是 调用 了 product. mk 中 的 import- 
products， 后 者 又 引用 了 import-nodes 一 一 这 个 国 数 则 会 对 PRODUCTS 和 
DEVICES 等 变量 进行 赋值 ， 从 而 才能 保证 TARGET_DEVICE 可 以 取 到 正确 的 
值 。 


总 结 来 说 ， 对 product 的 整个 检查 过 程 无 非 是 做 了 两 件 事 : 


o 对 各 种 变量 进行 赋值 ， 保 证 后 续 编 译 的 正常 运行 ; 

。 在 出 现 错误 时 直接 终止 脚本 运行 ， 从 而 有 效 保证 了 product 的 准确 
性 。 这 一 点 才 是 体现 “合法 性 检查 ”的 关键 核心 ;而 且 当 
check_product 检 查 过 程 中 出 现 错误 时 ，$? 不 为 0， 这 样 函数 退出 后 就 
可 以 通过 这 一 变量 进行 出 错 判断 ， 如 下 所 示 : 

if [ $? -ne0] 
then 
echo 
echo "** Don't have a product spec for: '$product'" 
echo "** Do you have the right repo manifest?" 


product= 
fi 


(2) lunch 对 variant 合 法 性 的 检查 





和 和 check_product 类 似 ， check _var iant 用 于 检查 var iant 的 合法 
性 ， 在 我 们 这 个 例子 中 就 是 “en 


/*/build/envsetup.sh*/ 
VARIANT_CHOICES=(user userdebug eng) 
function check_variant() 


{ 
for v in ${VARIANT_CHOICES[@]} 
do 
if [ "$y" 二 "$1" ] 
then 
return 0 
fi 
done 
return 1 
} 


可 以 看 到 ，check_variant 的 实现 相当 简单 ， 直 接 从 
VARIANT_CHOICES 数 组 〈 只 有 user 、userdebug 和 eng 三 种 ) 中 逐一 取出 
元 素 进行 比较 ， 一 旦 有 匹配 的 就 返回 0; 函数 结束 时 仍然 没有 找到 匹配 
aoa 后 面 一 种 情况 下 ，$? -ne 0 会 被 判定 为 真 ， 因 而 脚本 在 执 

过 程 中 将 打印 出 错误 ， 表 示 当 前 variant 是 无 效 的 。 


3.4.3 make sdk 


本 小 节 我 们 重点 分 析 make sdk 这 一 命令 的 处 理 流 程 ， 它 和 编译 各 种 
系统 image 有 不 小 的 差异 。 


不 过 和 其 他 image 一 样 ，sdk 的 编译 脚本 主体 在 Main. mk 中 。 我 们 节 
选 出 其 中 的 关键 部 分 : 


/*build/core/Main.mk*/ 
is_sdk_build := ## 用 于 标志 当前 是 否 是 sdk 编 译 


ifneq ($(filter sdk win _ sdk sdk_addon,$(MAKECMDGOALS) )，)## 判 断 是 否 : 
is_sdk_build := true 
endif 


ifdef is_sdk_build 

# Detect if we want to build a repository for the SDK 
sdk_repo_goal := $(strip $(filter sdk_repo, $(MAKECMDGOALS) ) ) 
MAKECMDGOALS := $(strip $(filter-out sdk_repo, $(MAKECMDGOALS) ) ) 


ifneq ($(words $(filter-out $(INTERNAL_MODIFIER_TARGETS) checkbui 
target-files-package, $(MAKECMDGOALS) )),1) 

$(error The 'sdk' target may not be specified with any other targ 
endif 


# TODO: this should be eng I think. Since the sdk is built from 
# variant. 

tags_to_install := debug eng 

ADDITIONAL_BUILD_PROPERTIES += xmpp.auto-presence=true 
ADDITIONAL_BUILD_PROPERTIES += ro.config.nocheckin=yes 

else # !sdk 

endif 


# Bring in all modules that need to be built. 
ifeq ($(HOST_OS),windows ) 

SDK_ONLY := true 

endif 


ifeq ($(SDK_ONLY), true) 
include $(TOPDIR)sdk/build/windows_sdk_whitelist.mk 
include $(TOPDIR)development/build/windows_sdk_whitelist.mk 


# Exclude tools/acp when cross-compiling windows under linux 
ifeq ($(findstring Linux, $(UNAME)), ) 

subdirs += build/tools/acp 

endif 


else # !SDK_ONLY 

# 

# Typical build; include any Android.mk files we can find. 
# 

subdirs := $(TOP) 

FULL_BUILD := true 

endif # !SDK_ONLY 


include $(BUILD_SYSTEM) /Makefile 


.PHONY: sdk 
ALL_SDK_TARGETS := $(INTERNAL_SDK_TARGET ) 
sdk: $(ALL_SDK_TARGETS) 
$(call dist-for-goals, sdk win_sdk, \ 
$(ALL_SDK_TARGETS) \ 
$(SYMBOLS_ZIP) \ 
$( INSTALLED _BUILD_PROP_TARGET) 和 


面 这 段 脚 本 的 关键 之 一 在 于 di st-for-goals 这 个 函数 ， 它 的 定义 
如 下 : 


/*build/core/distdir.mk*/ 
define dist-for-goals 
$(foreach file,$(2), \ 
$(eval fw := $(subst :,$(space),$(file))) \ 
$(eval src $(word 1,$(fw))) \ 
$(eval dst := $(word 2,$(fw))) \ 
$(eval dst $(if $(dst),$(dst),$(notdir $(src)))) \ 
$(if $(filter $(_all_dist_src_dst_pairs),$(src):$(dst)),\ ## 如 果 
$(eval $(call add-dependency,$(1),$(DIST_DIR)/$(dst))),\ ## 那 - 
$(eval $(call copy-one-dist-file,\ ## 如 果 没 有 处 理 过 的 情况 
$(src),$(DIST_DIR)/$(dst), $(1)))\ 
$(eval _all_dist_src_dst_pairs += $(src):$(dst))\ 





























jX 


endef 


这 个 函数 用 于 记录 goal 所 需要 的 全 部 src:dst 对 。 它 市 有 两 个 参 
数 ， 即 : 


e $(1) 
代表 目标 对 象 goal 的 集合 ， 比 如 上 面 脚本 中 对 应 的 是 sdk 


win _sdk。 


e $2 


aa ee 定 所 需 的 di st 文件 列表 。 如 果 di st 文件 中 包 
仿冒 号 ， 那 么 “:” 之 后 的 表示 它 在 di st 文件 夹 中 的 名 称 。 


dist-for-goals 函 数 会 遍历 $ (2) 中 di st 文件 列表 的 所 有 fi le， 并 执 
行 以 下 操作 。 


(1) 将 file 包 含 的 冒号 替换 成 空格 。 其 中 subst 和 eval 都 是 
makefile 提 供 的 函数 ，eval 的 函数 原型 为 : 


$(eval arg). 


这 个 函数 比较 特殊 ， 它 可 以 将 其 他 变量 和 防 数 的 解析 结果 添加 到 
make 的 语法 规则 中 。 为 了 达到 这 一 目标 ，eval 的 参数 会 被 扩展 两 次 : 第 
RR 函数 来 扩展 ， 然 后 当 它 被 作为 makef i 1e 语 法 解析 时 又 会 被 

展 一 


(2) fw 的 空格 前 半 部 分 是 src， 后 半 部 分 是 dst。 
(3) if 函数 的 语法 规则 为 : 


$(if <condition>,<then-part> ) 或 者 $(if <condition>,<then-part>,< 


所 以 $(if $ (dst), $(dst), $(notdir $(src)) ) 的 意思 就 是 如 果 dst 
不 为 空 ， 那 么 就 取 dst 作 为 结果 ; 否则 取 src 路 径 中 的 文件 名 作为 结果 。 
这 样 就 保证 了 用 户 没 有 特别 指定 dst 的 情况 下 它 有 一 个 默认 值 。 


(4) filter 国 数 的 语法 规则 为 : 


$(filter <pattern..>,<text> ) 


5 即 应 用 pattern 模 式 来 过 滤 text 中 的 内 容 ， 人 允许 有 多 个 pattern 存 
Æ. 


所 以 $ (Filter $( all dist src dst pairs), $ (src):$(dst)) 用 
于 判断 src:dst 这 个 组 合 对 在 al1 dist src dst pairs 中 是 否 已 经 存 
在 。 如 果 是 的 话 ， 接 下 来 就 只 调用 add-dependency 来 为 g0al 添 加 依赖 关 
A; 否则 就 需要 将 其 复制 到 dst 中 。 


我 们 再 回 到 main. mk 中 。 可 以 看 到 ，sdk 这 个 目标 依赖 于 
$ (ALL_SDK_TARGETS) ， 即 $(CINTERNAL_SDK_TARGET) ， 那 么 后 面 这 个 变量 
又 是 从 哪 来 的 呢 ? 


答案 就 是 bui1d/core/Makefile， 它 会 被 include 到 main. mk 中 : 
include $(BUILD SYSTEM)/Makefile 
不 光 是 sdk， 实 际 上 大 部 分 系统 image 的 依赖 关系 都 是 在 Makefi le 这 


个 文件 中 指定 的 ， 可 以 说 它 是 这 些 目标 生成 规则 的 “集大成 者 ”。 我 们 
看 一 下 与 sdk 相 关 的 部 分 : 


/*build/core/Makefile*/ 
INTERNAL_SDK_TARGET := $(Sdk_dir)/$(sdk_name).zip ####Comment 1 


$(INTERNAL_SDK_TARGET): $(deps)####Comment 2 
@echo "Package SDK: $@" 
$(hide) rm -rf $(PRIVATE_DIR) $@ 





if [ $$FAIL ]; then exit 1; fi ## 如 果 执 行 过 程 中 产生 错误 ， 直 接 结束 
$(hide) echo $(notdir $(SDK_FONT_DEPS)) | tr " " "\n" > $(S 
$(hide) ( \ 
ATREE_STRIP="Sstrip -x" \ 
$(HOST_OUT_EXECUTABLES)/atree \ ####Comment 3 
$(addprefix -f ,$(PRIVATE_INPUT_FILES)) \ 
-m $(PRIVATE_DEP_FILE) \ 
-I .\ 
-I $(PRODUCT_OUT) \ 
-I $(HOST_OUT) \ 
-I $(TARGET_COMMON_OUT_ROOT) \ 
-V "PLATFORM_NAME=android-$(PLATFORM_VERSION)" \ 
-v "OUT_DIR=$(OUT_DIR)" \ 
-v "HOST_OUT=$(HOST_OUT)" \ 
-V "TARGET_ARCH=$(TARGET_ARCH)" \ 
-V "TARGET_CPU_ABI=$(TARGET_CPU_ABI)" \ 
-V "DLL_EXTENSION=$(HOST_SHLIB_SUFFIX)" \ 
-V "FONT_OUT=$(SDK_FONT_TEMP)" \ 
-0 $(PRIVATE_DIR) && \ 
$(PRIVATE_DIR)/system-images/android-$(PLATFORM_VERSION) /$(T 
cp -f $(tools_notice_file_txt) $(PRIVATE_DIR)/platform- 
HOST_OUT_EXECUTABLES=$(HOST_OUT_EXECUTABLES) HOST_OS=$( 
development/build/tools/sdk_clean.sh $(PRIVATE_DIR 
chmod -R ug+rwX $(PRIVATE_DIR) && \ 
cd $(dir $@) && zip -rq $(notdir $@) $(PRIVATE_NAME) \ 
) || ( rm -rf $(PRIVATE_DIR) $@ && exit 44 ) 


Comment 1: J% INTERNAL SDK TARGET 赋值 为 
$(sdk_dir)/$ (sdk_name) .zip， 其 中 sdk_ dir 指 的 是 
$ (HOST_OUT) /sdk/$ (TARGET_PRODUCT) , 
Bll /out/host/sdk/$ (TARGET PRODUCT) ;而 sdk_name 则 为 android- 
sdk_$ (FILE_NAME_TAG) ， 典 型 情况 下 的 值 为 : 


# linux -x86 --> android-sdk_12345 linux-x86 
# darwin-x86 --> android-sdk_12345 mac-x86 
# windows-x86 --> android-sdk_12345 windows 


Comment 2: INTERNAL SDK TARGET := 
$ (sdk_dir)/$ (sdk_name) .zip， 下 面 是 这 个 变量 在 典型 情况 下 的 值 为 : 
out/host/ | inux-x86/sdk/sdk/android-sdk_eng. s_| inux-x86. zip. 


由 前 面 的 分 析 可 知 ，sdk 这 个 伪 目 标 依赖 于 INTERNAL_SDK_TARGET， 
后 者 则 实际 上 依赖 于 $ (deps) 这 个 变量 是 一 个 生成 物 的 列表 ， 如 下 
截图 是 部 分 节选 : 





deps=out/target/product/generic/obj/NOTICE.txt out/host/linux-x86/obj/ 
NOTICE.txt out/target/common/docs/offline-sdk-timestamp out/target/product/ 
generic/sdk-symbols-eng.s.zip out/target/product/generic/system.img out/target/ 
product/generic/userdata.img out/target/product/generic/ramdisk.img out/target/ 
product/generic/sdk/sdk-build.prop out/target/product/generic/system/ 

build.prop out/target/product/generic/system/bin/monkey out/target/product/ 
generic/system/usr/share/bmd/RFFspeed_501.bmd out/target/product/generic/system/ 
usr/share/bmd/RFFstd_501.bmd out/target/product/generic/system/bin/bmgr out/ 
target/product/generic/system/bin/ime out/target/product/generic/system/bin/ 
input out/target/product/generic/system/bin/pm out/target/product/generic/ 
system/bin/svc out/host/linux-x86/bin/aapt out/host/linux-x86/bin/adb out/host/ 
Linux-x86/bin/aidl out/host/linux-x86/bin/backtrace_test32 out/host/linux-x86/ 
bin/backtrace_test64 out/host/linux-x86/bin/bcc out/host/linux-x86/bin/ 
bec_compat out/host/lLinux-x86/bin/dalvikvm out/host/Linux-x86/bin/dalvikvm32 
out/host/lLinux-x86/bin/dalvikvm64 out/host/lLinux-x86/bin/dex2oat out/host/1linux- 
x86/bin/dexdeps out/host/linux-x86/bin/dexdump out/host/lLinux-x86/bin/dexlist 
out/host/Linux-x86/bin/dmtracedump out/host/lLinux-x86/bin/dx out/host/lLinux-x86/ 
bin/etcitool out/host/linux-x86/bin/fastboot out/host/linux-x86/bin/ 
hierarchyviewer1 out/host/linux-x86/bin/hprof-conv out/host/linux-x86/bin/1ld.mc 
out/host/lLinux-x86/bin/1Llvm-rs-cc out/host/lLinux-x86/bin/make_ext4fs out/host/ 
Linux-x86/bin/oatdump out/host/lLinux-x86/bin/patchoat out/host/linux-x86/bin/ 
simpleperf out/host/linux-x86/bin/split-select out/host/linux-x86/bin/sqlite3 
out/host/lLinux-x86/bin/tzdatacheck out/host/linux-x86/bin/zipalign out/host/ 
Linux-x86/framework/commons-compress-1.0.jar out/host/linux-x86/framework/ 
dexdeps. jar out/host/linux-x86/framework/dx. jar out/host/linux-x86/framework/ 
emmalib. iar out/host/lLinux-x86/framework/hierarchvviewer. iar out/host/Linux-x86/ 


它 代 表 了 生成 sdk 需 要 编译 的 所 有 中 间 产 物 。 那 么 这 么 多 文件 内 容 
又 是 如 何 产生 的 呢 ? 


/*build/core/Makefile*/ 


deps := \ 
$(target_notice_file_txt) \ 
$(tools_notice_file_txt) \ 
$(OUT_DOCS)/offline-sdk-timestamp \ 
$(SYMBOLS_ZIP) \ 
$(INSTALLED_SYSTEMIMAGE) \ 
$(INSTALLED_USERDATAIMAGE_TARGET) \ 
$(INSTALLED_RAMDISK_TARGET) \ 
$(INSTALLED_SDK_BUILD_PROP_TARGET) 和 
$(INSTALLED_BUILD_PROP_TARGET) 和 
$(ATREE_FILES) \ 
$(sdk_atree_files) \ 
$(HOST_OUT_EXECUTABLES)/atree \ 
$(HOST_OUT_EXECUTABLES)/line_endings \ 
$(SDK_FONT_DEPS) 


我 们 知道 ，SDK 包 含 的 东西 比较 多 ， 除 了 各 种 文档 和 framework 中 间 
44 (android. jar) 外 ， 还 有 平台 工具 、 字 体 ， 以 及 各 种 image 文 件 〈 如 
system 和 userdata， 这 些 都 是 模拟 器 运行 所 必需 的 ) 等 。 


因为 deps 变 量 所 涉及 的 内 容 比较 多 ， 我 们 接 下 来 会 挑选 
android. jar 这 个 最 重要 的 文件 作为 例子 进行 讲解 ， 读 者 也 可 以 根据 需 
要 自行 分 析 其 他 产物 。 


Comment 3: 可 以 看 到 deps 变 量 中 有 不 少 与 atree 相 关 的 文件 ， 它 们 
是 sdk 最 终 产 物 的 描述 文件 。 比 如 下 面 这 个 范例 : 


/*development/build/sdk.atree*/ 


# host tools from out/host/$(HOST_OS)-$(HOST_ARCH) / 


bin/adb strip platform-tools/adb 

bin/fastboot strip platform-tools/fast 
bin/sqlite3 strip platform-tools/sqli 
bin/dmtracedump strip platform-tools/dmtr 
bin/etcitool strip platform-tools/etc1 
bin/hprof -conv strip platform-tools/hpro 


Atree 文 件 中 的 内 容 分 为 两 列 ， 左 边 一 列表 达 的 是 “source”， 碳 
WMI “destination” 。 大 家 应 该 已 经 想到 了 ， 既 然 有 atree 格 式 的 描 


述 文 件 ， 那 么 一 定 会 有 工具 来 解析 这 些 格式 。 


完成 这 一 任务 的 是 atree， 它 所 支持 的 主要 参数 选项 及 释义 如 表 3-8 
PIT ZR o 


323-8 工具 atree 人 参数 选项 表 


| ome | | 
FILELIST 是 文件 列表 ， 其 中 的 文件 用 于 记录 需 

[ | 要 被 复制 的 一 系列 文件 名 

anvon | ra 目录 ， 帮 助 atree 碍 找 上 述 的 被 复制 文 

cca | 指定 复制 的 目标 路 径 





ho 使 用 硬 链 接 ， 而 不 是 真 的 复制 文件 
—_ 输出 一 个 make 格 式 的 文件 


-v VAR=VAL | 在 读 取 输 入 文件 过 程 中 ， 将 $VAR 蔡 换 成 VAL 


ex 用 于 输出 额外 的 信息 


对 照 上 述 的 参数 选项 列表 ， 我 们 再 来 重点 看 下 Comment 3 部 分 的 实 
现 : 





ATREE_STRIP="Strip -x" \ 
$(HOST_OUT_EXECUTABLES)/atree \ ####Comment 3 
$(addprefix -f ,$(PRIVATE_INPUT_FILES)) \ ####-fiJi 


-m 
-I 
-I 
=E 
-I 
-V 
-V 
-V 
-V 
-V 
-V 
-V 
-0 


$(PRIVATE_DEP_FILE) \ 

> 

$(PRODUCT_OUT) \ 

$(HOST_OUT) \ 
$(TARGET_COMMON_OUT_ROOT) \ 
"PLATFORM_NAME=android-$(PLATFORM_VERSION)" \ 
"OQUT_DIR=$(OUT_DIR)" \ 
"HOST_OUT=$(HOST_OUT)" \ 
"TARGET_ARCH=$(TARGET_ARCH)" \ 
"TARGET_CPU_ABI=$(TARGET_CPU_ABI)" \ 
"DLL_EXTENSION=$(HOST_SHLIB_SUFFIX)" \ 
"EONT_OUT=$(SDK_FONT_TEMP)" \ 
$(PRIVATE_DIR) && \ 


其 中 ，-f 选 项 所 带 的 参数 是 $ (PRIVATE_INPUT_FILES) ， 后 者 因为 是 
一 个 文件 列表 ， 所 以 需要 通过 addpref ix 为 它们 全 部 加 上 -f 选 项 。 那 么 
$ (PRIVATE_INPUT_FILES) 具体 包含 了 哪些 文件 呢 ? 


由 前 面 的 脚本 文件 不 难 分 析出 ，$ (PRIVATE_INPUT_FILES) 实际 上 等 
价 于 sdk_atree_files， 进 一 步 来 讲 ， 就 是 包含 了 如 下 的 文件 : 
sdk_atree_files := \ 


$(atree_dir)/sdk.exclude.atree \ 
$(atree_dir )/sdk-$(HOST_OS) -$(SDK_HOST_ARCH) .atree 


$(atree_dir)/sdk-android-$(TARGET_CPU_ABI) .atree 


$(atree_dir)/sdk.atree 


其 中 atree_ dir 指 定 的 是 development/bui 1d， 这 个 目录 下 包含 了 不 
少 atree 文 件 ， 如 下 所 示 : 


__| sdk.atree 

|_| sdk.exclude.atree 

|_| sdk-android-arm64-v8a.atree 
__| sdk-android-armeabi.atree 

__| sdk-android-armeabi-v7a.atree 
__| sdk-android-mips.atree 

__| sdk-android-x86.atree 

__| sdk-android-x86_64.atree 

__| sdk-darwin-x86.atree 

__| sdk-linux-x86.atree 


|_| sdk-windows-x86.atree 


以 我 们 关心 的 android. jar 为 例 ， 与 它 相对 应 的 描述 语句 如 下 所 


/小 : 


# the uper-jar file that apps link against. This is the public AP 
${OUT_DIR}/target/common/obj/PACKAGING/android_jar_intermediates/ 
platforms/${PLATFORM_NAME}/android. jar 


也 就 是 说 ， 通 过 atree 文 件 可 以 将 out 目 录 下 编译 生成 的 
android. jar 复 制 到 sdk 目 标 路 径 下 的 platforms/$ {PLATFORM_NAME} / 文 
件 夹 中 。 现 在 的 问题 转变 为 ，android. jar 又 是 如 何 生 成 的 呢 ? 


答案 就 在 development/bui 1d/Android. mk 中 ， 我 们 一 起 来 看 一 下 : 


# ===== SDK jar file of stubs ===== 
# A.k.a the "current" version of the public SDK (android.jar insi 
sdk_stub_name := android_stubs_current 


stub_timestamp := $(OUT_DOCS)/api-stubs-timestamp 
include $(LOCAL_PATH)/build_android_stubs.mk 


.PHONY: android_stubs 
android_stubs: $(full_target) 


# android.jar is what we put in the SDK package. 
android_jar_intermediates := $(TARGET_OUT_COMMON_INTERMEDIATES) /P 
android_jar_full_target := $(android_jar_intermediates)/android. j 





$(android_jar_full_target): $(full_target ) 
@echo Package SDK Stubs: $@ 
$(hide)mkdir -p $(dir $@) 
$(hide)$(ACP) $< $@ 





ALL_SDK_FILES += $(android_jar_full_target) 





其 中 android jar full target 是 android. jar 中 out 目 录 中 的 绝对 
路 径 ， 即 
$ (TARGET_OUT_COMMON_ INTERMED I ATES) /PACKAGING/android jar_interr 
而 且 它 依赖 于 ful1_target 变 量 一 一 从 名 称 上 可 以 猪 到 ， 这 个 变量 用 于 
记录 所 有 android. jar 包 中 所 需 的 文件 。 根 据 make 的 规则 ， 一 旦 
full_target 比 目标 android_jar_full_target 新 ， 那 么 就 会 执行 以 下 的 
命令 ， 包 括 : 


e 打印 出 “Package SDK Stubs:[ 目 标 对 象 ] o 

e 新 建 andtoid_jaf_full_tatset 所 指向 的 目录 ， 即 
$(TARGET_OUT_COMMON_INTERMEDIATES) / 
PACKAGING /android_jar_intermediates o 


。 调 用 $(ACP) 执 行 实际 的 复制 和 打包 工作 。 


$ (ACP) 是 Android 编 译 系统 提供 的 专门 用 于 跨 平 台 复制 的 一 个 工 
具 ， 源 码 路 径 是 /bui1d/tools/acp。 它 的 用 法 如 下 : 


acp [OPTION] SOURCE DEST 
那么 SOURCE， 即 full_target 包 含 了 哪些 内 容 呢 ? 


我 们 需要 在 bui 1d_android_stubs. mk 中 寻找 答案 ， 如 下 所 示 : 


/*development/build/build_android_stubs.mk*/ 

# Build an SDK jar file out of the generated stubs 

intermediates := $(TARGET_OUT_COMMON_INTERMEDIATES)/JAVA_LIBRARIE 
full_target := $(intermediates)/classes.jar 

src_dir := $(intermediates)/src 

classes_dir := $(intermediates)/classes 

framework_res_package := $(call intermediates-dir-for,APPS, framew 


$(full_target): PRIVATE_SRC_DIR := $(src_dir) 

$(full_target): PRIVATE_INTERMEDIATES DIR := $(intermediates ) 
$(full_target): PRIVATE_CLASS INTERMEDIATES DIR := $(classes_dir) 
$(full_target): PRIVATE_FRAMEWORK_RES_PACKAGE := $(framework_res_ 


$(full_target): $(stub_timestamp) $(framework_res_package) 
@echo Compiling SDK Stubs: $@ 
$(hide) rm -rf $(PRIVATE_CLASS_INTERMEDIATES_DIR) ###Step1 


$(hide) mkdir -p $(PRIVATE_CLASS_INTERMEDIATES_DIR) 
$(hide) find $(PRIVATE_SRC_DIR) -name "*.java" > \ 
$(PRIVATE_INTERMEDIATES_DIR)/java-source-list ###Step2 
$(hide) $(TARGET_JAVAC) -encoding ascii -bootclasspath "" \ 
-g $(xlint_unchecked) \ 
-extdirs "" -d $(PRIVATE_CLASS_INTERMEDIATES_DIR) 
\@$(PRIVATE_INTERMEDIATES_DIR)/java-source-list \ 
|| ( rm -rf $(PRIVATE_CLASS_INTERMEDIATES_DIR) ; exit 4 
$(hide) if [ ! -f $(PRIVATE_FRAMEWORK_RES PACKAGE) ]; then \ 
echo Missing file $(PRIVATE_FRAMEWORK_RES_ PACKAGE); \ 
rm -rf $(PRIVATE_CLASS_INTERMEDIATES_DIR); \ 
exit 1; \ 
fi; ###Step4 
$(hide) unzip -qo $(PRIVATE_FRAMEWORK_RES_PACKAGE) -d $(PRIV 
$(hide) (cd $(PRIVATE_CLASS_INTERMEDIATES_ DIR) && rm -rf cla 
$(hide) mkdir -p $(dir $@) 
$(hide) jar -cf $@ -C $(PRIVATE_CLASS_INTERMEDIATES_DIR) . 
$(hide) jar -uof $@ -C $(PRIVATE_CLASS_INTERMEDIATES_DIR) re 


脚本 bui ld android stubs. mk 有 两 个 类 似 于 入 人 参 的 变量 ， 分 别 是 


(1) sdk stub name: SDK stub 的 名 称 。Stub 源 代码 应 该 已 经 生成 
在 
$ (TARGET OUT COMMON INTERMED I ATES) /JAVA LIBRARIES/$ (sdk stub _n: 
目录 中 。 在 这 个 例子 中 对 应 的 就 是 
$ (TARGET OUT COMMON INTERMED I ATES) /JAVA LIBRARIES/android stubs 


(2) stub_timestamp: 生成 的 源码 所 依赖 的 时 间 戳 文件 


总 的 来 说 ，bui 1d_android_stubs. mk 脚本 的 目标 是 编译 一 
classes. jar， 换 句 话 讲 就 是 我 们 需要 的 android. jar 。 而 被 编译 的 所 有 
源 文件 必须 已 经 生成 到 上 述 的 android_ stubs current intermediates 
ores 这 是 由 droiddoc. mk 来 完成 的 ， 我 们 后 续 将 会 有 进一步 分 


现在 先 来 看 一 下 如 何 编译 和 打包 classes. jar 〈 即 脚本 中 的 
full _ target 变量 ) 。 


Step. 首先 通过 整个 文件 夹 删除 来 清理 掉 
$ (intermediates) /classes 目 录 中 的 内 容 ， 然 后 再 重新 创建 这 个 文件 
夹 。 


Step2， 查 找 $ (intermediates) /src 目 录 下 以 “java” 为 后 组 的 所 
有 文件 ， 并 把 结果 记录 到 $ (intermediates)/java-source-list 中 ， 以 
供 后 续 使 用 。 


Step3. 这 是 关键 的 一 个 步骤 ， 即 通过 调用 javac 来 完成 编译 工作 。 
其 中 encoding 人 参数 用 于 指明 文件 的 编码 格式 ， 以 保证 编译 能 顺利 进行 。 
其 他 参数 的 官方 释义 如 图 3-17 所 示 。 


-0 Generate all debugging info 

-g:none Generate no debugging info 

-qi{lines,vars,source} Generate only some debugging info 

-nowarn Generate no warnings 

-verbose Output messages about what the compiler is doing 

-deprecation Output source locations where deprecated APIs are used 
-classpath <path> Specify where to find user class files and annotation processors 
-cp <path> Specify where to find user class files and annotation processors 
-sourcepath <path> Specify where to find input source files 

-bootclasspath <path> Override location of bootstrap class files 

-extdirs <dirs> Override location of installed extensions 

-endorseddirs <dirs> Override location of endorsed standards path 

-proc:{none, only} Control whether annotation processing and/or compilation is done. 
-processor <classi1>[ ,<class2>,<class3>...] Names of the annotation processors to run; bypasses default discovery process 
-processorpath <path> Specify where to find annotation processors 

-d <directory> Specify where to place generated class files 

-s <directory> Specify where to place generated source files 
-inplicit:{none,class} Specify whether or not to generate class files for implicitly referenced files 
-encoding <encoding> Specify character encoding used by source files 

-Source <release> Provide source compatibility with specified release 

-target <release> Generate class files for specific VM version 

-version Version information 

-help Print a synopsis of standard options 

-Akey[=value] Options to pass to annotation processors 

-X Print a synopsis of nonstandard options 

"J<flag> pass <flag> directly to the runtime systen 

-Werror Terminate compilation if warnings occur 

@<filenane> Read options and filenames from file 





全 图 3-17 官方 释义 


最 后 通过 @<fi 1ename》 来 把 前 一 步 生 成 的 java-source-1ist 中 记录 
的 所 有 Java 文 件 读 取出 来 ， 然 后 执行 编译 过 程 ， 中 间 文 件 输出 到 


$ (intermediates) /classes 中 。 


Step4， 如 果 PRIVATE_FRAMEWORK_RES_PACKAGE 文 件 缺 失 ， 则 终止 操 
作 并 报错 。 


Step5， 这 一 步 主要 是 针对 前 述 的 步骤 进行 清理 和 打包 工作 。 


首先 将 framework_res_package 所 指向 的 apk 通 过 unz ip 命令 进行 解 
压 ， 结 果 也 同样 输出 到 $ (intermediates) /classes 中 。 在 以 后 章节 的 学 
习 中 我 们 会 发 现 ，apk 实 际 上 就 是 zip 包 。 大 家 可 以 尝试 在 Windows 操 作 
系统 下 通过 WinRAR 等 类 似 软件 打开 一 个 实际 的 apk 自 行 验证 下 。 紧 接着 
删除 掉 解 压 后 的 classes. dex 和 META-1NF 文 件 夹 ， 换 言 之 我 们 要 的 是 apk 
中 的 res 目 录 和 resources. arsc。 


一 切 准 备 就 结 ， 现 在 就 只 剩 下 打包 了 。 大 家 应 该 已 经 猜 到 了 ， 
classes. jar 就 是 $ (intermediates)/ classes 文 件 夹 内 容 的 集成 。 具 体 
操作 分 为 两 步 ， 即 : 


jar -cf $@ -C $(PRIVATE_CLASS_INTERMEDIATES_DIR) . 


创建 classes. jar 文 件 ， 然 后 将 $ (intermediates) /classes 内 容 打 
包 进 去 。 


jar -uOf $@ -C $(PRIVATE_CLASS_INTERMEDIATES_DIR) resources. 

更 新 jar 包 。 

接 下 来 我 们 再 分 析 一 下 $ (intermediates) /src 中 的 源 文 件 是 如 何 生 
成 的 。 

大 家 可 以 先 思考 一 下 ， 最 有 可 能 生成 stub source 的 脚本 是 哪 一 


个 ?回答 这 个 问题 ， 要 先 了 解 android. jar 中 的 内 容 是 什么 。 我 们 来 看 
图 3-18 所 示 的 表面。 


J android 





d java 

J javax 

BD junit 

J META-INF 

org 

i res 

|_| AndroidManifest.xml 122,908 
|_| resources.arsc 11,756,656 


全 图 3-18 android jar F TSH A R 


是 不 是 感觉 非常 熟悉 ? 没 错 ， 它 们 和 framework 的 组 成 基本 上 是 一 
致 的 ， 只 不 过 后 者 包含 了 实现 体 ， 而 android. jar 只 是 “ 空 达 ”， 即 
Stub (#E) ， 如 图 3-19 所 示 。 








国 国 android.jar\android\view - ZIP 压缩 文件 , 解 包 大 小 为 29,372,141 $5 





名 称 





|_| View$OnLongClickListener.class 
|_| View$OnSystemUiVisibilityChangeListener.class 


|_| View$OnTouchListener.class 





|_| ViewAnimationUtils.class 

|_| ViewConfiguration.class 

|_| ViewDebug$CapturedViewProperty.class 
| | ViewDebug$ExportedProperty.class 





public View(Context context) { 
throw new RuntimeException( "Stub! ”); 


} 


public View(Context context, AttributeSet attrs) { 
throw new RuntimeException( "Stub! ”); 


} 


public View(Context context, AttributeSet attrs, imt defStyleAttr) { 
throw new RuntimeException( "Stub! ”); 


} 


public View(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) { 
throw new RuntimeException( "Stub! ”): 


} 


public String toString() { 
throw new RuntimeException( "Stub! ”); 


} 


A 43-19 android.jar 中 不 包含 实现 体 
(Æ: android/view 目 录 下 的 View.class Æ: View.class 中 的 所 有 函数 体 实 现 都 只 是 抛 出 一 个 异 


常 。) 


所 以 生成 android. jar 所 需 Stub 源 码 的 地 方 很 可 能 在 framework 中 ， 
即 /frameworks/base/ Android. mk。 我 们 来 实际 验证 一 下 : 


三 三 三 三 the system api SDDS 三 全 三 三 三 三 三 三 三 三 三 三 三 二 三 三 三 三 三 三 三 二 三 三 三 三 三 三 三 三 三 三 三 三 
include $(CLEAR_VARS) 


LOCAL_SRC_FILES:=$(framework_docs_LOCAL_API_CHECK_SRC_FILES) 
LOCAL_INTERMEDIATE_SOURCES:=$( framework_docs_LOCAL_INTERMEDIATE_S 
LOCAL_JAVA_LIBRARIES:=$(framework_docs_LOCAL_API_CHECK_JAVA_LIBRA 
LOCAL_MODULE_CLASS:=$(framework_docs_LOCAL_MODULE_CLASS) 
LOCAL_DROIDDOC_SOURCE_PATH:=$(f ramework_docs_LOCAL_DROIDDOC_SOURC 
LOCAL_DROIDDOC_HTML_DIR:=$(framework_docs_LOCAL_DROIDDOC_HTML_DIR 
LOCAL_ADDITIONAL_JAVA_DIR:=$( framework_docs_LOCAL_API_CHECK_ADDIT 
LOCAL_ADDITIONAL_DEPENDENCIES: =$( f ramework_docs_LOCAL_ADDITIONAL_ 








LOCAL_MODULE := system-api-stubs 


LOCAL_DROIDDOC_OPTIONS: =\ 
$(framework_docs_LOCAL_DROIDDOC_OPTIONS) \ 
-stubs $(TARGET_OUT_COMMON_INTERMEDIATES )/JAVA_LIBRARIE 
-showAnnotation android.annotation.SystemApi \ 


-api $(INTERNAL_PLATFORM_SYSTEM_API_FILE) \ 
-removedApi $( INTERNAL_PLATFORM_SYSTEM_REMOVED_API_FILE 
-nodocs 


LOCAL_DROIDDOC_CUSTOM_TEMPLATE_DIR:=build/tools/droiddoc/template 


LOCAL_UNINSTALLABLE_MODULE := true 
include $(BUILD_DROIDDOC) 


果然 如 此 。 有 具体 生成 stub 借 助 的 是 droiddoc， 也 就 是 
BUILD_DRO1DD0C 变 量 所 指向 的 droi ddoc. mk: 


/*build/core/config.mk*/ 


BUILD_DROIDDOC: = $(BUILD_SYSTEM) /droiddoc.mk 


在 调用 这 个 脚本 之 前 ， 需 要 给 几 个 重要 的 变量 赋值 ， 包 括 
LOCAL_MODULE_CLASS、LOCAL_SRC_FILES 和 LOCAL_DRO1DDOC_OPT1ONS 
=. 


这 些 变量 将 作为 droiddoc 最 终 产 生 目 标 “ 文 档 ” 产 物 的 基础 一 一 在 
我 们 这 个 例子 中 ，“ 文 档 ” 意 味 着 stub source。 


我 们 只 市 选 droiddoc. mk 中 与 最 终 产 物 生成 有 关联 的 语句 ， 以 便 大 
家 可 以 更 好 地 理解 整个 过 程 : 


ifneq ($(strip $(LOCAL_DROIDDOC_USE_STANDARD_DOCLET)),true) ###dr 


else ###}x(Edoclet 737 
$(full_target): $(full_src_files) $(full_java_lib_deps) 
@echo Docs javadoc: $(PRIVATE_OUT_DIR) 
@mkdir -p $(dir $@) 
$(call prepare-doc-source-list, $(PRIVATE_SRC_LIST_FILE),$(PR 
$(PRIVATE_SOURCE_INTERMEDIATES_DIR) $(PRIVATE_ADDI 
$(hide) ( \ 
javadoc \、###javadoc 是 生成 doc 的 关键 ,其余 工作 都 是 围绕 它 展开 的 
-encoding UTF-8 \ 
$(PRIVATE_DROIDDOC_OPTIONS) \ 
\@$(PRIVATE_SRC_LIST_FILE) \ 
-J-Xmx1024m \ 
-XDignore.symbol.file \ 
$(PRIVATE_PROFILING_OPTIONS) \ 
$(addprefix -classpath ,$(PRIVATE_CLASSPATH)) \ 
$(addprefix -bootclasspath ,$(PRIVATE_BOOTCLASSPA 











-sourcepath $(PRIVATE_SOURCE_PATH)$(addprefix :,$ 
-d $(PRIVATE_OUT_DIR) \ 
-quiet \ 
&& touch -f $@ \ 
) || (rm -rf $(PRIVATE_OUT_DIR) $(PRIVATE_SRC_LIST_FILE); exi 
endif 


目前 编译 系统 对 doclet 的 实现 方式 进行 了 改进 ， 从 而 出 现 了 上 述 脚 
本 中 的 if 和 和 else 语句， 即 标准 的 doclet 和 doclava。 不 过 这 些 并 不 是 我 
ue 需要 关心 的 重点 ， 读 者 有 兴趣 的 话 可 以 自行 查阅 相关 资料 进行 分 


相信 大 家 应 该 都 听 说 过 javadoc 这 个 工具 ， 它 的 基本 用 法 如 图 3-20 
所 示 o 


这 样 一 来 android. jar 所 需 的 stub 就 可 以 成 功 生 成 了 ， 其 他 的 中 间 
件 的 处 理 过 程 也 是 类 似 的 。 一 旦 它们 都 处 于 Ready 状 态 后 ，make sdk 就 
可 以 将 它们 打包 ， 并 最 终 完成 Android SDK 的 编译 。 


usage: javadoc [options] 
-overview <file> 

-public 

-protected 

-package 

-private 

-help 

-doclet <class> 
-docletpath <path> 
-sourcepath <pathlist> 
-classpath <pathlist> 
-exclude <pkglist> 
-subpackages <subpkglist> 
-breakiterator 
-bootclasspath <pathlist> 


-source <release> 
-extdirs <dirlist> 
-verbose 

-locale <name> 
-encoding <name> 


[packagenames] [sourcefiles] [@files] 

Read overview documentation from HTML file 

Show only public classes and members 

Show protected/public classes and members (default) 
Show package/protected/public classes and members 
Show all classes and members 

Display command line options and exit 

Generate output via alternate doclet 

Specify where to find doclet class files 

Specify where to find source files 

Specify where to find user class files 

Specify a list of packages to exclude 

Specify subpackages to recursively load 

Compute 1st sentence with BreakIterator 

Override location of class files loaded 

by the bootstrap class loader 

Provide source compatibility with specified release 
Override location of installed extensions 

Output messages about what Javadoc is doing 
Locale to be used, e.g. en_US or en_US WIN 

Source file encoding name 

Do not display status messages 

Pass <flag> directly to the runtime system 

Print a synopsis of nonstandard options 


Provided by Standard doclet: 
-d <directory> 


-docfilessubdirs 
-splitindex 
-windowtitle <text> 


Destination directory for output files 
Create class and package usage pages 
Include @version paragraphs 

Include @author paragraphs 

Recursively copy doc-file subdirectories 
Split index into one file per letter 
Browser window title for the documenation 
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3.5 Android 系统 GDB 调 试 


GDB 是 GNU Project Debugger 的 缩写 ， 它 也 是 很 多 开源 软件 的 调试 
利器 。 对 于 Android 这 样 一 个 庞大 的 系统 ， 难 免 会 在 开发 过 程 中 遇 到 一 
些 “ 难 缠 ” 的 问题， 这 其 中 一 个 非常 重要 的 解决 办 法 就 是 通过 GDB 进 行 
调试 ， ee i ee Ee cae 
典型 用 法 。 


实际 上 Android 编 译 系统 也 已 经 为 开发 者 使 用 6DB 做 了 一 些 便利 的 工 
作 ， 如 /bui 1d/envsetup. sh: 


function gdbclient() 
{ 
local OUT_ROOT=$(get_abs_build_var PRODUCT_OUT) ## 得 到 out 目 录 
local OUT_SYMBOLS=$(get_abs_build_var TARGET_OUT_UNSTRIPPED) 
local OUT_SO_SYMBOLS=$(get_abs_build_var TARGET_OUT_SHARED_LIB 
local OUT_VENDOR_SO_SYMBOLS=$(get_abs_build_var TARGET_OUT_VEN 
_UNSTRIPPED) 
local OUT_EXE_SYMBOLS=$(get_symbols_directory) 
## 得 到 Symbols 目 录 ， 这 是 GDB 将 目标 对 象 与 源 文 件 进行 对 应 的 关键 





local PREBUILTS=$(get_abs_build_var ANDROID_PREBUILTS) 
##Prebuilts 目 录 下 有 很 多 GDB 相 关 的 工具 

local ARCH=$(get_build_var TARGET_ARCH) ##ARCH 决 定 了 需要 使 用 哪 一 个 
local GDB 











case "$ARCH" in 
arm) GDB=arm-linux-androideabi-gdb; ; 
arm64) GDB=arm-linux-androideabi-gdb; GDB64=aarch64-1linux- 
mips|mips64) GDB=mips64el1-1linux-android-gdb; ; 
x86) GDB=x86_64-1linux-android-gdb; ; 
x86_64) GDB=x86_64-1linux-android-gdb; ; 
*) echo "Unknown arch $ARCH"; return 1;; 
esac 大 # 通 过 ARCH 来 选 定 GDB 客 户 端 ， 通 常 这 些 客户 端 工具 保存 在 prebuilts 目 录 - 





if [ "$OUT_ROOT" -a "$PREBUILTS" ]; then 
local EXE="$1" ###EXE 代 表 的 是 需要 被 调试 的 应 用 程序 
if [ "$EXE" ] ; then 
EXE=$1 
if [[ $EXE =~ A[A/].* ]] ; then 
EXE="system/bin/"$EXE 





Fi 
else 





EXE="app_process" ## 默 认 情 况 下 调试 app_process 





fi 





local PORT="$2" ## 端 口号 ， 必 须 与 gdbserver 保 持 一 致 
if [ "$PORT" ] ; then 

PORT=$2 
else 

PORT=" :5039" ## 端 口号 默认 为 5039 





fi 











local PID="$3" ##PID 表 示 被 调试 对 象 的 进程 号 ， 也 可 以 只 提供 进程 名 ， 后 
if [ "$PID" ] ; then 





if [[ ! "$PID" =~ 人 ^[0-9]+$ ]] ; then 
PID=*pid $3` 
if [[ ! "$PID" =~ A[O-9]+$ ]] ; then 
PID='adb shell ps | \grep $3 | \grep -v ":" | 
if [[ ! "$PID" =~ A[O-9]+$ ]] 
then 
echo "Couldn't resolve '$3' to single PID" 
return 1 
else 
echo "n 


echo "WARNING: multiple processes matching 
using root process" 
echo "n 
fi 
fi 
fi 
adb forward "tcp$PORT" "tcp$PORT" ## 端 口 映 射 
local USE64BIT="$(is64bit $PID)" 
adb shell gdbserver$USE64BIT $PORT --attach $PID & ##g 


sleep 2 
else 
echo "n 
echo "If you haven't done so already, do this firs 
echo " gdbserver $PORT /system/bin/$EXE" 
echo " or" 
echo " gdbserver $PORT --attach <PID>" 
echo "n 
fi 


OUT_SO_SYMBOLS=$OUT_SO_SYMBOLS$USE64BIT 

OUT_VENDOR_SO_SYMBOLS=$OUT_VENDOR_SO_SYMBOLS$USE64BIT 

echo >|"$OUT_ROOT/gdbclient.cmds" "set solib-absolute-pref 

echo >>"$OUT_ROOT/gdbclient.cmds" "set solib-search-path $ 
SYMBOLS/hw: $0UT_SO_SYMBOLS/ss1/engines:$0UT_SO_SYMBOLS/drm: $0UT_S 

echo >>"$OUT_ROOT/gdbclient.cmds" "source $ANDROID_BUILD_T 


scripts/gdb/dalvik.gdb" 
echo >>"$0UT_ROOT/gdbclient.cmds" "target remote $PORT" 
### 将 GDB 需 要 的 一 些 参数 写 入 脚本 文件 中 





local WHICH_GDB= 

# 64-bit exe found 

if [ "$USE64BIT" != "" ] ; then 
WHICH_GDB=$ANDROID_TOOLCHAIN/$GDB64 

# 32-bit exe / 32-bit platform 

elif [ "$(get_build_var TARGET_2ND_ARCH)" = "" ]; then 
WHICH_GDB=$ANDROID_TOOLCHAIN/$GDB 

# 32-bit exe / 64-bit platform 

else 
WHICH_GDB=$ANDROID_TOOLCHAIN_2ND_ARCH/$GDB 

fi 

###WHICH_GDB 是 GDB 客 户 端 的 绝对 路 径 





gdbwrapper $WHICH_GDB "$0UT_ROOT/gdbclient.cmds" "$0UT_EXE 
else 

echo "Unable to determine build system output dir." 
fi 


综合 上 面 的 分 析 ， 可 以 发 现 gdbclient 函 数 的 实现 是 围绕 两 个 方面 
展开 的 。 为 了 让 大 家 可 以 更 快 地 理解 使 用 gdb 的 整个 过 程 ， 下 面 我 们 以 
调试 surfaceflinger 为 例 来 讲解 。 
(1) gdb server 


这 是 运行 在 Android 设 备 端 ( 量 产 的 设备 中 很 可 能 会 被 移 除 ) 的 一 
个 监听 服务 ， 通 常 路 径 为 /system/bin/gdbserver。 


Gdbserver 有 两 个 使 用 场景 。 


e attach 


如 果 被 调试 的 程序 已 经 在 运行 ， 那 么 我 们 就 需要 “attach” 上 它 。 
在 这 种 情况 下 ， 我 们 最 好 能 先 通 过 ps 命令 来 获取 到 被 测试 对 象 的 P1D。 
比如 attach surfaceflinger， 那 么 先 利 用 adb shell ps 来 找到 
surfaceflinger 的 进程 号 ， 接 着 在 adb she11 中 使 用 如 下 命令 : 


gdbserver --attach :5039 [PID] 


其 中 “:5039” 表 示 gdbserver 将 在 localhost 的 5039 端 口 进行 监 
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。 启动 被 调试 对 象 
上 述 的 attach 用 于 调试 已 经 在 运行 的 被 测 对 象 ， 而 如 果 和 希望 从 头 开 
始 调试 目标 对 象 ， 那 么 可 以 采用 这 个 场景 。 以 surfacef 1inger 为 例 ， 以 
下 命令 可 以 启动 一 个 新 的 surfaceflinger 程 序 来 进行 调试 : 
gdbserver :5039 /system/bin/surfaceflinger 
(2) gdb client 
当 gdbserver 处 于 监听 状态 下 了 时， 我们 就 可 以 启动 gdb 客 户 端 了 。 
首先 需要 切换 到 Android 工 程 的 根 目录 下 ， 然 后 执行 : 
source /build/envsetup.sh 
这 个 步 又 是 为 了 保证 我 们 可 以 正常 使 用 各 种 函数 。 
接 下 来 就 可 以 启动 gdbc1ient 了， 下 面 是 调试 surfaceflinger 所 用 


的 命令 : 
gdbclient surfaceflinger :5039 [PID] 


也 就 是 对 应 前 面 看 到 的 $1, $2, $3 各 变量 。 其 中 “:5039” 和 [PID] 都 
需要 与 gdbserver 中 的 保持 一 致 ， 才 能 保证 正常 连接 。 

一 切 顺 利 的 话 ， 此 时 gdb client 和 gdb server 就 已 经 建立 连接 了 。 
我 们 可 以 通过 gdb 提 供 的 一 系列 丰富 的 命令 进行 各 种 调试 工作 。 下 面 是 
gdb 提 供 的 官方 指导 文档 ， 供 大 家 参考 查询 : 


https://sourceware. org/gdb/down| oad/on| inedocs/gdb/ index. hi 
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. 
操作 系统 基础 


4.1 计算 机 体系 结构 (Computer Architecture) 


硬件 是 软件 的 基石 ， 所 有 的 软件 功能 最 终 都 是 由 硬件 来 实现 的 。 无 
论 是 复杂 的 数学 运算 、 图 像 处 理 ， 还 是 简单 的 文本 显示 、 编 辑 ， 其 软件 
实现 首先 都 是 架构 在 硬件 之 上 ， 然 后 由 此 逐 层 不 断 抽象 堆 共 而 起 的 。 
此 ， 要 彻底 理解 软件 ， 没 有 一 定 的 硬件 基础 是 不 行 的 。 


当然 ， 硬 件 是 一 个 笼统 而 宽泛 的 概念 。 我 们 不 能 强制 要 求 软件 工程 
师 都 能 理解 每 个 电子 元 器 件 的 电气 特性 ， 或 者 先 学 习 电 路 排版 作 图 然后 
编写 程序 。 这 就 像 汽 车 与 驾驶 员 的 关系 : 要 求 驾驶 员 必 须 透 彻 理解 发 动 
机 的 原理 和 内 部 构造 才能 开车 显然 是 行 不 通 的 ， 但 能 了 解 发 动机 工作 机 
理 的 驾驶 员 束 一 定 能 在 开车 的 过 程 中 受 葵 菲 浅 。 


计算 机 体系 结构 作为 一 门 学 科 ， 是 软件 和 硬件 的 抽象 体 ， 也 是 所 有 
开发 者 的 入 门 课 。 它 对 于 我 们 理解 程序 设计 ， 特 别 是 操作 系统 原理 ， 有 
十 分 重要 的 意义 。 

4.1.1 B - 诺 依 曼 结构 

冯 : 诺 依 曼 (Von Neumann) 是 20 世 纪 公 认 的 最 伟大 的 科学 家 之 

一 。 他 的 贡献 领域 相当 广泛 ，Von Neumann architecture 就 是 其 中 之 


冯 : 诺 依 曼 结 构 (Von Neumann Architecture) 又 被 称 为 “ 汉 诺 依 
曼 模 型 ”或 者 “普林斯顿 结构 ”， 起 源 于 Neumann 在 1945 年 发 表 的 一 篇 


关于 EDVAC (Electronic Discrete variable Automatic Computer, FA 
子 离 散 变 量 自动 计算 机 ) 的 论文 。 


就 是 在 这 篇 文章 中 ， 他 提出 了 两 个 对 计算 机 领域 产生 了 深远 影响 的 
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根据 电子 元 件 的 工作 特点 ， 冯 诡 依 曼 提 出 了 使 用 二 进 制 的 设想 。 他 
a 逻辑 线路 ， 后 来 的 事实 也 验证 了 他 的 这 
一 推断 


o 程序 存储 (stored-program) 


除了 二 进 制 ， 他 还 建议 计算 机 能 实现 程序 存储 和 程序 控制 。 具 体 而 
言 ， 程 序 指令 和 数据 都 存放 在 同一 内 存储 器 中 ， 因 此 它们 的 宽度 是 一 样 
oj 
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冯 诺 依 曼 结构 中 包含 了 运算 器 、 控 制 器 、 输 入 输出 设备 等 元 素 ， 其 
关系 如 图 4-1 所 示 。 





全 图 4-1 汉 诺 依 受 结 构 


从 早期 的 EDVAC 到 现代 很 多 最 先进 的 计算 机 ， 都 采用 了 冯 诺 依 曼 结 
构 ， 可 见 其 影响 之 深 。 


4.1.2 哈佛 结构 


值得 一 提 的 是 ， 哈 佛 结构 (Harvard Architecture) 并 不 是 作为 冯 
诺 依 曼 结 构 的 对 立 面 出 现 的 ; 相反 ， 它 们 都 属于 stored-program 类 型 体 
系 。 区 别 就 在 于 前 者 的 指令 与 数据 并 不 保存 在 同一 个 存储 器 中 ， 即 哈佛 
结构 是 对 冯 诺 依 曼 结构 的 改进 与 完善 ， 其 关系 如 图 4-2 所 示 。 





全 图 4-2 哈佛 结构 
这 意味 着 : 


。 指令 与 数据 可 以 有 不 同 的 数据 宽度 ; 
。 执行 速度 更 快 。 


由 于 取 指 令 和 数据 无 法 同步 进行 ， 冯 诺 依 曼 结构 的 执行 速率 并 不 占 
优势 。 而 采用 哈佛 结构 的 计算 机 由 于 指令 和 数据 的 单独 存储 ， 可 以 在 执 
行 操作 的 同时 预 读 下 一 条 指令 ， 所 以 在 一 定 程度 上 可 以 提高 其 吞吐 量 。 


哈佛 结构 的 缺点 在 于 构架 复杂 且 需 要 两 个 存储 器 ， 因 而 通常 会 被 运 
用 在 对 速度 有 特殊 需求 且 成 本 预算 相对 较 高 的 场合 。 目 前 市 面 上 采用 哈 
佛 结构 的 必 片 包括 ARM 公 司 的 ARM? 、ARM11， 以 及 ATMEL 公 司 的 AVR 系 列 
等 。 





不 论 是 何 种 结构 ， 它 们 所 包含 的 基本 元 素 都 是 不 变 的 ， 即 : 


CPU 〈 中 央 处 理 器 ) ; 
内 存储 器 ; 
输入 设备 ; 
输出 设备 。 


其 中 输入 和 输出 设备 一 般 会 统称 为 1/0 设 备 〈 外 存储 器 实际 上 也 归 
于 这 一 类 ) 。 因 而 ， 最 后 可 以 把 计算 机 结构 简化 为 : 


。 中 央 处 理 器 ; 
。 内 存储 器 ; 
° I/O 设 备 。 


无 论 是 哪 款 操作 系统 〈 如 Windows、Linux、Android 等 ) ， 都 是 建 
OO UD E S T E A 
之 7 53 à 


本 书 接 下 来 所 有 章节 的 内 容 都 是 基于 这 一 理解 展开 的 ， 希 望 读者 也 
能 以 体系 结构 为 线索 贯穿 整个 ndroid 系 统 的 学 习 。 


4.2 什么 是 操作 系统 


其 实 有 很 多 概念 我 们 在 平常 的 工作 学 习 中 都 会 经 常 磁 到 ， 如 操作 系 
统 、 体 系 结构 等 。 然 而 真正 需要 对 它们 进行 精确 定义 时 ， 大 部 分 人 却 可 
能 会 有 一 种 无 所 适 从 、 似 懂 非 懂 的 感觉 。 这 说 明 我 们 以 前 对 它们 “只 知 
其 然 ， 而 不 知 其 所 以 然 ” 一 一 仅仅 是 在 有 意 或 者 无 意 的 情况 下 涝 泛 地 了 
解 一 下 ， 并 没有 尝试 从 本 质 上 去 深层 次 地 挖掘 。 


那么 ， 到 底 什 么 是 操作 系统 呢 ? 
发 展 到 今天 ， 市 面 上 可 供用 户 选 择 的 操作 系统 已 经 具备 相当 的 数 
量 ; 而 且 出 于 版 权 及 成 本 等 因素 的 考虑 ， 针 对 不 同 领域 的 操作 系统 
如 “雨后春笋 ” 般 还 在 不 断 涌现 。 
些 操作 系统 可 以 按照 不 同 的 角度 进行 分 类 ， 如 表 4-1 所 示 。 
表 4-1 操作 系统 分 类 


e 果 面 型 操作 系统 
o 服务 如 型 操作 系统 
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支持 的 用 户 数 2 


e 多 用 户 ， 如 Windows、UNIX 


e 实时 操作 系统 ， 如 RTOS、VRTX 
e 分 时 系统 ， 如 UNIX、Mac OS 





指令 长 度 e 32 bit 
e 64 bit 


分 布 性 (distributed) ELS a 


、 TD RE e 开源 系统 ， 如 Linux、Android 
源码 开 太 程度 e 闭 源 系统 ， 如 Windows、MAC OS 


e UNIX-like, 如 Minix、 UNIX. Xinu 


vi i 
UNIX 系 列 e Non-UNIX-like， 如 Windows 


ay e 兼容 POSIX， 如 Linux 
P IX » fy! AJ 9 Po y Bo 
JPOSIXHREE 。 |。 示 兼容 或 不 完全 兼容 POSIX 








面 对 如 此 众多 的 操作 系统 ， 我 们 希望 可 以 提取 出 它们 的 共性 。 


人 们 常 说 “艺术 来 源 于 生活 ， 却 又 高 于 生活 ”。 同 样 的 ， 我 们 也 可 
以 从 工作 、 生 活 中 的 相关 “片断 ”来 理解 操作 系统 。 比 如 : 


。 操作 系统 对 硬件 设备 本 身 是 有 要 求 的 
比如 市 面 上 Android 系 统 面 对 的 多 是 手机 、 平 板 这 些 诅 入 式 领 域 ， 
以 ARM 忆 片 为 主 ; 而 Windows XP, Windows 7/Windows 8 系列 则 基本 应 用 
在 PC 市 场 。 当 然 ， 你 可 能 也 会 从 新 闻 上 看 到 某 些 “牛人 ”将 
Android“ 移 植 ”《〈 而 不 是 直接 使 用 ) 到 了 PC 上 。 
这 些 线索 告诉 我 们 ， 操 作 系 统 必须 针对 “硬件 ”来 研发 。 
o 同一 款 操 作 系 统 可 以 安装 在 不 同型 号 的 机 器 上 
比如 采用 Android 系 统 的 手机 、 平 板 数 量 众多 。 同 样 的 ，Windows 系 


列 操作 系统 也 可 以 安装 在 不同 品牌 配置 的 C 上 。 由 此 我 们 可 以 做 出 推 
断 ， 操 作 系 统 是 针对 某 些 “硬件 架构 ”的 ， 如 ARM、x86 等 。 


。 操作 系统 提供 可 用 的 人 机 交互 界面 


登录 Windows 系 统 后 ， 我 们 可 以 在 个 安装 任何 程序 的 情况 下 浏览 硬 
盘 中 的 文件 ; 原生 态 的 Android 系 统 中 用 户 也 可 以 直接 进行 短信 编辑 、 
通话 等 操作 ， 这 都 得 荔 于 操作 系统 预 装 的 各 种 人 机 交互 程序 。 


。 操 作 系统 支持 用 户 编写 和 安装 程序 


这 是 操作 系统 真正 的 魅力 所 在 ， 也 是 0S 生 态 圈 能 得 以 循环 的 关键 。 
在 Windows 环 境 中 编写 任意 类 型 的 应 用 程序 游戏、 文本 编辑 工具 、 浏 
览 器 等 ) ， 几 乎 都 可 以 调用 Microsoft 提 供 的 各 种 现成 的 AP1 ;在 
Android 中 开发 APK 应 用 ， 同 样 是 基于 SDK 或 者 NDK 来 完成 的 ， 而 不 是 直接 
与 底层 硬件 打交道 。 


基于 上 面 的 几 点 分 析 ， 我 们 可 以 大 致 得 出 操作 系统 的 共同 特征 ， 如 
图 4-3 所 示 。 
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全 图 4-3 操作 系统 的 抽象 特征 
操作 系统 “肩负 ”两 大 重任 。 
。 面向 下 层 


管理 硬件 。 这 里 的 硬件 是 笼统 的 概念 ， 它 包含 了 CPU、 内 存 、 
Flash、 各 种 1/0 设 备 等 系统 中 所 有 硬件 组 成 元 素 。 


。 面向 上 层 


一 方面 ， 操 作 系 统 需要 为 用 户 提供 可 用 的 人 机 交互 额 面 ; 另 一 方 
面 ， 它 还 负责 为 第 三 方程 序 的 研发 提供 便捷 、 可 靠 、 高 效 的 
API (Application Programming Interface) 。 这 样 上 层 应 用 的 设计 实 
现 就 可 以 不 用 直接 面向 硬件 ， 从 而 大 大 缩短 了 应 用 开发 的 时 间 。 


由 此 ， 我 们 可 以 给 操作 系统 下 一 个 简洁 的 定义 。 


计算 机 操作 系统 是 负责 管理 系统 硬件 ， 并 为 上 层 应 用 提供 稳定 编程 
接口 和 人 机 交互 表面 的 软件 集合 


这 一 概念 虽然 浅显 ， 却 是 我 们 在 学 习 操 作 系统 〈 而 不 仅仅 是 
Android) 时 的 指南 针 。 因 为 它 指出 了 操作 系统 最 核心 的 工作 ， 即 硬件 
管理 与 抽象 。 任 何 类 型 的 操作 系统 都 逃 不 出 这 个 范畴 。 


操作 系统 作为 “硬件 大 管家 ”， 任 重 而 道 远 。 特 别 是 随 着 硬件 的 不 
断 发 展 ， 会 有 越 来 越 多 的 “成 员 ” 加 入 这 个 “大 家 庭 ” 中 。 所 以 一 款 成 
功 的 操作 系统 ， 往 往 是 数 以 干 计 的 工程 师 花 费 几 年 、 日 夜 奋战 的 结晶 。 
而 Android 系 统 的 诞生 年 头 还 很 短 ， 何 以 能 风靡 各 大 领域 呢 ? 


其 中 一 个 非常 重要 的 原因 ， 就 是 Android 系 统 是 基于 Linux Kernel 
的 。 


Google 员 工 Patrick Brady， 曾 在 2008 年 的 1X0 大 会 上 做 过 一 篇 名 为 
«Android Anatomy and Physiology》 的 主题 演讲 。 其 中 提 到 过 
Android 采 用 Linux 内 核 的 原因 (Why Linux Kernel) 。 摘 录 如 下 : 


Great memory and process management; 
Permissions-based security model; 


e 

e 

e Proven driver model; 

e Support for shared libraries ; 
e 


It’ s already open source! 


从 中 可 以 看 出 ， 操 作 系统 的 难点 包括 了 进程 和 内 存 管理 、 硬 件 驱 动 
的 支持 等 。 而 这 些 正 是 Linux 的 长 处 所 在 。 更 为 可 贵 的 是 ， 内 核 本 身 也 
是 开源 项 目 一 一 于 是 Android 与 Linux“ 一 拍 即 合 ”， 遂 成 一 方 霸业 。 


虽然 Android 系 统 的 底层 完全 基于 Linux Kernel 来 实现 ， 但 并 不 代 
表 它 可 以 彻底 “撒手 不 管 ”; 相反 ， 对 于 进程 /线程 和 内 存 的 管理 ， 
Android 本 身 也 做 了 不 少 努力 。 接 下 来 的 几 个 小 节 ， 我 们 会 先 向 读者 讲 
人 然后 兼顾 Android 在 这 上 面 所 做 
人 66 = 43 I z 


4.3 进程 间 通 信 的 经 典 实 现 


我 们 知道 ， 操 作 系统 中 的 各 个 进程 通常 运行 于 独立 的 内 存 空间 中 ， 
并 且 有 严格 的 机 制 来 防止 进程 间 的 非法 访问 。 但 是 ， 这 并 不 代表 进程 与 
进程 间 不 允许 互相 通信 ; 相反 ， 进 程 间 通 信和 是 操作 系统 中 一 个 重要 的 概 
念 ， 应 用 非常 广泛 。 举 个 实用 的 例子 ， 我 们 常用 的 Windows 操 作 系统 中 
的 蔓 贴 板 ， 就 可 以 让 用 户 轻 松 地 从 一 个 程序 中 复制 信息 到 另 一 个 富 无 关 
联 的 程序 中 。 


广义 地 讲 ， 进 程 间 通信 (lnter-process communication, IPC) 是 
指 运行 在 不 同 进程 〈 不 论 是 否 在 同一 台 机 器 ) 中 的 若干 线程 间 的 数据 交 
换 ， 具 体 如 图 4-4 所 示 。 


Bhat | ew 


全 图 44 IPC 释 义 
从 这 个 定义 可 以 看 到 : 

。IPC 中 参与 通信 的 进程 既 可 运行 在 同一 人 台 机 器 上 ， 也 允许 它们 存在 
于 各 自 的 设备 环境 中 (RPC) 。 如 果 和 进程 是 跨 机 器 运行 的 ， 则 通常 
由 网 络 连接 在 一 起 ， 这 无 疑 给 进程 间 通 信 的 实现 增加 了 难度 。 后 续 
小 节 有 专门 针对 这 种 情况 的 讨论 ， 如 图 4-5 所 示 。 











进程 进程 2 


他 图 4-5 进程 间 通 信 的 未 知 因素 
° 实现 方式 多 种 多 样 。 原 则 上 ， 任 何 跨 进程 的 数据 交换 都 可 以 称 
为 进程 间 通 信 。 除 了 传统 意义 上 的 消息 传递 、 管 道 等 ， 还 可 以 使 用 
一 些 简单 的 方法 来 实现 对 性 能 要 求 不 高 的 进程 通信 。 比 如 : 
° 文件 共享 


比如 两 个 进程 间 约 定 以 磁盘 上 的 某 个 文件 作为 信息 交互 的 媒介 。 在 
这 种 情况 下 ， 要 特别 注意 不 同 进 程 访问 共享 文件 时 的 同步 问题 。 


。 操作 系统 提供 的 公共 信息 机 制 


比如 Windows 上 的 注册 表 对 于 所 有 进程 来 说 都 是 可 以 访问 的 ， 因 而 
在 特定 情况 下 也 能 作为 进程 间 信 息 交 换 的 平台 。 


虽然 各 操作 系统 所 采用 的 进程 间 通 信 机 制 可 以 说 五 花 八 门 ， 但 以 下 
将 要 讨论 的 几 种 却 因 其 高 效 、 稳 定 等 优点 而 几乎 被 广泛 应 用 于 所 有 操作 


系统 中 。 
4.3.1 共享 内 存 (Shared Memory) 
共享 内 存 是 一 种 常用 的 进程 间 通 信 机 制 。 由 于 两 个 进程 可 以 直接 共 


享 访问 同一 块 内 存 区 域 ， 减 少 了 数据 的 复制 操作 ， 因 而 速度 上 的 优势 比 
较 明 显 。 一 般 情 况 下 ， 实 现 内 存 共 享 的 步骤 如 图 4-6 所 示 。 





全 图 4-6 共享 内 存 机 制 


Step1. 创建 内 存 共享 区 


图 4-6 中 进程 1 首先 通过 操作 系统 提供 的 AP1 从 内 存 中 申请 一 块 共享 
区 域 比如 在 Linux 环 境 中 可 以 通过 shmget 函 数 来 实现 〈 人 参见 后 面 的 
表格 说 明 ) 。 生 成 的 共享 内 存 块 将 与 某 个 特定 的 key〈 即 shmget 的 第 一 
个 参数 ) 进行 绑 定 。 


Step2， 了 映射 内 存 共享 区 


成 功 创建 了 内 存 共享 区 后 ， 我 们 需要 将 它 映射 到 进程 1 的 空间 中 才 
能 进一步 操作 。 在 Linux 环 境 下 ， 这 一 步 可 以 通过 shmat 来 实现 。 


Step3. 访问 内 存 共享 区 
进程 1 已 经 创建 了 内 存 共享 区 ， 那 么 进程 2 如 何 访问 到 它 呢 ? 没 错 ， 


就 是 利用 第 一 步 中 的 key。 具 体 而 言 ， 进 程 2 只 要 通过 shmget， 并 传 入 同 
oe 然后 进程 2 执行 shmat， 将 这 块 内 存 映射 到 它 的 空间 





Step4， 进 程 间 通 信 

共享 内 存 的 各 个 进程 实现 了 内 存 映射 后 ， 便 可 以 利用 该 区 域 进行 信 
息 交 换 。 由 于 内 存 共 享 本 身 并 没有 同步 的 机 制 ， 所 以 参与 通信 的 诸 进 程 
需要 自己 协商 处 理 。 

Step5， 撤 销 内 存 映射 区 


完成 了 进程 间 通 信 后 ， 各 个 进程 都 需要 撤销 之 前 的 映射 操作 。 在 
Linux 中 ， 这 一 步 可 以 通过 shmdt 来 实现 。 


Step6， 删除 内 存 共享 区 


最 后 必须 删除 共享 区 域 ， 以 便 回 收 内 存 。 在 Linux 环 境 中 ， 可 以 通 
shet I AARI. 


表 4-2 详 细 讲 解 了 Linux 中 内 存 共 享 机 制 的 各 函数 实现 。 


表 4-2 AHS AHIMA BAA 




















函数 原型 Sk 3 


两 种 情况 下 系统 会 为 
shmget 创 建 一 块 新 的 
内 存 共享 区 : 

(1) key 值 为 
IPC_PRIVATE 

(2) key 不 为 
IPC_PRIVATE, 但 
shmflg 指 定 了 
IPC_CREAT 标 志 
申请 的 共享 区 的 大 
小 ， 以 字 节 为 单位 。 
但 要 注意 ，Linux 下 分 
配 的 内 存 大 小 都 是 页 
的 整数 倍 
IPC_CREAT: 申请 新 
建 区 域 

IPC_EXCL: 和 
IPC_CREAT 共 同 使 
用 。 如 果 指 定 的 区 域 
己 经 存在 ， 则 返回 错 
误 

mode_flags: 参照 
open 函 数 中 的 mode 参 
数 


Z 


Nn 
a 
g 
ane 
ga 
= — = 
WE 


size N 


key, size_t 
size, int 
shmflg); 


SHM_HUGETLB: 使 
FA “huge pages” 机 制 来 
申请 (Linux 2.6 后 版 
本 有 效 ) 
SHM_NORESERVE: 
此 区 域 不 保留 swap 空 
间 


内 存 共 享 区 域 的 id 
回 值 JOUT ”| 值 ， 用 于 唯一 识别 访 








= 








a | 


是 由 执行 
后 返回 的 


char "| 将 共享 内 存 区 映射 到 
\*shmat( int li<sys/types. 间 定 地 址 。 可 以 为 0， 


shmid , void |<sys/ipc.h> rey, St 
\*shmaddr ,ll<sys/shm.h> ca 目 动 分 配 


OVE, 返回 该 
okie 起 始 地 址 


<sys/shm.h> llshmid 同 shmget 的 返回 值 


命令 ， 可 选 值 如 
Leg STAT: 状态 查 
询 ， 结果 存 入 buf 中 
IPC_SET: 在 权限 允 
许 的 情况 下 ， 将 共享 
内 存 状态 更 新 为 buf 中 
的 数据 
IPC_RMID: 删除 共 
N 

返回 值 jour oe 否则 表示 

KS 











4.3.2 管道 (Pipe) 


道 也 是 操作 系统 中 常见 的 一 种 进程 间 通 信 方 式 ， 它 适用 于 所 有 
POS | <， 以 及 Windows 系 列 产 品 。 


Pipe 这 个 词 很 形象 地 朱 述 了 通信 双方 的 行为 ， 即 进程 A 与 进程 B。 
分 立 管 道 的 两 边 ， 进 行 数据 的 传输 通信 。 


° 管道 是 单 向 的 ， 意 味 着 一 个 进程 中 如 果 既 要 “ 读 ” 也 
要 “ 写 ” 的 话 ， 那 么 就 得 建立 两 根 管 道 。 这 点 很 像 水 管 的 特性 ， 通 
常 水 流 只 做 正 向 或 反 向 行进 。 


° 一 根 管道 同时 具有 “ 读 取 ” 端 (read end) 7 “SA” ih 
(write end) 。 比如 进程 A 从 wr ite end 写 入 数据 ， 那 么 进程 8 就 可 
以 从 read end 读 取 到 数据 。 


管道 有 容量 限制 。 即 当 pipe 满 时 ， 写 操作 (write) 将 阻塞 ; 
反之 ， 读 操作 (read) 也 会 阻塞 。2. 6. 11 版 本 以 前 的 Linux 内 核 ， 
管道 的 容量 和 page size 是 一 致 的 ， 之 后 版 本 中 改 为 65536 字 节 。 


在 Li nux 环 境 中 使 用 pi pe 的 流程 和 一 般 的 文件 操作 类 似 ， 下 面 给 大 
家 提供 一 个 范例 : 


A/*Linux 中 的 管道 示例 */ 
#include <sys/wait.h> 
#include <stdio.h> 
#include <stdlib.h> 
#include <unistd.h> 
#include <string.h> 


> 





int main(int argc, char *argv[]) 


int pipe_fd[2];// 管 道 的 read end 和 write end 
pid_t child_pid;// 子 进程 

char ”pipe_buf;// 管 道 数 据 

memset(pipe_fd, ©, sizeof(int)*2);//#uatk 








Pees 


if (pipe(pipe_fd) == -1) {/* 通 过 pipe 接 口 打 开 管道 ，pipe_fd 
表 读 、 写 端 */ 
/* 出 错 处 理 */ 








return -1; 


} 

child_pid= fork(); //fork 一 个 子 进程 
if (child pid == -1) { 

/* 出 错 处 理 */ 





return -1; 


if (child_pid == 0) {  /* 子 进程 中 的 操作 */ 
close(pipe_fd[1]); /* 关 闭 写 端 ， 因 为 子 进 程 负责 读 取 */ 
while (read(pipe_fd[0], &pipe_buf, 1) > 0)/* 从 管道 中 

write(STDOUT_FILENO，&pipe_buf，1);/* 读 取 成 功 ,第 

close(pipe_fd[0]); /* 关 闭 读 取 端 */ 
return 0; /* 成 功 */ 

} else { /* 父 进程 中 的 操作 */ 
close(pipe_fd[0]); /* 和 子 进程 相对 应 ， 关 闭 读 取 端 */ 
write(pipe_fd[1]，"H"，1);/* 写 入 一 个 字符 “H”*/ 
close(pipe_fd[1]); /* 关 闭 写 入 端 */ 
wait(NULL); /* 等 待 子 进程 */ 
return 0;/* 成 功 */ 








这 个 例子 的 结果 融 是 父 进程 向 管道 写 入 一 个 “H” 了 字符， 然后 子 进 
程 读 取 后 输出 。 从 中 可 以 学 到 : 


(1) Linux#et# 7 pipeHRORHA-TPEIS. HARA: 
int pipe(int pipefd[2], int flags); 

其 中 第 一 个 参数 代表 了 成 功 打开 后 的 管道 的 两 端 。 

(2) 根据 fork 的 特性 ， 当 chi 1d_pid 等 于 0 时 ， 代 表 的 是 子 进程 ; 


否则 ， 是 父 进 程 。 所 以 ， 最 后 的 “if”，“else” 部 分 分 别 对 管道 执行 
了 读 和 与 操作 。 


(3) 示例 中 因为 父子 进程 间 的 特殊 关系 ， 使 得 两 者 共享 管道 文件 
描述 符 《“ 即 变量 pipe_fd) 成 为 可 能 。 读 者 肯定 会 想到 ， 如 果 两 个 进程 
没有 任何 关系 怎么 办 了 呢 ? 


对 于 这 个 范例 ， 答 案 就 是 “无 法 实现 ”。 


这 也 就 是 后 来 “Named Pipe” 〈 也 被 称 为 FIF0) 得 以 发 展 的 原因 。 
作为 Pipe 的 扩展 ， 它 改变 了 前 者 的 “匿名 ”方式 。 另 外 ，Named Pipe 的 
生命 周期 也 不 再 是 随 进程 结束 而 完结 ， 其 “system-persistent” 特 性 
要 求 我 们 在 不 使 用 它 时 一 定 要 主动 删除 。 


关于 Named Pipe 的 更 多 信息 ， 建 议 读者 作为 练习 自行 查阅 相关 资 
料 。 


4.3.3 UNIX Domain Socket 


不 少 读者 因为 学 习 TCP/1P 协 议 才 接 触 到 Socket， 它 在 网 络 〈 比 如 
Internet) 通信 领域 获得 了 广泛 的 应 用 ， 被 称 为 Network Socket. XT 
运行 在 同一 机 器 内 的 进程 间 通 信 ，Network Socket 也 完全 能 够 胜任 ， 只 
不 过 执行 效率 未 必 让 人 满意 。 


UNIX Domain Socket (UDS) 是 专门 针对 单机 内 的 进程 间 通 信 提 出 
来 的 ， 有 时 也 被 称 为 1PC Socket。 两 者 虽然 在 使 用 方法 上 类 似 ， 但 内 部 
实现 原理 却 有 着 很 大 区 别 。 大 家 所 熟识 的 Network Socket 是 以 TCP/1P 协 
议 栈 为 基础 的 ， 需 要 分 包 、 重 组 等 一 系列 操作 。 而 UDS 因 为 是 本 机 内 
的 “安全 可 靠 操 作 ”， 实 现 机 制 上 并 不 依赖 于 这 些 协议 。 


Android 中 使 用 最 多 的 一 种 1PC 机 制 是 Binder， 其 次 就 是 UDS。 相 关 
资料 显示 ，2. 2 版 本 以 前 的 Android 系 统 ， 曾 使 用 Binder 作 为 整个 GUI 架 
构 中 的 进程 间 通 信 基 础 。 后 来 因 某 些 原因 不 得 不 弃 之 而 用 UDS， 可 见 后 
者 还 是 有 一 定 优势 的 。 

使 用 UDS 进 行进 程 间 通信 的 典型 流程 如 图 4-7 所 示 。 

如 果 读 者 做 过 1nternet Socket 的 开发 ， 一 定 会 觉得 图 4-7 非 常熟 
悉 。UDS 的 基本 流程 与 传统 Socket 一 致 ， 只 是 在 参数 上 有 所 区 分 。 下 面 
向 读者 提供 一 个 UDS 的 范例 ， 功 能 如 下 : 

e 服务 器 端 监听 1PC 请 求 ; 
° 客户 端 发 起 1PC 申 请 ; 


° 双方 成 功 建立 起 1PC 连 接 ; 


客户 端 向 服务 器 端 发 送 数 据 ， 证 明 1PC 通 信和 是 有 效 的 。 





Server 


全 图 4-7 UNIX Domain Socket 的 通信 流程 


源码 分 为 Client 和 Server 两 部 分 : 


/*Server 端 代码 */ 

#include <stdio.h> 

#include <stdlib.h> 

#include <errno.h> 

#include <string.h> 

#include <sys/socket.h> // 引 用 的 是 socket 头 文件 
#include <sys/un.h> 

#include <sys/types.h> 


#define UDS_PATH "uds_test" 
int main(void) 


4 


int socket_srv=-1; 

int socket_client=-1; 

int t=-1; 

int len=0; 

struct sockaddr_un addr_srv, addr_client; /注意 地 址 格式 与 Nety 
char str[100],;// 用 于 接收 通信 数据 
memset(str，0,，sizeof(char)*100);// 初 始 化 


if ((socket_srv = socket(AF_UNIX, SOCK_STREAM, 0)) <0) {/* 首 : 
系统 支持 AF_INET,， AF_UNIX, AF_N 
UDS 对 应 于 AF_UNIX， 而 不 是 AF_INE” 

return -1; 


addr_srv.sun_family = AF_UNIX; 

strcpy(addr_srv.sun_path, UDS_PATH); // 设 置 path name 

if(bind(socket_srv, (struct sockaddr *)&addr_srv,offsetof(st 
+ strlen(addr_srv.sun_path))<0) {/* 将 这 个 socket 与 地 址 进行 

return -1; 


if (listen(socket_srv, 10) <0) {/* 开 始 监听 客户 端的 连接 请 求 。 第 二 个 : 








return -1; 


while(1) { 


int nRecv; 
SZ = sizeof(addr_client); 
if ((socket_client = accept(socket_srv, (struct sockaddr 
== -1) {/* 要 特别 注意 ，accept 返 回 的 socke 
同一 个 。 另 外 addr_client 是 客户 











return -1; 


} 

if (nRecv =recv(socket_client, str, 100, 0)<0) {/* 接 收 数 
close(socket_client); 
break; 


} 

if (send(socket_client, str, nRecv, 0) < 0) {/* 将 接收 到 的 
close(socket_client); 
break; 


} 
close(socket_client );// 传 输 完毕 ， 关 闭 连 接 





} 


return 0; 


客户 端 代码 如 下 : 


#include <stdio.h> 

#include <stdlib.h> 

#include <errno.h> 

#include <string.h> 

#include <sys/socket.h> // 也 是 引用 socket 头 文件 
#include <sys/un.h> 

#include <sys/types.h> 


#define UDS PATH "uds test" 


/* ZP mR BRE IRS Be ER, BATT AS BIRR * / 
int main(void) 


{ 


int socket_client =-1; 

int data_len =0; 

int addr_size =0; 

struct sockaddr_un addr_srv; 

char str[100]; 

memset(str, 0, sizeof(char)*100); 
strcpy(str, "This is a test for UDS"); 


if ((socket_client = socket(AF_UNIX, SOCK_STREAM, 0)) <0) { 
return -1; 


} 


addr_srv.sun_family = AF_UNIX; 

strcpy(addr_srv.sun_path, UDS_PATH); 

addr_size = offsetof(struct sockaddr_un, sun_path) + strlen(a 

if (connect(socket_client, (struct sockaddr *)&addr_srv, addr. 
处 于 监听 状态 ，CLient 则 通关 


return -1; 


} 


if (send(socket_client, str, strlen(str), 0) <0) {/* 发 送 数 据 给 月 
close(socket_client); 
return -1; 


J 
if ((data_len=recv(socket_client, str, 100, 0)) > ©) {/* 接 收服 
str[data_len] = '\0'; 
printf("echo from server: %s", str); 
} else { 
close(socket_client); 
return -1; 


close(socket_client); 
return 0; 


可 以 看 到 ， 建 立 一 个 Unix Domain Socket MER ZAM, 
特别 是 服务 器 端 进程 。 考 虑 到 这 一 点 ，UDS 特 别提 供 了 一 个 便捷 的 函 
数 ， 即 socketpair 0 一 一 它 可 以 大 大 简化 通信 双方 的 工作 ， 因 而 在 实际 
项 目 中 有 不 少 应 用 。 


后 续 章 节 在 对 Android 系 统 的 分 析 过 程 中 ， 还 会 碰 到 基于 UDS 的 进程 
间 通 = 5 希望 本 小 节 讲 解 的 知识 和 范例 可 以 帮助 大 家 打下 一 定 的 基础 。 


4.3.4 RPC (Remote Procedure Calls) 


从 名 称 上 可 以 看 出 ， RPC 涉 及 的 通信 双 万 递 弟 运行 于 两 台 不 同 的 机 
器 中 。 在 RPC 机 制 中 ， 开 发 人 员 不 需要 特别 关心 具体 的 中 间 传 输 过 程 是 
如 何 实现 的 ， 这 种 “透明 性 ”可 以 较 大 程度 地 降低 研发 难度 ， 如 图 4-8 
所 示 。 





人 图 4-8 ”RPC 通信 图 释 
一 般 而 言 ， 一 个 完整 的 RPC 通 信和 需要 以 下 几 个 步 又 : 


o 客户 端 进 程 调用 Stub 接 口 ; 

。 Stub 根 据 操 作 系 统 的 要 求 进 行 打包 ， 并 执行 相应 的 系统 调用 ; 

。 由 内 核 来 完成 与 服务 器 端的 具体 交互 ， 它 负责 将 客户 端的 数据 包 发 
给 服务 器 端的 内 核 ; 

。 服务 器 端 Stub 解 包 并 调用 与 数据 包 匹 配 的 进程 ; 

。 进程 执 行 操作 ; 

o 服务 器 以 上 述 步骤 的 逆向 过 程 将 结果 返回 给 客户 端 。 


4.4 同步 机 制 的 经 典 实 现 


既然 操作 系统 支持 多 个 进程 〈 多 线程 ) 的 并 发 执行 ， 那 么 它们 之 间 
难免 会 出 现 相互 制约 的 情况 。 比 如 两 个 进程 《线程 ) 需要 共享 唯一 的 硬 
件 设 备 ， 或 者 同一 块 内 存 区 域 ; 又 或 者 像 生产 流水 线 一 样 ， 进 程 〈 线 
程 ) 的 工作 依赖 于 另 一 方 对 共享 资源 的 执行 结果 一 一 换 名 话说， 它们 存 
在 协同 关系 。 同 步 机制 不 但 是 操作 系统 的 实现 重点 ， 在 应 用 程序 的 设计 
中 也 具有 举足轻重 的 作用 ， 因 而 有 必要 先 对 它们 进行 集中 分 析 。 


从 定义 上 来 讲 ， 如 果 多 个 (包括 两 个 ) 进程 间 存 在 时 序 关 系 ， 需 要 
协同 工作 以 完成 一 项 任务 ， 则 称 为 同步 ;， 如果 它们 并 不 满足 协同 的 条 
件 ， 而 只 是 因为 共享 具有 排他 性 的 资源 时 所 产生 的 关系 ， 则 称 为 互 斥 。 
当然 ， 这 样 的 理论 定义 既 枯 燥 又 难 懂 ， 大 家 可 以 结合 具体 的 例子 来 理 


解 。 


BF (Mutual Exclusion) 问题 是 由 入 兰 专 家 Edsger W. Di jkstra 
于 1965 年 在 一 篇 名 为 《Solution of a problem in concurrent 
programming control》 的 Paper 中 首次 提出 的 。 经 过 几 十 年 的 发 展 ， 互 
斥 机 制 已 经 得 到 了 广泛 的 应 用 ， 并 出 现 了 很 多 有 效 的 解决 方案 一 一 这 其 
中 既 有 硬件 的 实现 ， 也 有 软件 的 实现 ， 本 书 介绍 的 重点 是 后 者 。 


接 下 来 我 们 将 分 若干 小 节 详 细 讲 解 操作 系统 中 常见 的 几 种 同步 机 
制 ， 然 后 在 此 基础 上 分 析 Android 系 统 具 体 是 如 何 实现 同步 机 制 的 。 


4.4.1 信号 量 (Semaphore) 


信和 号 量 与 PV 原 语 操作 是 由 Dijkstra 发 明 的 ， 也 是 使 用 最 为 广泛 的 互 
斥 方法 之 一 。 它 包括 以 下 几 个 元 素 : 


e Semaphore S (È 5) ; 


° Operation P (RA = Eproberen, BAtest) ， 有 时 也 表 
Await () ; 


° Operation V (RAH Everhogen, BAincrement) ， 有 时 
也 表达 为 signal 0 。 


Semaphore S 用 于 指示 共享 资源 的 可 用 数量 。P 原 语 可 以 减 小 S 计 
数 ，V 则 增加 它 的 计数 。 由 此 可 知 当 某 个 进程 想 进 入 共享 区 时 ， 首 先 要 
执行 P 操 作 ; 同 理 ， 想 退出 共享 区 时 执行 V 操 作 。PV 原 语 都 属于 原子 操作 
(Atomic Operations) ， 意 味 着 它们 的 执行 过 程 是 不 允许 被 中 断 的 。 


描述 PV 原 语 如 图 4-9 所 示 。 





全 图 4-9 PV 操作 图 


P 操 作 的 执行 过 程 : 
° aS SSA; 


° 如 果 此 时 S$ 仍 然 宇 0， 说 明 共 享 资 源 此 时 是 允许 访问 的 ， 因 而 调 
用 者 将 直接 返回 ， 然 后 开始 操作 共享 资源 ; 


° 否则 的 话 就 要 等 待 别人 主动 释放 资源 ， 这 种 情况 下 调用 者 会 被 
加 入 等 待 队 列 中 ， 直 到 后 续 被 唤醒 ; 


° 当 某 人 释放 了 共享 资源 后 ， 处 于 等 待 队列 中 的 相关 AFA 


体 情 况 ) 对 象 会 被 唤醒 ， 此 时 该 对 象 就 具备 了 资源 的 访问 权 。 
V 操 作 的 执行 过 程 : 
° 信号 量 S 自 增 1; 


° 此 时 如 果 S>0， 说 明 当 前 没有 希望 访问 资源 的 等 待 者 ， 所 以 直 
接 人 返回; 


° 否则 V 操 作 要 唤醒 等 待 队列 中 的 相关 对 象 ， 对 应 P 操 作 中 的 最 后 


tke 


Yo 

由 此 可 见 ，Dijkstra 的 信号 量 机 制 只 需要 有 限 的 几 个 元 素 和 简单 的 
操作 就 能 解决 同步 问题 ， 这 也 是 它 能 产生 深远 影响 的 一 大 原因 。 
4.4.2 Mutex 


Mutex 是 Mutual Exclusion 的 缩写 ， 其 释义 为 互 斥 体 。 那 么 ， 它 和 
Semaphore 有 什么 区 别 和 联系 呢 ? 


根据 计算 机 领域 的 普遍 观点 ， 如 果 资 源 允 许多 个 对 象 同时 访问 ， 称 
为 Counting Semaphores; 而 对 于 只 允许 取 值 0 或 1《〈 即 
locked/unlocked) 的 Semaphore， 则 叫 作 Binary Semaphore。 后 者 可 以 
认为 与 本 小 节 的 Mutex 具 有 相同 的 性 质 。 换 句 话 说 ，Mutex 通 常 是 对 某 一 
排他 资源 的 共享 控 ” 制 一 一 要 么 这 个 资源 被 占用 (locked) ， 要 么 就 
是 可 以 访问 的 《unlocked) 。 在 很 多 操作 系统 中 ，Binary Semaphore 和 
Mutex 没 有 本 质 差 异 ， 前 者 是 特定 的 Semaphore 机 制 ， 而 后 者 相 较 于 
Semaphore 在 实现 上 则 更 为 简单 。 


4.4.3 GE (Monitor) 


管 程 是 由 C. A. R. Hoare 和 Per Brinch Hansen 提 出 来 的 ， 并 在 
Hansen’ s Concurrent Pascal Language 中 得 到 实现 。 它 实际 上 是 对 
Semaphore 机 制 的 延伸 和 改善 ， 是 一 种 控制 更 为 简单 的 同步 手段 。 


根据 前 面 的 分 析 ， 我 们 知道 Semaphore 机 制 要 求 用 户 成 对 配套 地 使 
用 P 和 V 操 作 原 语 。 对 于 简单 的 应 用 场合 ， 这 不 容易 引发 问题 。 而 一 旦 涉 
及 庞大 且 复 杂 的 系统 ， 就 难免 让 人 产生 “不 识 庐山 真面目 ， 只 缘 身 在 此 


山中 ”的 感觉 。 这 就 好 比 C/C++ 语 言 中 的 new/delete 操 作 ， 假 如 只 是 简 
短 的 几 句 代码， 通常 不 会 产生 内 存 泄露 的 问题 。 可 如 果 是 写 一 个 操作 系 
统 呢 ?其 中 的 工作 量 大 得 惊人 ， 而 且 一 定 会 是 由 很 多 人 协作 完成 的 。 在 
这 种 情况 下 ， 如 果 没 有 很 好 的 机 制 来 约束 内 存 的 分 配 和 释放 ， 那 么 产生 
内 存 泄露 、 野 指针 等 问题 的 可 能 性 就 很 大 了 。 


采用 Semaphore 机 制 的 程序 易 读 性 相对 较 差 ， 对 于 信号 量 的 管理 也 
分 散在 各 个 参与 对 象 中 ， 因 而 有 可 能 由 此 引发 一 系列 问题 ， 如 和 死 锁 、 进 
为 了 使 资源 的 互 斥 访问 更 利于 维护 ， 科 学 家 们 提出 了 管 程 的 
HERA 0 下 : 


‘tz (Monitor) 是 可 以 被 多 个 进程 /线程 安全 访问 的 对 象 
(ob ject) 或 模块 (module) 。 


管 程 中 的 方法 都 是 受 mutual exclusion 保 护 的 ， 意 味 着 在 同一 时 刻 
只 允许 有 一 个 访问 者 使 用 它们 。 另 外 ， 管 程 还 具备 如 下 属性 : 


上 享 ， 
很 多 流行 的 编程 语言 中 都 实现 了 管 程 机 制 ， 如 Delphi 、Java、 
Python、Ruby 、C# 等 。 


4.4.4 Linux Futex 


Futex (Fast Userspace muTEXes) 是 由 Hubertus Franke 等 人 发 明 
的 一 种 同步 机 制 ， 首次 出 现在 Linux 2.5. 7 版 本 ， 并 在 2. 6. x 中 成 为 内 核 
主 基线 的 一 部 分 。 它 的 核心 优势 已 经 体现 在 其 名 称 中 了 ， 即 “Fast”。 
Futex 的 “ 快 ” 主要 体现 于 它 在 应 用 程序 空间 中 就 可 以 应 对 大 多 数 的 同 
步 场景 (只 有 当 需 要 仲裁 时 才 会 进入 内 核 空间 ) ， 这 样 一 来 节省 了 不 少 
系统 调用 和 上 下 文 切换 的 时 间 。 


Futex 在 Android 中 的 一 个 重要 应 用 场景 是 ART 虚 拟 机 。 如 果 Android 
版 本 中 开启 了 ART_USE_FUTEXES 宏 ， 那 么 ART 虚 拟 中 的 同步 机 制 就 会 以 
Futex 为 基石 来 实现 。 下 面 所 示 的 就 是 ART 中 使 用 相当 频繁 的 互 斥 机 制 |: 


/*art/runtime/base/mutex.cc*/ 


void Mutex::ExclusiveLock(Thread* self) 4.. 
if (!recursive_|| !IsExclusiveHeld(self)) { 
#if ART_USE_FUTEXES // 通 过 Futex 来 实现 互 斥 加 锁 
bool done = false; 
do { 
int32_t cur_state = state_.LoadRelaxed(); 
if (LIKELY(cur_state == 0)) { 
done = state_.CompareExchangeWeakAcquire(0 /* cur_state * 
} else { 
ScopedContentionRecorder scr(this, SafeGetTid(self), GetE 
num_contenders_++; 
if (futex(state_.Address(), FUTEX_WAIT, 1, nullptr, nullp 
if ((errno != EAGAIN) && (errno != EINTR)) { 
PLOG(FATAL) << "futex wait failed for " << name_; 
} 
} 
num_contenders_--; 


} 

} while (!done); 

DCHECK_EQ(state_.LoadRelaxed(), 1); 
#else // 不 启用 Futex 的 情况 下 ， 通 过 传统 的 pthread 来 实现 

CHECK_MUTEX_CALL(pthread_mutex_lock, (&mutex_)); 
#endif 

DCHECK_EQ(exclusive_owner_, QU); 

exclusive_owner_= SafeGetTid(self); 

RegisterAsLocked(self); 

} 


recursion_count_++; 





上 述 的 Mutex 加 锁 操作 可 以 分 为 两 部 分 ， 其 一 是 开启 了 
ART_USE_FUTEXES 的 情况 ， 此 时 通 过 Futex 来 实现 ;其 二 则 是 使 用 传统 的 
pthread AP1 来 完成 相同 的 功能 。 





其 中 state 是 一 个 Atomiclnteger 变 量 ， 而 Atomiclnteger 的 定义 如 
下 : 


typedef Atomic<int32_t> AtomicInteger; 
即 原子 类 型 的 int32。 


Mutex 加 锁 的 基本 远 辑 是 : 如 果 可 以 获取 到 锁 ， 则 直接 返回 ; 否则 
就 进入 挂 起 状态 。 第 二 种 情 况 下 是 调用 futex 函 ; 数 来 完成 的 ， 后 者 由 


bionic 提 供 ， 它 会 在 内 部 使 用 到 SYS_futex 这 个 系统 调用 。 
浮 数 futex 共 有 6 个 参数 ， 其 原型 如 下 所 示 : 


static inline int futex(volatile int *uaddr, int op, int val, con 
volatile int *uaddr2, int val3) 





第 一 个 参数 uaddr 指 向 的 是 futex word 即 一 个 4 字 节 的 
interger， 在 我 们 这 个 场景 中 具体 对 应 的 是 state _。 


第 二 个 参数 op 代表 operation， 即 需要 执行 的 操作 ， 目 前 只 支持 两 
种 ， 即 FUTEX_WAIT 和 FUTEX_WAKE 。 


第 三 个 参数 val 的 含义 根据 op 的 不 同 而 有 所 差异 。 


后 面 几 个 参数 只 有 在 某 些 特殊 情况 下 才 需 要 ， 在 我 们 这 个 场景 中 可 
以 直接 略 过 。 


如 果 调 用 futex 时 提供 的 操作 指令 是 FUTEX_WAIT， 通 常 意味 着 futex 
word 保 持 val 值 (acquired) 可 能 需要 等 待 较 长 时 间 。 可 以 看 到 ， 我 们 
利用 原子 操作 在 用 户 态 获取 到 了 futex word, JAVA futexey ey 
这 两 个 操作 之 间 有 一 个 明显 的 时 间 差 。 换 句 话说 ， 当 我 们 调用 futex 时 
情况 有 可 能 已 经 变化 了 。 这 也 是 需要 在 futex 的 第 一 个 参数 传 入 futex 
word 的 原因 之 一 ， 即 内 核 可 以 据 此 自行 判断 当前 的 最 新 状态 。 


对 于 不 存在 竞争 的 情况 下 ， 采 用 futex 机 制 在 用 户 态 就 可 以 完成 锁 
的 获取 ， 而 不 需要 通过 系统 调用 进入 内 核 态 ， 从 而 提高 了 效率 。 





4.4.5 同步 范例 


理解 了 以 上 几 种 同步 机 制 的 原理 后 ， 我 们 再 来 分 析 一 个 范例 ， 即 经 
典 的 生产 者 与 消费 者 问题 。Android 系 统 源码 中 有 多 个 地 方 都 应 用 了 这 
个 经 典 模型 ， 如 音频 子 系 统 里 AudioTrack 和 AudioF1inger 间 的 数据 交 
es 


相信 读者 对 此 问题 “The producer-consumer problem” , EFR 
为 “The bounded-buffer problem” ) 并 不 卫生 。 摘 述 如 下 : 


两 个 进程 共享 一 块 大 小 为 N 的 缓冲 区 一 一 其 中 一 个 进程 负责 往 里 填 


充 数据 (生产 者 ) ， 而 另 一 个 进程 则 负责 往 里 读 取 数 据 〈 消 费 者 ) 。 问 
题 的 核心 有 两 点 : 


。 当 缓冲 区 满 时 ， 禁 止 生 产 者 继续 添加 数据 ， 直 到 消费 者 读 取 了 部 分 
数据 后 ; 
o 当 缓 冲 区 空 时 ， 消 费 者 应 等 待 对 方 继续 生产 后 再 执行 操作 。 


具体 如 图 4-10 所 示 。 


producer consumer 





butter 


A 4-10 The producer-consumer problem 


i 如 果 使 用 信号 量 来 解决 这 个 问题 ， 需 要 用 到 3 个 Semaphore。 功 能 分 
别 如 下 : 


e S_emptyCount: 用 于 生产 者 获取 可 用 的 缓冲 区 空间 大 小 ， 初 始 值 为 
No 

e S fillCount: 用 于 消费 者 获取 可 用 的 数据 大 小 ， 初 始 值 为 0。 

e S mutex: 用 于 操作 缓冲 区 ， 初 始 值 为 1。 
对 于 生产 者 来 说 ， 执 行 步骤 如 下 : 


° 循环 开始 ; 


° Produce_item; 


° P (S_emptyCount) ; 
° P (S_mutex) ; 

e Put_item_to buffer; 
° V (S_mutex) ; 


° V (S_fillCount) ; 
° 继续 循环 。 

对 于 消费 者 来 说 ， 执 行 步骤 如 下 : 
° 循环 开始 ; 


° P (S_fillCount) ; 


° P (S_mutex) ; 

e Read_item from buffer; 
° V (S_mutex) ; 

e V (S_emptyCount) ; 

° Consume; 


° 继续 循环 。 


一 开始 ，S_emptyCount 的 值 为 N，S_fil1count 的 值 为 0， 所 以 消费 
AEP (S_fillCount) 后 处 于 等 待 状态 。 而 生产 者 首先 生产 一 件 产品 ， 
然后 获取 S_emptyCount 因为 它 为 N， 处 于 可 访问 状态 ， 所 以 产品 可 
以 被 放 入 buffer 中 。 之 后 生产 者 通过 V (S_fillCount) 来 增加 可 用 产品 
的 计数 ， 并 唤醒 正 于 这 个 Semaphore 上 等 待 的 消费 者 。 于 是 消费 者 开始 





读 取 数据 ， 并 利用 V (S_emptyCount) 来 表明 buffer 又 空 出 了 一 个 位 
Bo 

生产 者 和 消费 者 就 是 如 此 循环 反复 来 完成 整个 工作 ， 这 样 我 们 就 通 
过 Semaphore 机 制 保证 了 生产 者 和 消费 者 的 有 序 执行 。 


4.5 Android 中 的 同步 机 制 


学 习 了 操作 系统 中 同步 机 制 的 基础 原理 后 ， 我 们 再 来 看 Android 具 
体 是 如 何 做 的 ， 又 有 哪些 改进 。 值 得 一 提 的 是 ， 不 论 什 么 样 的 操作 系 
统 ， 其 技术 本 质 都 类 似 ， 而 更 多 的 是 把 这 些 核心 的 理论 应 用 到 符合 自己 
需求 的 场景 中 。 目 前 Android 封 装 的 同步 类 包括 : 


e Mutex 
L(+ frameworks/native/include/utils/Mutex. h 


Android 中 的 Mutex 只 是 对 pthread 提 供 的 AP1 的 简单 再 封装 ， 所 以 水 
oe ene eet a 这 样 做 也 方便 了 调用 者 的 操 


另外 ，WMutex 中 还 包含 一 个 AutoLock 的 藤 套 类 ， 它 是 利用 变量 生命 
周期 特点 而 设计 的 一 个 辅助 类 。 


e Condition 
Uw frameworks/native/include/utils/Condition.h 


Condition 是 “条 件 变量 ”在 Android 系 统 中 的 实现 类 ， 后 面 的 分 析 
中 我 们 将 看 到 它 是 依赖 Mutex 来 完成 的 。 


e Barrier 


头 文件 是 
frameworks/native/services/surfacef | inger/Barrier.h 
Barr ier 是 同时 基于 Mutex 和 Condition 实 现 的 一 个 模型 。 本 书 在 


AudioFlinger 和 SurfaceFlinger 这 两 个 章节 都 会 碰 到 它 的 使 用 场景 ， 并 
建议 大 家 以 理论 结合 实例 来 理解 ， 这 样 可 能 会 事 半 功 





Mutex 


4.5.1 进程 间 同 步 


我 们 先 来 看 Mutex 类 中 的 一 个 enum 定 义 。 如 下 所 示 : 


class Mutex { 
public: 
enum { 
PRIVATE = 0,// 只 限 同 一 进程 间 的 同步 
SHARED = 1// 支 持 跨 进程 间 的 同步 
}; 


这 说 明 Mutex 既 可 以 处 理 进 程 内 同步 的 情况 ， 也 能 完美 解决 进程 间 
同步 的 问题 。 


如 果 在 Mutex 构 造 时 指定 它 的 type 是 SHARED 的 话 ， 说 明 它 是 适用 于 
跨 进程 共享 的 。 此 时 Mutex 将 进一步 调用 
pthread mutexattr_setpshared 接 口 来 为 这 个 互 斥 量 设 置 
PTHREAD PROCESS SHARED 属 性 。Android 中 使 用 SHARED 类 型 Mutex 的 地 方 
有 不 少 ， 如 本 书 音 频 系统 章节 中 AudioTrack 与 AudioF 1 inger 就 驻 留 在 两 
个 不 同 的 进程 中 ， 所 以 它们 的 Mutex 变 量 就 是 以 如 下 方式 构造 的 : 


frameworks/av/media/libmedia/AudioTrack.cpp*/ 
audio_track_cblk_t::audio_track_cblk_t(): 

lock(Mutex::SHARED), cv(Condition: :SHARED), user(0), server(0), .. 
{... 


} 


与 Semaphore 不 同 的 是 ，Mutex 只 有 两 种 状态 ， 即 0 和 1。 所 以 这 个 类 
只 提供 了 3 个 重要 的 接口 函数 : 


status_t lock(); // 获 取 资 源 锁 
void unlock(); // 释 放 资 源 锁 
status_t tryLock(); /* 不 论 成 功 与 否 都 会 及 时 返回 ， 而 不 是 等 待 */ 


当 调用 者 希望 访问 临 表 资源 时 ， 它 必须 先 通 过 lock 0 来 获得 资源 
锁 。 如 果 此 时 资源 可 用 ， 这 个 函数 将 马上 返回 ; 否则 ， 会 进入 阻塞 等 
待 ， 直 到 有 人 释放 了 资源 锁 并 唤醒 它 。 释 放 资 源 锁 调用 的 是 unlock 0 ， 
同时 正在 等 待 使 用 这 个 锁 的 其 他 对 象 就 会 被 唤醒 ， 然 后 继续 执行 它 的 任 
务 。 男 外 ，Mutex 还 特别 提供 了 一 个 tryLock 0 来 满足 程序 的 多 样 化 需 
求 。 这 个 函数 仅 会 “试探 性 ”地 查询 资源 锁 是 否 可 用 一 一 如 果 答 案 是 肯 
定 的 束 获 取 它 ， 然 后 成 功 返 回 〈 返 回 值 为 0) ， 从 这 一 点 看 它 和 1ock () 
的 表现 是 一 样 的 ; 但 在 资源 暂 不 可 用 的 情况 下 ， 它 并 不 会 进入 等 待 ， 而 
同样 是 立即 返回 ， 只 是 返回 值 不 为 0。 


这 三 个 函数 的 实现 很 简单 ， 具 体 源码 如 下 : 


inline status_t Mutex::lock() { 
return -pthread_mutex_lock(&mMutex) ;// 变 量 mMutex 的 类 型 是 pthread 


inline void Mutex::unlock() { 
pthread_mutex_unlock(&mMutex) ; 


inline status_t Mutex::tryLock() { 
return -pthread_mutex_trylock(&mMutex) ; 
} 


所 以 我 们 说 ，Mutex 实 际 上 只 是 基于 pthread 接 口 的 再 封装 。 
4.5.2 条件 判断 一 一 Condition 


Condition 的 字面 意思 是 “条 件 ”。 换 名 话说， 它 的 核心 思想 是 判 
断 “ 条 件 是 否 已 经 满足 ”一 一 满足 的 话 马上 返回 ， 继 续 执行 未 完成 的 动 
作 ; 否则 就 进入 休眠 等 待 ， 直 到 条 件 满足 时 有 人 唤醒 它 。 


可 能 有 读者 会 问 ， 这 种 情况 用 Mutex 能 实现 吗 ? 理论 上 讲 ， 的 确 是 
可 以 的 。 举 一 个 例子 ， 假 设 两 个 线程 A 和 B 共 享 一 个 全 局 变量 vari ， 且 它 
们 的 行为 如 下 。 

Thread A: 不 断 去 修改 vari， 每 次 改变 后 的 值 未 知 。 

Thread B: 当 var i 为 0 时 ， 它 需要 做 某 些 动作 。 

显而易见 ，A 和 B 都 想 访 问 var i 这 个 共享 资源 ， 属 于 Mutex 的 问题 领 
域 。 但 需要 商 榨 的 细节 是 : 线程 A 的 “企图 ”仅仅 是 获得 var i 的 访问 
权 ; 而 线程 8B 则 “ 酬 翁 之 意 不 在 酒 ”， 其 真正 等 待 的 条 件 是 “var i 等 于 
0” o 

那么 如 果 用 Mutex 去 完成 的 话 ， 线 程 B 就 只 能 通过 不 断 地 读 取 var i 来 
判断 条 件 是 否 满足 ， 有 点 类 似 于 下 面 的 伪 代 码 : 
while(1)// 死 循环 ， 直 到 条 件 满足 时 退出 
{ 


acquire_mutex_lock(vari);// 获 取 vari 的 Mutex 锁 
if(9 == vari) // 条 件 满足 
{ 


release_mutex_lock(vari);// 释 放 锁 
break; 


else 


release_mutex_lock(vari);// 释 放 锁 
sleep();// 休 眠 一 段 时 间 


对 于 线程 B 而 言 ， 什 么 时 候 达 到 条 件 (var i==0) 是 未 知 的 ， 这 点 和 
其 他 只 是 使 用 var i 的 线程 (比如 线程 A〉 有 很 大 不 同 ， 因 而 采用 轮 询 的 
方式 显然 极 大 地 浪费 了 CPU 时 间 。 


再 举 一 个 生活 中 的 例子 ， 以 加 深 大 家 的 理解 。 比 如 有 一 个 公共 出 
所 ， 人 于 现在 把 希望 使 用 这 一 资源 的 人 分 为 两 
X: 其 一 当然 是 正常 使 用 厕所 的 用 户 〈 类 似 于 线程 A) ; 其 二 就 是 更 换 
出 二 的 工作 人 中 (类 似 于 线程 8) 。 如 果 我 们 使 用 Mutex 来 解决 这 一 资源 
同步 共享 问题 ， 会 发 生 什 么 4 青 况 呢 ? 


首先 对 于 用 户 来 说 并 不 会 产生 太 大 的 影响 ， 他 们 仍然 正常 排队 、 使 
FA, VAR. 
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需要 和 其 他 人 一 样 正常 排队 。 只 有 等 排 到 他 时 ， 他 才能 进去 看 下 耐 纸 是 
否 用 完 一 一 用 完 就 更 换 ， 否则 就 什么 也 不 做 直接 退出 ， 然后 继续 排队 等 
待 ， 如 此 循环 往复 。 假 设 排 一 次 队 需 要 5 分 钟 ， 而 工作 人 员 进 去 后 需要 
更 换 厕 纸 的 概率 只 有 1/10。 那 么 可 想 而 知 ， 和 
低 的 ， 因 为 他 的 时 间 都 浪费 在 等 待 “而 纸 为 空 ” 上 


所 以 ， 我 们 需要 寻找 另 一 种 模型 来 解决 这 一 特殊 的 同步 场景 。 

可 行 的 方法 之 一 是 工作 人 员 不 需要 排队 ， 而 是 由 其 他 人 通知 他 厕所 
缺 纸 的 事件 。 这 样 做 既 减 少 了 排队 人 员 的 数量 ， 提 高 了 资源 的 使 用 率 ， 
同时 也 改善 了 工作 人 员 的 办 事 效 率 ， 可 谓 一 举 两 得 。 

Condition 就 是 按照 这 样 的 思路 提出 来 的 : 


class Condition { 
public: 
enum { // 和 Mutex 一 样 ， 它 支持 跨 进 程 共 享 


PRIVATE = 0, 
SHARED = 1 
J}; 
status_t wait(Mutex& mutex); // 在 某 个 条 件 上 等 待 
status_t waitRelative(Mutex& mutex, nsecs_t reltime); /* 也 是 在 
时 退出 功能 */ 
void signal(); // 条 件 满足 时 通知 相应 等 待 者 
void broadcast(); // 条 件 满足 时 通知 所 有 等 待 者 
private: 
#if defined(HAVE_PTHREADS ) 
pthread_cond_t mCond; 
#else 
void* mState; 
#endif 


了 


从 Condition 提 供 的 几 个 接口 函数 中 ， 我 们 有 如 下 疑问 。 


。 了 既然 wait0 是 在 等 待 基 个 “条 件 ”满足 ， 那 么 如 何 去 描 述 这 个 “条 
件 ” 呢 ? 


在 整个 Condition 类 的 源码 实现 中 ， 我 们 都 看 不 到 与 条 件 相 关 的 变 
量 或 者 操作 。 这 是 因为 ，Condition 实 际 上 是 一 个 “半成品 ”， 它 并 不 
理会 具体 的 “条 件 ” 是 什么 样 的 一 一 理由 很 简单 ， 在 不 同 的 情况 下 ， 用 
户 所 设 定 的 “条 件 ” 形 式 都 可 能 不 同 。Condition 想 要 提供 一 种 “通用 
的 解决 方案 ”， 而 不 是 针对 某 些 具 体 的 “条 件 样 式 ” 去 设计 。 比 如 “条 
件 ” 既 可 能 是 “ 某 变量 A 为 True”， 也 可 以 是 “变量 A 达到 值 100”， 或 
者 “变量 A 等 于 B” 等 。 这 些 是 Condition 所 无 法 预料 的 ， 因 此 它 能 做 的 
co “ 黑 盒 ”及 “ 黑 盒 ”的 操作 手法 ， 而 不 必 去 理会 盒子 里 是 

Zs o 


e 为 什么 需要 mutex? 


相信 大 家 都 注意 到 了 ，wait 和 waitRe1ative 接 口 都 带 有 一 个 Mutex& 
mutex 变 量 ， 这 是 很 多 人 不 解 的 地 方 一 一 既然 都 有 Condition 这 一 互 斥 方 
法 了 ， 为 什么 还 要 把 Mutex 替 扯 进 来 呢 ? 


由 于 Condition 本 身 的 不 完整 性 ， 如 果 直 接 从 理论 角度 分 析 估 计 比 
较 生 硬 ， 所 以 我 们 将 结合 下 一 小 节 的 Barr ier 来 为 大 家 解答 上 述 两 个 问 


题 。 





4.5.3 “栅栏 、 障 碍 ” 


Condition 表 示 “ 条 件 ”， 而 Barrier 表 示 “ 栅 栏 、 障 碍 ”。 后 者 是 
对 前 者 的 一 个 应 用 ， 即 Barrier 是 填充 了 “具体 条 件 ” 的 Condition， 这 
给 我 们 理解 Condition 提 供 了 一 个 很 好 的 范例 : 


顺便 提 一 下 ，Barrier 类 是 专门 为 SurfaceFlinger 而 设计 的 ， 并 不 
da pus ition 一 样 作为 常用 的 Utility 提供 给 整个 Android 系 统 
使 用 。 不 过 “影响 我 们 对 它 的 分 析 : 


/*frameworks/native/services/surfaceflinger/Barrier .h*/ 
class Barrier 





Barrier 


{ 
public: 
inline Barrier() : state(CLOSED) { } 
inline ~Barrier() { } 
void open() { 
Mutex: :Autolock _1(1lock); 
state = OPENED; 
cv.broadcast(); 


void close() { 
Mutex::Autolock _1(1lock); 
state = CLOSED; 


void wait() const { 
Mutex::Autolock _1(lock); 
while (state == CLOSED) { 
cv.wait(lock); 


} 
3} 
private: 
enum { OPENED, CLOSED }; 
mutable Mutex lock; 
mutable Condition CV; 
volatile int state; 


}; 


Barr ier 总 共 提 供 了 3 个 接口 函数 ， Bllwait0 ， open () 和 close () 。 
既然 说 它 是 Condition 的 实例 ， 那 么 “条 件 ” 是 什么 呢 ? 稍微 观察 一 下 
就 会 发 现 ， 是 其 中 的 变量 state==0PENED; 另 一 个 状态 当然 就 是 CLOSED 
这 有 点 类 似 于 汽车 栅栏 的 开启 和 关闭 。 在 汽车 通过 前 ， 它 必 须要 先 
确认 栅栏 是 开启 的 ， 于 是 调用 wait () 。 如 果 条 件 不 满足 ， 那 么 汽车 就 只 





能 停 下 来 等 待 。 这 个 洱 数 首先 获取 一 个 Mutex 锁 ， 然 后 才 是 调用 
a ee 为 什么 呢 ? 我 们 知道 Mutex 是 用 于 保证 共享 资源 的 互 
斥 使 用 的 ， 这 说 明 wait () 中 接 下 来 的 操作 涉及 了 对 某 一 互 斥 资源 的 访 
问 ， 即 state 这 个 变量 。 可 以 想象 一 下 ， 假 如 没有 一 把 对 state 访 问 的 
锁 ， 那 么 当 wait 与 open/close 同 时 去 操作 它 时 ， 有 没有 可 能 引起 问题 
We? 

假设 有 如 下 步骤 。 

Step 1. 线程 A 通过 wait () 取得 state 值 ， 发 现 是 CLOSED。 

Step 2. 线程 B 通 过 open () 取得 state 值 ， 将 其 改 为 OPENED。 


Step 3. open () 唤醒 正在 等 待 的 线程 。 因 为 此 时 线程 A 还 没有 进入 
睡眠 ， PURERAA 需要 唤醒 。 


Step4， 另 外 ， 线 程 A 因 为 state==CLOSED， 所 以 进入 等 待 ， 但 这 时 
候 的 栅栏 实际 上 已 经 开启 了 ， 这 将 导致 wait0 调用 者 所 在 线程 得 不 到 唤 
WE 

这 样 就 很 清楚 了 ， 对 于 state 的 访问 必须 有 一 个 互 斥 锁 的 保护 。 

接 下 来 ， 我 们 分 析 Condition: :wait () 的 实现 : 


inline status_t Condition: :wait(Mutex& mutex) { 
return -pthread_cond_wait(&mCond, &mutex.mMutex); 


和 Mutex 一 样 ， 直 接 调 用 了 pthread 提 供 的 AP1 方 法 。 
pthread_cond_wait 的 逻辑 语义 如 下 。 

Step1. 释放 锁 mutex。 

Step2. 进入 休眠 等 待 。 

Step3.， 了 唤醒 后 再 获取 mutex 锁 。 

也 就 是 经 历 了 先 释 放 ， 再 获取 锁 的 过 程 ， 为 什么 这 么 设计 呢 ? 


由 于 wait 即 将 进入 休眠 等待 ， 假 如 此 时 它 不 先 释放 Mutex 锁 ， 那 么 
open () /close () 又 如 何 能 访问 “条 件 变 量 ”state 呢 ? 这 无 疑 会 使 程序 
陷入 互相 等 待 的 死 锁 状态 。 所 以 它 需要 先行 释放 锁 ， 再 进入 睡眠 。 之 后 
ae (0 操作 完毕 会 释放 锁 ， 也 就 让 wait 0 有 机 会 再 次 获得 这 一 
Mutex $i. 


同时 我 们 注意 到 ， 判 断 条 件 是 否 满足 的 语句 是 一 个 whi le 循环 : 


while (state == CLOSED) {... 


这 样 做 也 是 合理 的 。 假 设 我 们 在 close 0 的 末尾 也 加 一 个 
broadcast () 或 者 signal () ， 那 么 wait 0 同样 会 被 唤醒 ， 但 是 条 件 满足 
TB? 显然 没有 。 所 以 wait () 只 能 再 次 进入 等 待 ， 直 到 条 件 真 正 为 
OPENED 为 止 。 


值得 注意 的 是 ，wait ( 函数 的 结尾 会 自动 释放 Mutex 锁 〈 因 为 .1 是 
一 个 Autolock 变 量 ， 详 见 下 一 小 节 ) 。 也 就 是 说 wait () 返回 时 ， 程 序 已 
经 不 再 拥有 对 共享 资源 的 锁 了 。 笔 者 认为 ， 如 果 接 下 来 的 代码 还 有 对 共 
享 资源 的 操作 ， 那 么 就 应 该 再 次 获取 锁 ， 否 则 还 是 会 出 错 。 举 个 前 面 的 
例子 ， 当 wait () 返回 时 ， 我 们 的 确 可 以 认为 此 时 汽车 栅栏 是 已 经 打开 
的 。 但 是 因为 释放 了 锁 ， 很 有 可 能 在 汽车 发 动 的 过 程 中 ， 又 有 人 把 它 关 
闭 了 。 这 导致 的 后 果 就 是 汽车 会 直接 撞 上 栅栏 而 引起 事故 。Barrier 通 
常 被 用 于 对 某 线程 是 否 初始 化 完成 进行 判断 ， 这 种 场景 具有 不 可 逆 性 
一 一 既然 已 经 初始 化 了 ， 那 么 后 期 就 不 可 能 再 出 现 “ 没 有 初始 化 ”的 情 
况 ， 因 而 即便 wait () 返回 后 没有 获取 锁 也 被 认为 是 安全 的 。 


条 件 变量 Condition 是 和 互 斥 锁 Mutex 同 样 重要 的 一 种 资源 保护 手 
段 ， 大 家 务必 要 理解 清楚 。 当 然 ， 我 们 更 多 的 是 从 使 用 的 角度 去 学 习 ， 
至 于 pthread_cond_wait 内 部 是 如 何 实现 的 ， 因 为 涉及 具体 的 硬件 平 
台 ， 可 以 暂时 不 去 深究 。 
4.5.4 加 解锁 的 自动 化 操作 


在 Mutex 类 的 内 部 还 有 一 个 Autolock 藤 套 类 ， 从 字面 上 看 它 应 该 是 
为 了 实现 加 、 解 锁 的 自动 化 操作 ， 那 么 如 何 实现 呢 ? 


其 实 很 简单 ， 看 看 这 个 类 的 构造 和 析 构 函数 大 家 就 明月 了 : 





Autolock 


class Autolock { 

public: 
inline Autolock(Mutex& mutex) : mLock(mutex) { mLock.1loc 
inline Autolock(Mutex* mutex) : mLock(*mutex) { mLock.1loc 
inline ~Autolock() { mLock.unlock(); } 

private: 
Mutex& mLock; 

3; 


也 就 是 说 ， 当 Autolock 构 造 时 ， 会 主动 调用 内 部 成 员 变 量 mLock 的 
lock () 方 法 来 获取 一 个 锁 。 而 析 构 时 的 情况 正好 相反 ， 调 用 它 的 
unlock () 方法 释放 锁 。 这 样 假如 一 个 Autolock 对 象 是 局 部 变量 的 话 ， 那 
么 它 在 生命 周期 结束 时 就 会 自动 把 资源 锁 解 。 除 了 前 一 小 节 中 遇 到 的 _| 
变量 外 ， 我 们 再 举 个 AudioTrack 中 的 例子 。 如 下 所 示 : 
/*frameworks/av/media/libmedia/AudioTrack.cpp*/ 


uint32_t audio_track_cblk_t::framesAvailable() 


{ 





Mutex: :Autolock _1(lock); 
return framesAvailable_1(); 


变量 1 是 一 个 Autolock 对 象 ， 它 在 构造 时 会 主动 去 获取 
audio track_cblk _t 中 的 lock 锁 。 而 当 framesAvai lable 0 结束 时 ，_| 
的 生命 周期 也 随 之 完结 ， 于 是 它 在 析 构 函数 中 又 会 unlock 这 个 锁 。 这 虽 
然 是 一 个 不 起 眼 的 小 技巧 ， 但 在 某 些 情况 下 可 以 有 效 防 止 开发 人 员 因 没 
有 配套 使 用 lock/unlock 而 酿 成 “悲剧 ”。 


45.5 R5 


Android Art 虚 拟 机 中 用 到 互 斥 和 锁 操 作 的 地 方 非常 多 ， 为 此 它 实 
现 了 一 整套 自己 的 mutex 机 制 ， 大 家 可 以 参考 art/runtime/base 目 录 并 
结合 本 书 的 虚拟 机 章节 了 解 详 情 。 


本 小 节 我 们 重点 分 析 一 下 Art 虚 拟 机 中 的 一 种 特殊 mutex， 即 
ReaderWr iterMutex。 从 字面 意思 上 来 理解 ， 它 代表 的 是 “ 读 写 锁 ”。 
与 普通 的 mutex 相 比 ， 它 主要 提供 了 如 下 一 些 差 异 接口 : 


void ExclusiveLock(Thread* self) ACQUIRE(); 

void ExclusiveUnlock(Thread* self) RELEASE(); 

bool ExclusiveLockwWithTimeout(Thread* self, int64_t ms, int32_t n 
EXCLUSIVE_TRYLOCK_FUNCTION(true); 





ReaderWr i terMutex 


void SharedLock(Thread* self) ACQUIRE_SHARED() ALWAYS_INLINE; 
void SharedUnlock(Thread* self) RELEASE_SHARED() ALWAYS_INLINE; 


其 中 Exclusive 和 Shared 分 别 代表 Write 和 Read 权 限 ， 这 也 很 好 地 诠 
释 了 这 种 锁 的 特点 是 允许 有 多 个 对 象 共 享 Read 锁 ， 但 同时 却 只 能 有 唯一 
一 个 对 象 拥 有 Wr ite 锁 。ReaderWr iterMutex 可 以 有 以 下 3 种 状态 。 


e Free: 还 没有 被 任何 对 象 所 持 有 的 情况 。 
e Exclusive: 当前 被 唯一 一 个 对 象 持 有 的 情况 。 
。 Shared: 被 多 个 对 象 持 有 的 情况 。 


各 个 状态 间 所 人 允许 的 操作 及 操作 结果 如 表 4-3 所 示 。 





表 4-3 ReaderWr iterMutex 状 态 表 





ReaderWr iterMutex 的 内 部 实现 并 不 复杂 ， 它 的 基础 仍然 是 普通 的 
mutex， 并 且 根 据 系 统 是 否 局 用 Futex 在 实现 上 会 有 所 差异 。 大 家 可 以 人参 
考 /art/runtime/base/mutex. cc 来 了 解 详 情 。 


46 操作 系统 内 存 管理 基础 
不 论 什么 类 型 的 操作 系统 ， 内 存 管 理 都 是 绝对 的 重点 和 难点 。 


简单 来 说 ， 内 存 管 理 (Memory Management) 由 在 为 系统 中 的 所 有 
Task 提 供 稳定 可 靠 的 内 存 分 配 、 释 放 与 保护 机 制 。 可 能 有 读者 会 问 ， 我 
们 学 习 Android 系 统 还 需要 了 解 Linux Kernel 的 内 存 管理 机 制 吗 ? 


答案 是 肯定 的 。 不 论 是 Android 中 的 音频 系统 、6GU1 系 统 ， 还 是 
Binder 的 实现 机 理 等 ， 都 与 内 存 管理 是 息息相关 的 。 甚 至 可 以 说 ， 任 何 
操作 系统 的 运行 都 只 是 在 “ 玩 内 存 游戏 ”。 当 然 ， 没 有 内 核 基 础 的 读者 
也 不 要 因此 而 觉得 “前 途 漫漫 无 归 路 ”， 事 实 上 “内 存 游戏 ”再 精彩 ， 
其 底层 原理 都 基本 不 变 。 因 此 ， 需 要 重点 理解 以 下 几 个 核心 : 


° 虚拟 内 存 ; 
e 内 存 分 配 与 回收 ; 
° 内 存 保 护 。 


接 下 来 我 们 将 通过 若干 小 节 来 和 读者 一 起 “补缺 补漏 ”， 从 而 为 后 
续 的 Android 学 习 扫 清道 路 。 


4.6.1 虚拟 内 存 (Virtual Memory) 


计算 机 出 现 的 早期 物理 内 存 普遍 很 小 ， 不 过 因为 当时 程序 的 体积 也 
不 大 ， 所 以 不 会 有 什么 问题 。 然 而 随 着 软件 的 发 展 ， 动 辆 以 6B 为 单位 的 
程序 比比 皆 是 。 在 这 种 情况 下 ， 如 何 保证 这 些 软 件 能 在 大 多 数 机 器 上 运 
{THE ? 


一 种 最 直接 的 方式 就 是 加 大 物理 内 存 ， 使 得 机 器 能 一 次 性 读 入 任何 
程序 。 这 样 的 “理想 是 很 丰满 的 ”， 但 “现实 却 很 骨 感 ”。 且 不 论 硬 件 
的 升级 意味 着 成 本 的 增加 ， 即 便 把 内 存 加 大 到 166 以 上 ， 问 题 还 是 没有 
得 到 根本 的 解决 一 一 程序 体积 仍然 可 能 超过 它 。 换 句 话说 ， 这 样 的 设备 
是 不 可 靠 的 ， 因 为 我 们 不 清楚 它 什么 时 候 会 遭遇 宕 机 。 


虚拟 内 存 的 出 现 为 大 体积 程序 的 运行 提供 了 可 能 。 它 的 基本 思想 


=| 
KE o 


。 将 外 存储 器 的 部 分 空间 作为 内 存 的 扩展 ， 如 从 硬盘 划分 出 4GB 
大 小 。 


° 当 内 存 资源 不 足 时 ， 系 统 将 按照 一 定 算法 自动 挑选 优先 级 低 的 
数据 块 ， 并 把 它们 存储 到 硬盘 中 。 


。 后续 如 果 需 要 用 到 硬盘 中 的 这 些 数据 块 ， 系 统 将 产生 “ 缺 
页 ”指令 ， 然 后 把 它们 交换 回 内 存 中 。 


。 这 些 操作 都 是 由 操作 系统 内 核 自 动 完成 的 ， 对 上 层 应 用 “ 完 
透明 ” : 


理解 虚拟 内 存 机 制 ， 首 先 要 学 习 3 种 不 同 的 地 址 空间 。 
1. 逻辑 地 址 (Logical Address) 


它 也 称 为 “相对 地 址 ”， 是 程序 编译 后 所 产生 的 地 址 。 逻 辑 地 址 由 
两 部 分 组 成 : 


e Segment Selector ( 段 选择 子 ) 


用 于 朱 述 逻辑 地 址 所 处 的 段 ，16bit。 格 式 如 下 : 





BET 


其 中 的 TI 指 “Table Indicator” , RPL#§ “Request Privilege 
Level”。 从 TI 的 名 称 可 以 猜测 到 ， 它 和 某 种 “Table” 有 关 。 具 体 而 
言 ， 就 是 GDT (Global Descriptor Table) 及 LDT (Local Descriptor 
Table) 。 它 们 都 用 于 记录 各 种 段 描 述 符 (Segment Descriptors) , m 
表 本 身 的 存储 地 址 则 由 GDTR 和 LDTR 两 个 CPU 寄 存 器 来 保存 。GDT 的 有 效 范 
围 是 全 局 的 ， 同 时 系统 也 允许 各 进程 创建 自己 的 本 地 表 (LDT〉 以 增加 


额外 的 段 。 

这 样 就 很 清楚 了 ， 上 段 选 择 子 中 的 1INDEX 就 是 GDTR/ALDTR 中 的 “ 序 
号 ”一 一 具体 是 哪个 表 ， 则 由 “Table lndicator” 来 区 分 : 0 表示 
GDT，1 表 示 LDT。 

e Offset 
用 于 描述 段 内 的 偏 移 值 ，32b it。 
CPU 提供 了 专用 的 寄存 器 来 承载 段 选择 子 ， 如 表 4-4 所 示 。 


表 4-4 段 寄存 器 


i fe te A 
Code Segment Register， 代 码 段 寄存 器 


D Data Segment Register， 全 局 与 静态 数据 段 寄 存 器 





Stack Segment Register, JEP EC AT TF as 
Extra Segment Register， 附 加 数据 段 寄存 器 


通用 段 寄 存 器 





对 于 开局 段 页 式 内 存 管理 的 机 器 而 言 ， 罗 辑 地 址 需要 经 过 两 次 变换 
才能 得 到 最 终 的 物理 地 址 ， 如 图 4-11 所 示 。 
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全 图 4-11 地址 空间 的 转换 过 程 简 图 


早期 的 机 器 并 没有 任何 虚拟 地 址 的 概念 ， 被 称 为 “ 实 模式 ”内 存 管 
理 。 而 后 期 发 展 出 来 的 设备 即使 提供 了 虚拟 地 址 的 硬件 实现 ， 但 为 了 兼 
容 早期 的 操作 系统 ， 机 器 在 开机 时 仍然 会 处 于 “ 实 模式 ”一 一 直到 系统 
程序 做 好 准备 工作 后 才 切 换 到 相应 的 “保护 模式 ”。 


需要 注意 的 是 ， 并 不 是 所 有 系统 都 同时 支持 段 页 式 的 内 存 管理 。 有 
些 操 作 系统 只 提供 了 页 式 的 管理 机 制 ， 而 Linux 内 核 虽然 理论 上 是 段 页 
式 的 ， 但 也 只 是 实现 了 分 页 机 制 〈 分 段 机制 只 用 到 其 中 一 部 分 功能 
关于 这 部 分 内 容 ， 读 者 可 以 参考 相关 资料 来 了 解 。 
2. 线性 地 址 (Linear Address) 

线性 地 址 是 逻辑 地 址 经 过 分 段 机 制 转换 后 形成 的 。 其 基本 思想 是 。 


° 根据 段 选 择 子 中 的 TI 字段 ， 得 知 段 描述 符 存 储 在 6DT 或 者 LDT 
中 。 


í 通过 GDTR/LDTR 获 得 GDT/LDT 的 存储 地 址 。 


。 ”根据 段 选 择 子 中 的 INDEX 字 段 ， 到 GDT/LDT 中 查找 到 对 应 的 段 摘 


述 符 
。 根据 段 朱 述 符 获得 此 段 的 基地 址 。 
° 由 基地 址 + 段 内 偏 移 值得 到 线性 地 址 。 
逻辑 地 址 到 线性 地 址 的 转换 如 图 4-12 所 示 。 
3. 物理 地 址 (Physical Address) 
物理 地 址 空间 很 好 理解 ， 它 是 指 机 器 真实 的 物理 内 存 所 能 表示 的 地 
址 空间 范围 。 比 如 对 于 只 有 64KB 内 存 的 系统 来 说 ， 其 物理 地 址 范围 是 


0x0000~0xFFFF。 任 何 操作 系统 ， 最 终 都 需要 通过 真实 的 物理 地 址 来 访 
问 内 存 。 





全 图 4-12 ”逻辑 地 址 到 线性 地 址 的 转换 简 图 





线性 地 址 物理 地 址 


全 图 4-13 线性 地 址 到 物理 地 址 的 转换 实例 


当 系 统 开 启 了 分 页 机 制 后 ， 线 性 地 址 也 需要 经 过 一 次 转换 才 是 物理 
地 址 。 为 了 便于 大 家 理解 这 个 转换 过 程 ， 举 个 实例 如 图 4-13 所 示 。 


在 这 个 例子 中 ， 有 两 个 概念 需要 先 说 明 一 下 。 


。 页 


\ 同 的 是 ， 分 页 机 制 的 操作 对 象 是 固定 大 小 的 内 存 块 ， 
称 为 “页 ”。 一 般 情 况 下 ， 页 的 大 小 为 4KB。 


。 页 杠 


与 页 的 概念 相对 应 ， 页 框 是 对 物理 内 存 的 最 小 操作 单位 。 显 然 ， 页 
和 页 框 的 大 小 必须 完全 一 致 ， 即 4KB。 


如 图 4-13 所 示 ， 线 性 地 址 中 的 1、3、4、6 页 分 别 对 应 物理 内 存 中 的 
1、2、3、4 页 框 。 这 就 意味 着 ， 如 果 一 个 线性 地 址 刚好 落 在 页 3 的 范围 
中 (线性 地 址 是 由 页 基 址 和 偏 移 地 址 组 成 的 ， 即 线性 地 址 = 页 基 址 + 页 内 
偏 移 量 ) ， 那 么 它 对 应 的 物理 内 存 地 址 在 页 框 2 中 〈 即 物理 地 址 = 页 框 2 
HIHN ARE) 。 


当前 与 物理 内 存 没 有 映射 关系 的 页 (比如 2、5、7 页 ) ， 说 明 它 们 
并 不 在 内 存 中 ， 因 此 访问 时 会 产生 一 个 缺 页 中 断 。 此 时 操作 系统 会 自动 
介入 处 理 ， 利 用 一 定 的 算法 将 当前 不 常用 的 页 调 出 内 存 ， 从 而 为 “缺失 
页 ” 膳 出 位 置 ， 然 后 将 “缺失 页 ”从 外 存储 器 重新 取 回 ， 最 后 返回 中 断 
点 继续 操作 。 由 于 这 些 操作 对 访问 者 都 是 透明 的 ， 它 们 并 不 会 感觉 
到 “ 缺 页 ”事件 ， 从 而 保证 了 上 层 程 序 的 稳定 运行 。 


当然 ， 实 际 的 内 核 分 页 机 制 比 这 个 例子 要 复杂 得 多 ， 不 过 我 们 暂时 
只 要 掌握 基础 原理 即 可 。 有 兴趣 的 读者 可 以 在 此 基础 上 深入 分 析 Kernel 
的 具体 实现 。 


本 小 节 主 要 通过 讲解 3 种 类 型 的 地 址 (逻辑 地 址 、 线 性 地 址 、 物 理 
地 址 ) ， 为 读者 完整 地 还 原 了 操作 系统 虚拟 地 址 的 概念 与 转换 原理 。 相 
信 大 家 会 在 后 续 Android 各 子 系统 的 学 习 中 受益 菲 浅 。 


4.6.2 AFAIRE (Memory Protection) 


最 初 的 操作 系统 中 ， 并 没有 严格 意义 的 内 存 保护 机 制 。 对 于 内 存 的 
访问 约束 完全 基于 程序 编写 人 员 的 自觉 性 一 一 这 种 做 法 显然 是 不 可 靠 
的 。 一 方面 ， 没 有 任何 软件 程序 是 十 全 十 美的 ， 它 们 或 多 或 少 都 存在 
Bug， 如 内 存 越秀 ; 另 一 方面 ， 那 些 “ 不 怀 好 意 ” 的 程序 可 以 很 容易 地 
攻击 和 破坏 系统 中 的 数据 。 


人 们 逐渐 认识 到 内 存 保护 的 必要 性 ， 并 将 其 列 入 内 存 管 理 的 重点 。 
当然 ， 保 护 方法 也 越 来 越 多 、 越 来 越 全 面 ， 如 上 一 小 节 所 提 到 的 分 段 和 
页 式 管理 。 因 为 每 个 进程 的 逻辑 地 址 和 物理 地 址 都 不 是 直接 对 应 的 ， 任 
何 进 程 都 没有 办 法 访问 到 它 管辖 范围 外 的 内 存 空间 一 一 即便 刻意 产生 的 
内 存 越 弄 与 非法 访问 ， 操 作 系统 也 会 马上 阻止 并 强行 关闭 程序 ， 从 而 有 
力 地 保障 应 用 程序 和 操作 系统 的 安全 和 稳定 


4.6.3 内 存 分 配 与 回收 


对 应 用 程序 而 言 ， 内 存 的 分 配 和 回收 是 它们 最 关心 的 。 换 句 话说 ， 
这 是 | 
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全 图 4-14 内 存 管理 与 上 层 程序 

既然 是 操作 系统 的 重要 组 成 部 分 ， 内 存 管理 模块 也 同样 遵循 操作 系 
统 的 定义 ， 即 为 “上 层 建筑 ”控制 和 使 用 硬件 〈 内 存储 器 ) 提供 有 效 的 
接口 方法 。Linux Kernel 所 面 对 的 核心 问题 包括 但 不 限于 : 
1. 保证 硬件 无 关 性 

每 个 硬件 平台 的 物理 内 存 型 号 、 大 小 甚至 架构 比如 不 同 的 体系 结 
构 ) 等 都 可 能 是 不 一 样 的 。 这 种 差异 绝 不 能 体现 在 应 用 程序 上 ， 操 作 系 
统 应 尽 可 能 实现 向 上 的 “透明 ”。 
2. 动态 分 配 内 存 和 回收 

需要 考虑 的 问题 很 多 ， 如 如 何 为 内 存 划 分 不 同 的 使 用 区 域 ; 分 配 的 
粒度 问题 ， 即 分 配 的 最 小 单位 ; 如 何 管理 和 区 别 已 经 使 用 和 未 使 用 的 内 
存 ; 如 何 回 收 和 再 利用 等 。 
3. 内 存 碎片 

和 磁盘 管理 一 样 ， 内 存 也 一 样 会 有 和合 片 的 问题 。 


举 个 简单 的 例子 ， 如 图 4-15 所 示 。 


pF Ud Ty 


(a) 6 PAE IR 


到 国 醒 丁丁 加 


(b) 分 配 使 用 了 5 个 内 存 块 以 后 


| 


(0) 释放 了 1 个 内 存 块 以 后 


A415 内 存 碎片 实例 
在 这 个 例子 中 ， 假 设 初始 状态 有 6 块 未 使 用 的 内 存单 元 。 随 着 程序 
不 断 地 申请 使 用 ， 前 面 5 块 已 经 成 功 分 配 。 此 时 若菜 程序 释放 了 第 2 块 单 
元 ， 那 么 最 后 将 会 有 两 块 不 连续 的 未 使 用 内 存单 元 存在 一 一 碎片 形成 。 
另外 ， 内 核 既 要 保证 内 存 分 配 的 合理 性 ， 也 要 考虑 整体 机 制 的 高 效 
性 。 内 存 的 分 配 和 回收 是 非常 频繁 的 ， 如 果 没 有 办 法 实现 高 效 管理 ， 将 
会 极 大 地 影响 系统 的 稳定 性 。 


在 Android 系 统 中 ， 内 存 的 分 配 与 回收 分 为 两 个 方向 。 





e Native 层 


本 地 层 的 程序 基本 上 是 由 C/C++ 编写 的 ， 与 开发 人 员 直 接 相 关 的 内 
存 函 数 包 括 malloc/free，new/delete 等 。 由 于 动态 分 配 的 内 存 需 要 人 
工 管理 ， 根 据 项 目的 开发 经 验 一 一 当 工 程 达 到 一 定数 量 级 〈 特 别 是 像 操 
作 系 统 这 样 的 大 工程 ) 时 ， 很 容易 出 现 各 种 问题 ， 如 野 指针 、 空 指针 。 
我 们 将 在 本 书 的 智能 指针 章节 详细 总 结 常见 的 一 些 内 存 致命 Bug， 并 分 
析 它 们 出 现 的 原因 ; 同时 ， 通 过 对 智能 指针 实现 原理 的 分 析 来 向 读者 曾 
述 Google 作 为 Android 系 统 的 缔造 者 又 是 如 何 有 效 避 免 这 些 让 无 数 开 发 
者 头疼 的 问题 的 。 


e Java 层 


大 多 数 Android 的 应 用 程序 都 由 Java 语 言 编 写 。Java 相 对 于 C 在 内 存 
管理 上 做 了 很 多 努力 ， 可 以 帮助 开发 人 员 在 一 定 程 度 上 摆脱 内 存 的 各 种 
困扰 。 但 是 ，Java 本 身 并 不 是 万 能 的 ， 需 要 研发 者 在 程序 设计 过 程 中 保 
持 良好 的 内 存 使 用 规范 ， 并 对 Android 提 供 的 内 存 管理 机 制 有 比较 深入 
的 理解 。 本 书后 续 的 章节 将 在 分 析 系 统 原理 的 基础 上 进一步 去 理解 上 层 
应 用 的 实现 ， 和 希望 可 以 为 读者 开发 应 用 程序 提供 一 些 帮 助 。 


4. 6.4 进程 间 通 信 
本 节 末 尾 顺 便 讲 解 一 下 mmap 函 数 ， 它 是 兼容 P0S1X 协 议 的 一 个 系统 


调用 。Linux Kerne1 和 Android 系 统 中 都 频繁 使 用 到 了 这 个 函数 。 比 如 
上 层 应 用 在 使 用 Binder 驱 动 前 ， 就 必须 通过 mmap () 来 为 其 正常 工作 提供 





mmap 


环境 。 


正如 其 名 所 示 (Memory Map) ，mmap 可 以 将 某 个 设备 或 者 文件 映射 
到 应 用 进程 的 内 存 空 间 中 ， 这 样 访问 这 块 内 存 就 相当 于 对 设备 /文件 进 
行 读 写 ， 而 不 需要 再 通过 read () ，wr ite() 了 。 由 此 可 见 ， 理 论 上 mmap 
也 可 以 用 于 进程 间 通 信 ， 即 通过 映射 同一 块 物理 内 存 来 共享 内 存 。 这 种 
a 了 数据 复制 的 次 数 ， 在 一 定 程度 上 能 提高 进程 间 通 信 的 效 


我 们 通过 图 4-16 来 加 深 对 mmap () 的 理解 。 


High Memory 


Low Memory mmapl) 


必用 和 内地 空间 a Ce bcd, 


全 图 4-16 mmap0 示 意图 
这 个 函数 提供 了 不 少 参 数 选 项 供用 户 使 用 。 其 函数 原型 为 : 
void *mmap(void *addr, size_t len, int prot, int flags, int fd, o 


我 们 来 看 看 几 个 参数 的 具体 含义 。 


e addr 


指出 文件 /设备 应 该 被 映射 到 进程 空间 的 哪个 起 始 地 址 。 这 个 参数 
如 果 为 空 ， 则 由 内 核 驱动 自行 决定 被 映射 的 地 址 。 


e len 
指出 被 映射 到 进程 空间 中 内 存 块 的 大 小 。 
。 prot 
指定 了 被 映射 内 存 的 访问 权限 ， 常 用 的 有 如 下 几 种 。 
。 PROT_READ: 内 存 页 可 读 。 
。 PROT_WRITE: 内 存 页 可 写 。 
° PROT_EXEC: 内 存 页 是 可 执行 的 。 
。 PROT_SEM: 内 存 页 可 用 于 atomic 操 作 。 
° PROT_NONE: 内 存 页 不 可 访问 。 
。 flags 
指定 了 程序 对 内 存 块 所 做 改变 将 造成 的 影响 ， 常 用 的 有 如 下 几 种 。 
° MAP_SHARED: 对 内 存 块 的 修改 将 被 保存 到 文件 中 。 


° MAP_PRIVATE: 对 内 存 块 的 修改 是 private 的 ， 即 只 在 局 部 范围 
内 有 效 。 

è MAP_FIXED: 使 用 指定 的 映射 起 始 地 址 。 

è MAP_ANONYMOUS: 匿名 映射 ， 也 就 是 说 可 以 不 和 任何 文件 进行 


关联 ， 同 时 将 fd 参数 设 为 -1。 这 是 一 种 比较 特殊 的 映射 方式 ， 通 常 
需要 进程 人 旧 有 一 定 关 系 才能 实现 。 


° fd 


被 映射 到 进程 空间 的 文件 的 描述 符 ， 通 常 是 由 open 0 返回 的 。 


e offset 
指定 了 从 文件 的 哪 一 部 分 开始 映射 ， 一 般 设 为 0。 
e 返回 值 


这 个 函数 的 返回 值 分 为 两 类 : 成 功 时 为 0， 否 则 就 是 错误 码 。 


理解 了 mmap 的 使 用 方法 后 ， 读 者 可 以 结合 本 书 的 Binder 章 节 来 综合 
ER 
FS 概 EA o 


这 样 我 们 就 完整 分 析 了 一 个 典型 操作 系统 所 应 具有 的 内 存 管理 的 核 
心 功 能 。 可 以 看 出 ， 内 存 管 理 所 涉 及 的 内 容 不仅 非 常 多 ， 而 且 很 繁杂 
这 也 是 Android 基 于 Linux 的 好 处 之 一 。Linux Kerne1 的 内 存 管 理 机 
tle “AOS Wh; 而 且 经 过 这 么 多 年 的 验证 ， 已 经 相当 稳定 成 熟 。 
因此 Android 完 全 可 以 “站 在 巨人 的 肩膀 上 ”， 去 完成 更 多 有 意义 的 事 
情 。 比 如 下 一 小 节 将 讲解 的 Low Memory Killer， 就 是 Android 在 “巨人 
肩膀 上 ”建立 的 “ 低 内 存 处 理 机 制 ”。 





4.6.5 ” 写 时 拷贝 技术 (Copy on Write) 


COW (Copy on Write) 是 Linux 中 一 个 非常 关键 的 技术 。 它 的 基本 
思想 用 一 句 话 来 概括 ， 就 是 多 个 对 象 在 起 始 时 共享 某 些 资源 (如 代码 
段 、 数 据 段 )， 直 到 某 个 对 象 需要 修改 该 资源 时 才 拥 有 自己 的 一 份 找 
贝 。 从 这 个 描述 不 难 发 现 ，C0W 完 全 可 以 被 用 到 虚拟 内 存 管理 之 外 的 其 
他 地 方 一 一 只 要 它 符 合 COW 的 预 设 场景 。 


当 我 们 调用 fork 0 级 数 生成 一 个 子 进 程 时 ， 内 核 并 没有 马上 为 这 
个 “ 另 立 门户 ”的 孩子 分 配 自己 的 物理 内 存 ， 而 是 仍然 共享 父 进 程 的 固 
有 资源 。 这 样 一 来 “分 家 ”过 程 惑 非常 快 了 一 一 理论 上 只 需要 注册 一 
个 “门户 ”就 可 以 了 。 而 如 果 新 进程 对 现 有 资源 “不 是 很 满意 ”， 希 望 
自己 去 做 些 修 改 ， 那 么 此 时 才 需 要 为 它 提供 自己 的 “施展 空间 ”。 特 别 
是 如 果子 进程 在 fork () 之 后 很 快 地 调用 了 exec 概率 很 大 ) ， 从 而 载 入 


与 父 进 程 迎 异 的 映像 ， 那 么 COW 的 存在 显然 可 以 较 大 程度 地 避免 不 必要 
的 资源 操作 ， 从 而 提升 了 运行 速度 。 


4.7 Android 中 的 Low Memory Killer 


敬 入 式 设备 的 一 个 普遍 特点 是 内 存 容量 相对 有 限 。 当 运行 的 程序 起 
过 一 定数 量 ， 或 者 涉及 复杂 的 计算 时 ， 很 可 能 出 现 内 存 不 足 ， 进 而 导致 
系统 卡 顿 的 现象 。Android 系 统 也 不 例外 ， 它 同样 面临 着 设备 物理 内 存 
短缺 的 困境 。 另 外 ， 细 心 的 开发 者 应 该 已 经 注意 到 了 ， 对 于 已 经 启动 过 
一 次 的 Android 程 序 ， 再 一 次 启动 所 花 的 时 间 明 显 减少 了 。 原 因 就 在 于 
Android 系 统 并 不 马上 清理 那些 已 经 “淡出 视野 ”的 程序 〈 比 如 调用 
Activity. finishiRQUIARM) 。 换 句 话 说， 它们 在 一 定 的 时 间 里 仍然 
驻 留 在 内 存 中 (虽然 用 户 已 经 感觉 不 到 它们 的 存在 ) 。 这 样 做 的 好 处 是 
明显 的 ， 即 下 一 次 启动 不 需要 再 为 程序 重新 创建 一 个 进程 ; 坏处 也 同样 
存在 ， 那 就 是 加 大 了 内 存 00M (Out OF Memory) 的 概率 。 


那么 ， 应 该 如 何 掌握 平衡 点 呢 ? 


熟悉 Linux 的 开发 人 员 应 该 知道 ， 底 层 内 核 有 自己 的 内 存 监控 机 
制 ， 即 00MKi 11er。 一 旦 发 现 系统 的 可 用 内 存 达 到 临界 值 ， 这 个 00M 的 管 
理 者 就 会 自动 跳出 来 “收拾 残局 ”。 根 据 策略 的 不 同 ，00M 的 处 理 手段 
略 有 差异 。 不 过 它 的 核心 思想 始终 是 : 


按照 优先 级 顺序 ， 从 低 到 高 逐步 杀 掉 进 程 ， 回 收 内 存 。 

优先 级 的 设 定 策略 一 方面 要 考虑 对 系统 的 损害 程度 〈 例 如 系统 的 核 
心 进 程 ， 优 先 级 通常 较 高 ) ， 另 一 方面 也 希望 尽 可 能 多 地 释放 无 用 内 
存 。 根 据 经 验 ， 一 个 合理 的 策略 至 少 要 综合 以 下 几 个 因素 : 

° 进程 消耗 的 内 存 ; 

° 进程 占用 的 CPU 时 间 ; 

° oom adj (OOM) 。 

我 们 先 来 了 解 下 Li nux Kernel -FAYOOM Killer。 内 核 所 管理 的 进程 
都 有 一 个 衡量 其 oom 权 重 的 值 ， 存 储 在 /proc/<P1D>/oom_adj 中 。 根 据 这 
一 权重 值 以 及 上 面 所 提 及 的 若干 其 他 因素 ， 系 统 会 实时 给 每 个 进程 评 


分 ， 以 决定 00M 时 应 该 杀 死 哪些 进程 。 比 如 oom_score 分 数 越 低 的 进程 ， 
被 杀 死 的 概率 越 小 ， 或 者 说 被 杀 死 的 时 间 越 晚 。 


这 个 值 存储 在 /proc/<P1D>/oom score 中 。 下 面 所 示 分 别 是 P1D 为 
427 和 415 的 两 个 进程 的 oom 数 值 。 


# cat proc/427/oom_adj 
cat proc /427/oom_adj 

13 

# cat proc/427/oom_score 
cat proc/427/oom_score 


355548992 


# cat proc/415/oom_adj 
cat proc/415/oom_adj 

15 

# cat proc/415/oom_score 
cat proc/415/oom_score 
1424261126 





基于 Linux 内 核 00M Killer 的 核心 思想 ，Android 系 统 扩 展 出 了 自己 
的 内 存 监 控 体 系 。 因 为 Linux 下 的 “内 存 杀 手 ” 要 等 到 系统 资源 “濒临 
绝境 ”的 情况 下 才 会 产生 效果 ， 而 Android 则 实现 了 “不 同 梯级 ”的 


Killer. 


Android 系 统 为 此 开发 了 一 个 专门 的 驱动 ， 名 为 Low Memory 
Killer (LMK) 。 源 码 路 径 在 内 核 工 程 的 
drivers/staging/android/Lowmemorykiller.c 中 。 先 来 看 看 它 的 驱动 
加 载 消 数 : 
static int _ init lowmem init(void) 

task_free_register(&task_nb); 

register_shrinker(&lowmem_shrinker); 


return 0; 


module_init(lowmem_init); 


可 见 LMK 同 内 核 线 程 kswapd 注 册 了 一 个 shr inker 的 监听 回调 ， 实 现 
体 为 1owmem_shrinker。 当 系 统 的 空闲 页 面 低 于 一 定 交 值 时 ， 这 个 回调 
就 会 被 执行 。 

Lowmemorykiller. c 中 定义 了 两 个 数组 ， 分 别 如 下 : 


static int lowmem_adj[6] = { 


12, 
J; 
static int lowmem_adj_size = 4; // 下 面 的 数值 以 此 为 单位 (页 大 小 ) 
static size_t lowmem_minfree[6] = { 
So * 512; /* 6MB */ 
2 * 1024, /* 8MB */ 
4 * 1024, /* 16MB */ 
16 * 1024, /* 64MB */ 
J; 


第 一 个 数组 lowmem_adj 最 多 有 6 个 元 素 〈 默 认 只 定义 了 4 个 ) , ER 
示 可 用 内 存 容量 处 于 “ 菜 层级 ”时 过 要 被 处 理 的 adj 值 ; 第 二 个 数组 则 
是 对 “层级 ”的 摘 述 。 举 个 例子 ，lowmem_minfree 的 第 一 个 元 素 是 
3*k512， 即 3*k512#1owmem_ adj _ size=OMB。 也 就 是 说 ， 当 可 用 内 存 小 于 
6MB 时 ，Ki ller 需 要 清理 adj 值 为 0 〈( 即 lowmem_adj 的 第 一 个 元 素 ) an 
2o aea 亡 围 是 17~~15， 数 字 越 小 表示 进程 级 别 越 


LMK 的 实现 如 图 4-17 所 示 。 


rules 
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A417 LMK 的 实现 简 图 





值得 一 提 的 是 ， 这 两 个 数组 (lowmem adj 和 |lowmem adj size) 只 
是 系统 的 预定 义 值 ， 我 们 还 可 以 根据 项 目的 实际 需求 来 做 定制 。 
Android 系 统 提供 了 相应 的 文件 来 供 我 们 修改 这 两 组 值 。 路 径 如 下 : 


/sys/module/lowmemorykiller/parameters/adj 
/sys/module/lowmemorykiller/parameters/minfree 


比如 ， 可 以 在 init. rc《〈 系 统 司 动 时 由 init 进 程 解析 的 一 个 脚本 ， 
参见 后 续 章 节 ) 中 加 入 这 样 的 语句 : 


write /sys/module/lowmemorykiller/parameters/adj 0,8 
write /sys/module/lowmemorykiller/parameters/minfree1024, 4096 


ActivityManagerService 中 有 一 个 名 为 update0omLevels 的 函数 ， 
其 内 部 实现 原理 也 是 通过 写 上 面 这 两 个 文件 来 实现 的 。 此 外 ，AMS 在 运 
行 时 还 会 根据 系统 的 当前 配置 自动 修正 adj 和 minfree， 以 尽 可 能 适 配 不 
同 的 硬件 。 具 体 如 下 所 示 : 


# cat /sys/module/lowmemorykiller/parameters/adj 
cat /sys/module/lowmenorykiller/parameters/adj 
6.1.2.4.9,.15 


# cat /sys/module/lowmemorykiller/parameters/minf ree 


cat /sys/module/lowmemorykiller/parameters/minf ree 
5181 .6727,82'73 .16321.11868 .14458 





讨论 完 LMK 所 采用 的 “rules” 后 ， 我 们 再 来 从 程序 进程 的 角度 进行 
分 析 。 显 然 ， 当 LMK 执 行 清理 工作 时 ， 它 需要 知道 当前 系统 中 所 有 进程 
的 adj 归 属 情况 。 换 句 话说 ， 即 系统 如 何 给 进程 评定 adj 等 级 。 


默认 情况 下 ，Android 会 将 所 有 进程 划 归 为 如 表 4-5 所 示 的 若干 种 
adj。 


表 4-5 _ Android 进程 所 属 ADJ 值 





用 户 前 一 次 交互 的 进程 。 按 照 用 
户 的 使 用 习惯 ， 人 们 经 常会 在 几 
个 常用 进程 间 切 换 ， 所 以 这 类 进 
程 得 到 再 次 运行 的 概率 比较 大 
Launcher 进 程 ， 它 对 于 用 户 的 重 
要 性 不 言 而 喻 

当前 运行 了 application service 的 


用 于 承载 backup 相 关 操 作 的 进程 
[1 


















HEAVY_WEIGHT _APP_ADJ=l 重 量 级 应 用 程序 进程 
; | | 


这 类 进程 能 被 用 户 感 觉 到 但 不 可 
见 ， 如 后 台 运 行 的 音乐 播放 堪 
有 前 台 可 见 的 Activity 的 进程 ， 

如 果 轻 易 杀 死 这 类 进程 将 严重 影 








啊 用 户 的 体验 
当前 正在 前 台 运 行 的 进程 ， 也 就 
= 是 用 户 正 在 交互 的 那个 程序 
PERSISTENT_ PROC ADJ= |persistent 性 质 的 进程 ， 如 
-12 telephony 


YSTEM_ADJ = -16 系统 进程 


Nn 





除了 表 4-5 所 示 的 系统 的 评定 标准 ， 我 们 有 没有 办 法 自己 来 改变 进 
程 的 adj 〈 在 Android 中 ， 被 称 为 oom_adj) 值 呢 ? 


答案 是 肯定 的 且 方 法 不 是 唯一 的 。 
T 3A 


和 前 面 的 adj 和 minfree 类 似 ， 进 程 的 oom_adj 也 可 以 通过 写 文 件 的 
形式 来 修改 ， 路 径 为 /proc/《P1D>/oom_adj。 比 如 init. rc 中 就 有 如 下 语 


句 : 


on early-init 
write /proc/1/oom_adj-16 


PID 值 为 1 的 进程 是 init 程 序 ， 这 里 将 此 进程 的 adj 改 为 16， 以 保证 
它 不 会 被 杀 死 。 


2. android:persistent 


对 于 某 些 非常 重要 的 应 用 程序 ， 我 们 不 希望 它们 被 系统 杀 死 。 一 个 
最 简单 的 方法 就 是 在 它 的 Androi dManifest. xni LHR 
给 “application” 标 签 添加 “android:persistent=true” 属 性 。 不 过 
将 应 用 程序 设置 为 常 驻 内 存 要 特别 慎重 ， 如 果 应 用 程序 本 身 不 够 完善 ， 
而 系统 又 不 能 通过 正常 方式 回收 它 的 话 ， 则 有 可 能 导致 意 想 不 到 的 问 


题 


4.8 Android 匿 名 共享 内 存 (Anonymous Shared Memory) 


Anonymous Shared Memory (简称 Ashmem) 是 Android 特 有 的 内 存 共 
享 机 制 ， 它 可 以 将 指定 的 物理 内 存 分 别 映射 到 各 个 进程 自己 的 虚拟 地 址 
空间 中 ， 从 而 便捷 地 实现 进程 间 的 内 存 共享 。 不 过 其 本 质 还 是 没有 超出 
前 面 小 节 介 绍 的 基础 知识 ， 只 能 算是 对 以 上 经 典 理 论 的 应 用 与 改进 。 


4.8.1 Ashmem 设 备 
Ashmem 的 实现 依托 于 /dev/ashmem 设 备 ， 其 源码 数量 很 少 ， 核 心 文 
件 在 Linux 工 程 中 : 


/common/mm/ashmem.c 
/common/include/linux/ashmem.h 


这 两 个 文件 都 不 长 ， 我 们 主要 关心 ashmem 设 备 的 以 下 几 个 问题 : 


。 设备 节点 是 什么 时 候 创建 的 ; 

设备 对 应 的 操作 函数 有 哪些 ， 如 open、mmap、ioctl 等 ， 以 及 它们 的 
实现 原理 ; 

它 与 linux 中 的 内 存 共享 机 制 的 区 别 与 联系 。 


当 Android 系 统 局 动 时 ，init 程 序 会 读 取 init. rc 文件 进行 解析 。 
ueventd 就 是 这 时 启动 的 ， 如 下 : 


on early-init 


start ueventd 


进程 ueventd 对 应 的 源码 在 /system/core/init/Ueventd. c 中 ， 来 看 
看 它 的 main 函 数 实现 。 
int ueventd_main(int argc, char **argv) 

struct pollfd ufd; 

int nr; 


char tmp[32]; 


ueventd_parse_config_file("/ueventd.rc"); 


snprintf(tmp, sizeof(tmp), "/ueventd.%s.rc", hardware); 
ueventd_parse_config_file(tmp) ; 


可 见 ， 默 认 情 况 下 ueventd 会 去 解析 ueventd. rc 和 uveventd. 
<hardware>. rc 文件 来 加 载 指定 的 设备 。 以 ueventd. rc 为 例 ， 它 的 格式 
大 概 如 下 : 


/dev/null 0666 root root 
/dev/zero 0666 root root 
/dev/full 0666 root root 
/dev/ptmx 0666 root root 
/dev/tty 0666 root root 
/dev/random 0666 root root 
/dev/urandom 0666 root root 
/dev/ashmem 0666 root root 
/dev/binder 0666 root root 


包括 binder，ashmem 在 内 的 一 系列 设备 节点 信息 都 会 在 这 里 被 读 取 
到 系统 中 〈 不 过 此 时 未 必 马 上 创建 节点 ) 。 具 体 细节 大 家 可 以 自行 深入 
分 析 ， 我 们 这 里 的 重点 是 ashmem 设 备 相 关 的 处 理 流程 。 先 从 ashmem 的 
init 入 口 来 看 看 它 是 什么 类 型 的 设备 : 


/*ashmem.c*/ 
static int _ init ashmem_init(void) 


{ | 
int ret; 
ashmem_area_cachep = kmem_cache_create("ashmem_area_cache", 
sizeof(struct ashmem_area), ©, ©, NULL 
ashmem_range_cachep = kmem_cache_create("ashmem_range_cache" 
sizeof(struct ashmem_range), ©, ©, NUL 
ret = misc_register(&ashmem_misc); 
return 0; 
} 


很 明显 ，ashmem 是 一 个 mi sc 设备 〈 主 设备 号 10) ， 所 以 它 使 用 
misc_register 进 行 注册 。 设 备 的 描述 如 下 : 


static struct miscdevice ashmem misc = { 
.minor = MISC_DYNAMIC_MINOR, 
,name = "ashmem", 


.fops = &ashmem_fops, 


}; 
其 实现 了 如 下 所 示 的 文件 操作 接口 : 


static struct file_operations ashmem_fops = { 
.owner = THIS_MODULE, 
.open = ashmem_open, 
.release = ashmem_release, 
.read = ashmem_read, 
.llseek = ashmem_llseek, 
.mmap = ashmem_mmap, 
.unlocked_ioctl = ashmem_ioctl, 
.compat_ioctl = ashmem_ioctl, 


}; 


全 局 变量 ashmem area cachep 和 ashmem range cachep 是 通过 
kmem_cache_create () 创建 的 kmem_cache 对 象 。 其 中 第 一 个 函数 参数 是 是 
这 个 cache 的 名 称 ， 第 二 个 参数 是 cache 大 小 ， 随 后 的 参数 分 别 表示 对 齐 
FNs ANRE EM. 


我 们 知道 ，Li nux 内 核 在 内 存 管理 上 有 Slab、Slub 和 Slob 三 种 机 
制 。Slab 是 在 2. 6. 23 版 本 以 前 内 核 所 采用 的 默认 分 配 手 段 ， 之 后 则 以 
Slub 来 代替 。Slob 则 是 更 适合 能 入 式 系统 的 一 种 内 存 管理 机 制 。 这 里 面 
涉及 很 多 内 核实 现 细 节 ， 大 家 若 有 兴趣 可 以 参阅 相关 资料 。 这 里 我 们 只 
要 明白 内 核 提供 了 一 整套 高 效 的 内 存 分 配 和 回收 机 制 即 可 。 


这 两 个 cache 是 ashmem 后 续 一 系列 操作 的 基础 ， 进 程 则 的 匿名 共享 
内 存 将 从 这 里 分 配 。 


接 下 来 ， 我 们 依次 分 析 ashmem_open、ashmem_mmap 和 和 
ashmem_ioctl. 





1. ashmem_open 


static int ashmem_open(struct inode *inode, struct file *file) 


{ 
struct ashmem_area *asma; 
int ret; 


asma = kmem_cache_zalloc(ashmem_area_cachep, GFP_KERNEL); 


INIT_LIST_HEAD(&asma->unpinned_list); 

memcpy(asma->name, ASHMEM_NAME_PREFIX, ASHMEM_NAME_PREFIX_LE 
asma->prot_mask = PROT_MASK; 

file->private_data = asma; 

return 0; 


可 以 看 到 open 主 要 做 了 两 个 工作 ， 首先 是 从 ashmem_area_cachep 分 
配 一 块 ashmem_area 内 存 ， 然 后 对 这 块 共 < 享 内 存 做 了 一 些 初始 化 操 RE, 
包括 名 称 、 权限 等 ， 并 把 它 记 录 在 fi1e- ene aoe 这 样 ， 后 续 
就 可 以 通过 fi 1e 来 访问 到 这 块 共享 内 存 了 


2. ashmem_mmap 


static int ashmem_mmap(struct file *file, struct vm_area_struct * 


{ 
struct ashmem_area *asma = file->private_data;/* 取 出 上 一 步 保存 
int ret = 0; 


mutex_lock(&ashmem_mutex) ;// EJF% 














/* 在 做 mmap 前 ， 一 定 要 先 通过 ioct1 设 置 大 小 ， 我 们 后 面 还 会 讲 到 */ 
if (unlikely(!asma->size)) { 

ret = -EINVAL; 

goto out; 


























/* 所 请 求 的 权限 保护 必须 与 我 们 给 asma 分 配 的 权限 相 匹配 */ 
if (unlikely((vma->vm_flags & ~calc_vm_prot_bits(asma->prot_ 
calc_vm_prot_bits(PROT_MASK))) { 





ret = -EPERM; 
goto out; 





if (!asma->file) {// 当 前 还 没 创建 backing file 
char *name = ASHMEM_NAME_DEF; 
struct file *vmfile; 
if (asma->name[ASHMEM_NAME_PREFIX_LEN] != '\O') 
name = asma->name; 





/* 创建 ashmem 的 临时 文 持 文件 */ 
vmfile = shmem_file_setup(name, asma->size, vma->vm_fla 


asma->file = vmfile; 


get_file(asma->file); 


if (vma->vm_flags & VM_SHARED) 
shmem_set_file(vma, asma->file); // 内 存 映 射 
else { 
if (vma->vm_file) 
fput(vma->vm_file); 
vma->vm_file = asma->file; 


} 
vma->vm_flags |= VM_CAN_NONLINEAR; 


mutex_unlock(&ashmem_mutex); 
return ret; 


在 Li nux 系 统 中 ，mmap 可 以 把 一 个 文件 〈 这 里 指 /dev/ashmem 设 备 文 
件 ) 映射 到 进程 虚拟 空间 中 ， 从 而 使 得 程序 可 以 像 使 用 内 存 一 样 去 操作 
文件 。 前 一 小 节 我 们 已 经 专门 讲解 过 mmap 的 使 用 方法 了 ， 此 处 不 再 歼 


述 。 
对 于 ashmem_mmap 有 两 点 疑问 : 
° /dev/ashmem 这 个 文件 中 的 内 存 空 间 从 何 而 来 ? 


° 使 用 ashmem 的 进程 很 多 ， 共 享 内 存 的 双方 是 如 何 建 立 关联 的 ? 
假设 有 两 对 希望 通过 ashmem 来 实现 匿名 内 存 共享 的 进程 (P11/P12 
和 P21/P22) ， 那 么 ashmem 是 如 何 正 确 区 分 它们 的 呢 ? 


在 上 面 这 个 函数 中 ， 首 先 通过 pr ivate_data 取 得 这 个 进程 的 asma， 
它 是 在 ashmem_open 时 创建 的 。 在 取得 互 斥 锁 后 ， 还 需要 检查 asma- 
>size 是 否 合 法 ， 这 个 大 小 值 是 通过 后 面 要 讲 到 的 ioct1 设 置 的 。 如 果 
asma->fi le 为 空 ， 说 明 这 是 第 一 个 访问 该 共享 空间 的 进程 。 可 以 看 到 ， 
其 中 最 关键 的 就 是 shmem_fi le_setup 函 数 。 这 个 函数 是 Linux 提 供 的 ， 
目的 就 是 在 tmpfs 中 创建 一 个 临时 文件 ， 用 于 进程 间 的 内 存 共 享 。 由 此 
可 见 ，Android 的 ashmem 实 际 上 是 借用 并 扩展 了 Linux Kernel ANA 
享 机制 。 


再 来 看 第 二 个 疑问 。 可 以 先 猜想 下 ， 即 使 用 ashmem 来 共享 ， 内 存 的 
双方 应 该 拥有 一 个 共同 的 tmpfs 中 的 临时 文件 〈 即 asma->fi le) 。 理 由 
如 下 : 


当 asma->file 为 空 时 ，ashmem 会 为 这 个 进程 创建 临时 文件 ， 并 把 它 
记录 在 asma->file 中 ， 这 可 以 看 作 P11 或 P21 的 工作 。 而 后 P12 或 者 P22 执 
行 mmap 时 ， 假 如 asma->file 不 为 空 呢 ? 此 时 自然 不 会 再 创建 一 个 tmpfs 
| 临时 文件 ， 而 是 直接 调用 shmem_set_fi le 做 好 内 存 映 射 。 ag ae 只 
要 P11/P21 与 P12/P22 拥 有 同一 个 tmpfs 临 时 文件 的 fd 描述 符 ， 则 第 二 
问题 就 迎 刃 而 解 了 。 


下 一 小 节 我 们 将 专门 分 析 Android 系 统 中 的 一 个 实例 来 证 明 上 述 猜 
测 ， 如 图 4-18 所 示 。 


3. ashmem_ioctl 


在 ashmem_mmap 的 开头 ， 程 序 需要 判断 asma->size 的 合法 性 ， 这 是 


ashmem_ioct| 


= asma asma asma ama 





全 图 4-18 ashmem 中 的 内 存 共享 示意 图 
提供 的 诸多 功能 之 一 : 


static long ashmem_ioctl(struct file *file, unsigned int cmd, uns 
{ 

struct ashmem_area *asma = file->private_data; 

long ret = -ENOTTY; 


Switch (cmd) { 

case ASHMEM_SET_NAME:// 设 置 名 称 
ret = set_name(asma, (void __user *) arg); 
break; 

case ASHMEM_GET_NAME:// 获 取 名 称 
ret = get_name(asma, (void __user *) arg); 
break; 


case <strong>ASHMEM_SET_SIZE</strong>://iK eK) 
ret = -EINVAL; 
if (!asma->file) { 
ret = 0; 
asma->size = (size_t) arg; 


break; 


return ret; 


这 个 函数 的 实现 相对 简单 ， 即 根据 ioct1 命 令 来 做 相应 的 操作 一 一 
比如 设置 和 获取 size 大 小 、 名 称 等 ， 并 将 信息 保存 到 各 个 进程 自己 的 


asma 中 。 


4.8.2 Ashmem 应 用 实例 


上 一 小 节 我 们 分 析 了 /dev/ashmem 设 备 驱动 中 3 个 重要 函数 的 源码 实 
现 。Android 系 统 就 是 基于 ashmem 设 备 来 实现 跨 进 程 内 存 共 享 的 ， 如 


MemoryDealer. 


MemoryDealer 可 以 看 作对 ashmem 的 封装 ， 源 码 位 于 
frameworks/native/1ibs/binder 中 ， 可 见 它 与 Binder 机 制 有 直接 关 
联 。MemoryDealer 在 Android 中 有 不 少 应 用 场景 ， 如 音频 系统 中 的 
AudioFlinger 就 是 通过 它 来 与 AudioTrack 实 现 跨 进程 的 音频 数据 传递 
二 从 而 
—H SrA. 


先 来 看 AudioF1inger 这 边 的 操作 : 


AudioFlinger::Client::Client(const sp<AudioFlinger>& audioFlinger 
RefBase(), 
mAudioFlinger(audioFlinger), 
mMemoryDealer (new MemoryDealer(1024*1024, "AudioFlinger:: 


MemoryDealer 内 部 有 两 个 重要 的 成 员 变 量 ， 即 mHeap 和 
mAllocator。 从 名 称 上 可 以 看 出 ，mAllocator 是 一 个 “内 存 分 配器 ”， 
它 服务 的 对 象 是 “内 存 承 载体 ” mHeap 。 举 个 例子 ，mHeap 就 像 餐厅 
座位 ， 而 mAllocator 则 是 服务 员 。 当 客人 有 用 餐 请 求 时 ， 服 务 员 需 要 根 
据 具 体 人 数 来 安排 他 们 。 服 务 员 可 采用 的 分 配 策略 多 种 多 样 ， 总 的 原则 





就 是 尽量 满足 大 部 分 顾客 的 需求 。 


从 实现 上 来 看 ，mHeap 是 一 个 MemoryHeapBase 对 象 。 构 造 浸 数 如 
F 


MemoryHeapBase: :MemoryHeapBase(size_t size, uint32_t flags, char 


const size_t pagesize = getpagesize(); 
size = ((size + pagesize-1) & ~(pagesize-1)); 
int fd = ashmem_create_region(name == NULL ? "MemoryHeapBase" 
if (fd >= 0) { 
if (mapfd(fd, size) == NO_ERROR) {// 空 间 映 射 


} 


量 fd 是 由 ashmem_create_region 返 回 的 文件 描述 符 ， 可 想 而 知 它 
oe e i 这 个 函数 在 
system/core/ l ibcuti |s/Ashmem-host. cA 
system/core/ l| ibcutils/Ashmem-dev. c 中 都 有 实现 。 以 “host” 结 尾 的 
是 提供 给 模拟 器 的 ， 而 以 “dev” 为 后 缀 的 则 是 为 真实 设备 服务 的 。 我 
们 只 看 后 面 文件 中 的 实现 : 


int ashmem_create_region(const char *name, size_t size) 
{ 

int fd, ret; 

fd = open(ASHMEM_DEVICE, O_RDWR); 


if (name) { 
char buf [ASHMEM_NAME_LEN]; 
stricpy(buf, name, sizeof(buf)); 
ret = ioctl(fd, ASHMEM_SET_NAME, buf);// REZEK 
if (ret < 0) 
goto error; 


} 
ret = ioctl(fd, ASHMEM_SET_SIZE, size);//i#XK/) 


} 

果不其然 ， 首 先 就 打开 了 ASHMEM_DEV1CE=' '/dev/ashmem" 这 个 设 
备 ， 然后 依 ， 欠 执 行 ASHMEM_SET AAE TSIEN SET_S1ZE 这 两 个 ioct1 命 
令 ， 这 也 和 我 们 前 面 的 分 析 吻 合 


打开 ashmem 后 ， 接 下 来 要 把 设备 空间 映射 到 进程 中 来 ， 也 就 是 
mapfdek Ay SLEW ANID BE : 


status_t MemoryHeapBase::mapfd(int fd, size_t size, uint32_t offs 


{ 


if ((mFlags & DONT_MAP_LOCALLY) == 0) { 
void* base = (uint8_t*)mmap(0, Size, PROT_READ|PROT_WRITE, 


mBase = base; 
mNeedUnmap = true; 
} else { 


} 

mFD = fd; 

mSize = size; 
mOffset = offset; 
return NO_ERROR; 


MemoryHeapBase 内 部 有 一 系列 成 员 变 量 来 保存 共享 内 存 相关 的 数 
据 ， 如 mBase 就 是 共享 内 存 映射 到 进程 空间 中 的 内 存 起 点 ，mFD 是 ashmem 
设备 相对 应 的 文件 描述 符 ，mSize 是 被 映射 空间 的 大 小 等 。 


这 样 ashmem 设 备 就 为 AudioF 1inger 开 尽 了 一 块 共享 内 存 ， 那 么 如 何 
让 AudioTrack 也 知道 这 块 内 存 呢 ? 根据 前 一 小 节 的 猜测 ， 
通过 文件 描述 符 fd 来 与 这 块 共享 区 建立 关联 的 。 那 么 问题 转化 为 : 怎么 
把 fd 这 个 值 传 给 AudioTrack? 


大 家 可 能 马上 会 想到 Binder 机 制 。 没 错 ， 确 实 是 通过 它 来 实现 的 。 
AudioTrack 先 通过 getCb1k 来 获得 一 个 1IMemory 对 象 : 


sp<IAudioTrack>track = audioFlinger->createTrack(...); 
sp<IMemory> cblk = track->getCblk(); 


其 中 的 track 变 量 是 AudioTrack 与 AudioF linger 的 连接 通道 。 按 照 
Binder 机 制 的 实现 原理 ，track->getCblk () 最 终 执 行 的 是 
TrackBase (此 时 已 经 在 AudioFlinger 进 程 ) 中 的 getCb1k: 


sp<IMemory> getCblk() const { return mCblkMemory; } 


而 这 个 mcb1kMemory 则 是 由 TrackBase 在 构造 时 申请 的 : 


mCblkMemory = client->heap()->allocate(size); 


这 里 的 cl ient->heap 就 是 前 面 所 说 的 MemoryDealer， 它 的 
allocate () 函数 会 返回 由 MemoryHeap Base 申 请 的 内 存 映射 空间 : 


sp<IMemory> MemoryDealer::allocate(size_t size) 


sp<IMemory> memory; 
const ssize_t offset = allocator()->allocate(size); 
// 通 过 “服务员 ”来 分 配 “ 座 位 ”， 不 过 ] 
// 只 得 到 “座位 号 ” 
if (offset >= 0) { 
memory = new Allocation(this, heap(), offset, size);// 分 配 


return memory; 


按照 前 面 所 做 的 类 比 ，allocator 是 “服务 ” 员 ， 于 是 通过 它 可 以 
安排 到 “座位 ”。 不 过 并 不 是 mHeap 本 身 ， 而 是 Al location, RIRI 
析 下 原因 。 


Al location 构 造 国 数 : 


/*frameworks/native/libs/binder/MemoryDealer .cpp*/ 
Allocation: :Allocation(const sp<MemoryDealer>& dealer, 
const sp<IMemoryHeap>& heap, ssize_t offset, size_t size) 
: MemoryBase(heap, offset, size), mDealer (dealer) 


{ 

#ifndef NDEBUG 
void* const start_ptr = (void*)(intptr_t(heap->base()) + offs 
memset(start_ptr, Oxda, size); 

#endif 


Í 


1MemoryHeap 和 1Memory 是 什么 关系 呢 ?” 前 者 是 MemoryHeapBase 的 父 
类 ， 后 者 则 是 Al 1ocation 的 父 类 。 这 几 个 类 的 取 名 并 不 是 太 合 理 ， 很 容 
易 引 起 混乱 ， 它 们 的 关系 如 图 4-19 所 示 。 


也 就 是 当 Al1ocati on 构造 时 ， 由 第 二 个 参数 传 入 的 就 是 
IMemoryHeap 对 象 ， 对 应 的 是 前 面 我 们 分 析 过 的 MemoryHeapBase， 这 样 
1Memory 和 和 1MemoryHeap 就 建立 了 关联 。 


分 析 完 AudioF linger (Server) 这 一 侧 ， 我 们 回 到 
AudioTrack (Client) 端 。 也 就 是 : 


sp<IMemory> cblk = track->getCblk(); 


我 们 知道 cb lk 是 一 个 1IMemory 对 象 ， 那 么 它 是 BnMemory 吗 ? 不 是 。 
这 是 由 Binder 的 实现 原理 决定 的 。Server 端 是 BnMemory， 那 么 Client 端 
对 应 的 通常 就 应 该 是 BpMemory。 这 些 细节 我 们 将 在 后 续 的 Binder 原 理 章 
节 进 行 详细 解释 ， 这 里 要 记 住 cblk 实 际 上 是 一 个 BpMemory。 


cblk 此 时 还 没有 接触 到 真正 的 共享 内 存 一 一 需要 由 接 下 来 的 代码 从 
IMemory 中 进一步 获取 : 


mCblk = static_cast<audio_track_cblk_t*>(cblk->pointer()); 


变量 mCb1k 的 数据 类 型 是 audio_track_cblk_t。 按 照 我 们 的 猜测 ， 
它 的 内 部 一 定 会 存储 共享 内 存 被 映射 到 AudioTrack 进 程 空 间 中 的 虚拟 地 
址 (mmap 后 的 结果 ) 。 换 句 话说 ，cblk->pointer 从 表面 上 看 很 简单 ， 
但 实际 上 它 要 完成 : 


ô 得 到 AudioFlinger 中 创建 的 这 块 共享 内 存 的 地 址 ; 


° 将 这 个 地 址 进一步 转化 成 AudioTrack 可 以 直接 访问 的 虚拟 地 
HE; 
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全 图 4-19 IMemory 和 ImemoryHeap 的 继承 关系 图 
前 面 说 过 ， 两 个 进程 在 ashmem 中 之 所 以 能 共享 同一 内 存 ， 是 因为 它 
们 使 用 了 一 样 的 ashmem 文 件 摘 述 符 。 这 惑 是 cb 1k->pointer 要 完成 的 重 
点 所 在 。 


因为 cblk 是 BpMemory， 而 BpMemory 也 继承 自 IMemory， 关 系 如 图 4- 
20 所 示 。 
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全 图 4-20 Client 49 Memory 


所 以 cblk->pointer， 实 际 上 就 是 1Memory: :pointer () 。 具 体 源 人 码 
如 下 : 


/*frameworks/native/libs/binder/IMemory.cpp*/ 
void* IMemory::pointer() const { 
ssize_t offset; 
sp<IMemoryHeap> heap = getMemory(&offset); 
void* const base = heap!=0 ? heap->base() : MAP_FAILED; 
if (base == MAP_FAILED) 
return 0; 
return static_cast<char*>(base) + offset; 


这 个 函数 首先 调用 BpMemory : :getMemory 得 到 1MemoryHeap， 也 就 是 
BpMemoryHeap， 然 后 调用 其 base () 方法 〈base 实 际 上 就 直接 调用 了 
getBase ) 


void* BpMemoryHeap::getBase() const { 


assertMapped(); 
return mBase; 


很 精练 的 两 句 话 ， 看 来 玄机 应 该 就 在 下 面 这 个 函数 中 了 : 


void BpMemoryHeap: :assertMapped() const 





if (mHeapId == -1) {// 当 前 是 第 一 次 调用 ， 说 明 还 没有 做 过 映射 
sp<IBinder> binder(const_ cast<BpMemoryHeap*>(this)->asBin 
sp<BpMemoryHeap> heap(static_cast<BpMemoryHeap*>(find_hea 
heap->assertReallyMapped(); 


假如 mHeap1d == 说 明 还 没有 把 共享 内 存 映 射 到 虚拟 空间 中 
来 。 BEI pe 同一 块 共享 内 存 ， 
因而 它 使 用 find_heap 来 判断 是 否 已 经 存在 一 个 与 binder 相 对 应 的 
heap。 如 果 是 直接 增加 计数 返回 即 可 ， 否 则 还 需要 做 映射 。 具 体 实现 如 
下 : 


void BpMemoryHeap: :assertReallyMapped() const 


if (mHeapId == -1) { 
Parcel data, reply; 
data.writeInterfaceToken(IMemoryHeap: :getInterfaceDescrip 
status_t err = remote()->transact(HEAP_ID, data, &reply); 
int parcel_fd = reply.readFileDescriptor() ;//3t#{AudioFlin 
// 设 备 文件 描述 符 














int fd = dup( parcel_fd ); 


Mutex: :Autolock _1(mLock); 
if (mHeapId == -1) { 
mRealHeap = true; 
mBase = mmap(0, size, access, MAP_SHARED, fd, offset) 


CO RAR BAILA tewritelnterfacetoken, Parcel, remote ()- 
>transact 等 变量 和 函数 方法 是 什么 意思 ， 建 议 先 放 一 放 ， 等 学 习 了 
Binder 和 章节 后 再 回 过 头 来 分 析 。 简 单 地 说 ，remote () ->transact 就 是 向 
Server 端 发 起 了 一 个 请 求 (HEAP_1D) ， 即 得 到 文件 描述 符 。 如 下 
BnMemoryHeap 源 码 所 示 : 


status_t BnMemoryHeap::onTransact(uint32_t code, const Parcel& da 


Switch(code) { 
case HEAP_ID: 
CHECK_INTERFACE(IMemoryHeap, data, reply); 
reply->writeFileDescriptor(getHeapID()); 


郧 数 getHeap1D 的 实现 如 下 : 


/*frameworks/native/libs/binder/MemoryHeapBase.cpp*/ 
int MemoryHeapBase::getHeapID() const { 

return mFD; 
} 


所 以 ，reply. readFi leDescriptor 得 到 的 就 是 在 AudioTrack 中 可 用 
的 ashmem 文 件 摘 述 符 。 接 着 就 可 以 通过 这 个 fd 进行 map 了， 从 而 成 功 地 
将 AudioFlinger 中 创建 的 共享 内 存 映射 到 AudioTrack 所 在 的 进程 空间 
中 。 


Android 系 统 中 的 匿名 共享 机 制 涉 及 了 设备 驱动 、Binder 原 理 等 一 
系列 技术 ， 所 以 初学 者 可 能 很 难 理解 。 建 议 大 家 在 充分 学 习 相关 基础 知 
识 后 ， 再 集中 精力 攻克 这 一 难关 。 


4.9 JNI 


在 后 续 章节 的 原理 分 析 中 ， 我 们 经 常 要 涉及 JNI (Java Native 
Interface) 这 一 概念 。 它 是 一 种 允许 运行 于 JVM 的 Java 程 序 去 调用 〈( 反 
向 亦 然 ) 本 地 代码 〈 通 常 JNI 面 向 的 本 地 代码 是 用 C、C++ 以 及 汇编 语言 
编写 的 ) 的 编程 框架 。 本 地 代码 通常 与 硬件 或 者 操作 系统 有 关联 ， 因 而 
会 在 一 定 程 度 上 破坏 Java 本 身 的 可 移植 性 。 不 过 有 时 这 种 方法 是 必需 
的 ， 如 Android 系 统 中 就 采用 了 大 量 JN1 手 段 去 调用 本 地 层 的 实现 库 。 


通常 有 以 下 3 种 情况 需要 用 到 JN1 。 


。 应 用 程序 需要 一 些 平台 相关 的 feature 的 支持 ， 而 Java 无 法 满足 。 

。 兼 容 以 前 的 用 其 他 语言 书写 的 代码 库 。 使 用 JNI 技 术 可 以 让 Java 层 的 
代码 访问 到 这 些 旧 库 ， 实 现 一 定 程度 的 代码 复 用 。 

。 应 用 程序 的 某 些 关键 操作 对 运行 速度 要 求 较 高 。 这 部 分 代码 可 以 用 
底层 语言 如 汇编 来 编写 ， 再 通过 JNI 向 Java 层 提供 访问 接口 。 


JNI 在 Android 系 统 中 扮演 了 非常 重要 的 角色 ， 我 们 有 必要 先 对 它 进 
行 讲 解 。 其 主要 涉及 以 下 两 方面 。 





e Java Code->Native Code 
Java 语 言 如 何 调用 本 地 技 的 函数 方法 与 变量 。 
e Native Code->Java Code 


虽然 多 数 情 况 下 都 是 APK 应 用 程序 通过 Java 源 人 码 去 调用 本 地 层 代 
码 ， 但 在 有 些 情 况 下 本 地 层 代 码 也 同样 需要 访问 Java 层 的 实现 一 一 包括 
用 Java 实 现 的 函数 与 变量 。 
4.9.1 Java 函数 的 本 地 实现 

创建 一 个 可 供 Java 代 码 调用 的 本 地 子 数 的 步 又 如 下 : 


。 将 需要 本 地 实现 的 Java 方 法 加 上 native 声 明 ; 
。 使 用 javac 命 令 编 译 Java 类 ; 


使 用 javah 生 成 .h 头 文件 ; 

在 本 地 代码 中 实现 native 方 法 ; 
编译 上 述 的 本 地 方法 ， 生 成 动态 链接 库 ; 

在 Java 类 中 加 载 这 一 动态 链接 库 ; 

Java 代 码 中 的 其 他 地 方 可 以 正常 调用 这 一 native 方 法 。 


下 面 我 们 以 一 个 范例 来 说 明 这 一 过 程 : 


/*TestJNI.java*/ 
class TestJNI 


z private native void testJniAdd(int vi, int v2); // 用 native 关 
public void test() 
System.out.println ("The result:" + testJniAdd(2,3)); 
public static void main(String args[]) 
TestJNI JniExample = new TestJNI(); 
JniExample.test(); 
ee 
System.loadLibrary("testJniLib");/* 加 载 本 地 代码 实现 库 */ 
} 


接 下 来 ， 首 先 使 用 javac 编 译 上 面 的 TestJN1. java, ERK 
TestUNI. class。 然 后 利用 javah 生 成 TestJN1. h 文 件 ， 其 中 就 包含 了 JN| 
方法 的 声明 体 : 


JNIEXPORT void JNICALL Java_TestJNI_testJniAdd (JNIEnv *, jobject 
有 了 TestJN1. h 后 ， 我 们 将 上 述 的 函数 声明 用 本 地 语言 来 实现 。 功 
能 很 简单 一 一 直接 将 两 个 数值 相 加 的 和 返回 给 调用 者 : 


JNIEXPORT void JNICALL Java_TestJNI_testJniAdd(JNIEnv * env, jobj 
{ 





return value1 + value2; 


最 后 ， 只 要 将 上 述 包 含 JNI 方 法 的 文件 〈 比 如. ce、. cpp 等 。 这 里 有 


一 个 小 技巧 来 快速 创建 它们 ， 就 是 将 上 面 javah 生 成 的 . h 改 个 后 缀 名 ， 
这 样 所 有 的 声明 体 和 头 文件 引用 都 不 用 再 手工 输入 了 ) 编译 成 动态 链接 
库 ， 然 后 让 TestJN1 加 载 进去 ， 整 个 JNI 框 架 就 运行 起 来 了 。 


关于 如 何 编译 生成 动态 链接 库 ， 已 经 有 非常 多 的 参考 资料 一 一 比如 
利用 VS Studio， 或 者 采用 某 些 开源 的 小 工具 等 。 其 实 ，Android 系 统 本 
身 也 提供 了 非常 方便 的 实现 来 完成 这 一 功能 一 一 NDK (Native 
Development Kit) . 


这 里 简要 介绍 下 如 何 通 过 NDK 生 成 JNI 库 。 首 先 当 然 是 要 下 载 NDK 
包 ， 可 以 从 官网 获取 到 : 


http://developer.android.com/tools/sdk/ndk/index.html 
然后 ， 依 次 执行 以 下 步骤 来 编译 动态 库 。 


。 将 之 前 生成 的 Jai 本 地 源码 文件 放 在 工程 某 个 目录 下 ， 建 议 是 
<project>/jni/ 
e 在 <project>/jni 中 生成 一 个 Android.mk 文 件 来 描述 本 地 源码 。 下 面 
是 一 个 范例 : 
/*Android.mk*/ 


LOCAL_PATH := $(call my-dir) 
include $(CLEAR_VARS) 


LOCAL_MODULE 
LOCAL_SRC_FILES : 


testJniLib 
testJniLib.c 


include $(BUILD_SHARED_LIBRARY ) 


7 


9 注意 
我 们 要 编译 的 是 “BUILD SHARED LIBRARY” 。 


e 在 <project>/jni 中 生成 一 个 Application.mk (FU) 。 
。 利 用 如 下 命令 执行 编译 ; 


cd <project> 


<ndk>/ndk-build 


从 上 面 的 Java_TestJN1_testJniAdd 方 法 中 ， 我 们 看 到 诸如 
JNIEnv、jobject 这 样 的 参数 类 型 ， 而 Java 层 的 testJniAdd 本 身 并 没有 
带 这 两 个 参数 。 第 一 反应 是 它们 应 该 为 类 似 于 C++ 中 的 thi s 指 针 ， 即 代 
表 了 类 的 一 个 实例 化 对 象 。 事 实 上 也 确实 如 此 ，JNIEnv 的 定义 如 下 : 


typedef const struct JNINativeInterface *JNIEnv; 


JNINativelnterfacese=—TUNIAVAIHIEO, BETR SA HH 
T eens 而 jobject 则 代表 了 这 个 本 地 类 方法 对 应 的 
Java 类 实例 。 


Java_TestJNI_testJniAdd 函 数 中 的 最 后 两 个 参数 ， 才 是 函数 的 真 
正 入 参 。 不 过 和 我 们 之 前 看 到 的 数据 类 型 不 同 ， 它 们 是 jint， 而 不 是 
int。 这 是 因为 JNI 已 经 对 所 有 的 标准 数据 类 型 做 了 相应 的 typedef， 可 
以 参照 表 4-6 和 表 4-7。 


表 4-6 JN1 基 础 类 型 对 照 表 





int jint signed 32 bits 


jlong signed 64 bits 


jfloat 32 bits 


mp 
iii 


long 





表 4-7 J NI 引用 数据 类 型 对 照 表 
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booleanArray jdoubleArray 
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基础 类 型 的 变量 可 以 在 Java 和 本 地 代码 间 进 行 复制 ， 而 Java 对 象 需 
要 通过 引用 类 型 进行 传递 。JVM 需 要 跟踪 所 有 它 传 递 给 本 地 代码 的 对 象 
实例 ， 这 样 才能 保证 它们 不 被 垃圾 回收 器 收回 。 而 当 本 地 代码 不 再 使 用 
这 些 对 象 时 ， 也 要 及 时 通知 JVM。 


这 里 再 顺便 介绍 一 下 Type Signature， 它 是 数据 类 型 的 标签 ， 如 表 
4-8 所 示 。 


表 4-8 Type Signature 


Type 


Signature Java Type Type Signature 


fully-qualified- L fully-qualified- 
class class 


method type ( arg-types ) ret-type 
= 一 二 





比如 一 个 Java 方 法 : 
long aMethod(int n, String s, int[] arr); 
那么 就 可 以 表示 为 : 
(ILjava/lang/String; [1I]J 


其 中 ， 括 号 里 表示 的 是 函数 万 法 的 参数 ， 尾 部 是 返回 值 。 这 样 的 表 
达 万 式 看 起 来 非常 简洁 ， 而 且 可 以 用 字符 串 的 形式 来 表达 ， 因 此 在 JNI 
中 使 用 非常 广泛 。 


4.9.2 本 地 代码 访问 JVM 


上 一 小 节 我 们 讲解 了 如 何 为 一 个 Java 函 数 创建 本 地 实现 ， 但 这 并 不 
是 JNI 的 全 部 。 试 想 一 下 ， 既 然 Java 可 以 调用 C/C++ 等 语言 编写 的 源码 ， 
那么 反 过 来 是 否 也 可 行 呢 ? 答案 是 肯定 的 。 本 地 层 同 样 可 以 访问 JVM 空 
间 ， 这 是 JN1 的 另 一 个 重要 组 成 部 分 。 本 小 节 中 我 们 将 向 大 家 展示 如 何 
做 到 这 种 “逆向 ”的 操作 。 


先 来 看 看 前 面 提 到 的 JNIEnv 类 型 的 变量 ， 它 是 本 地 代码 函数 中 的 第 
一 个 人 参数， 代表 了 一 个 JNI interface pointer。 其 本 质 是 指向 了 一 个 
消 数 列表 的 指针 ， 如 图 4-21 所 示 。 


INI Interface Pointer 





A 4-21 JNI Interface Pointer 


JNI Interface Pointer 之 所 以 没有 直接 做 成 “ 硬 编码 ”形式 的 函 
数 调 用 ， 而 采用 如 图 4-21 所 示 的 函数 指针 形式 ， 是 为 了 给 JN1 的 实现 市 
来 更 多 灵活 性 。 它 有 点 类 似 于 C++ 中 虚 函 数 的 概念 ， 在 运行 时 才 会 动态 
决定 需要 真正 被 调用 的 目标 函数 。 


JN1 通 过 名 称 和 Type Signatures 来 访问 Java 类 中 的 域 (fields) 和 
方法 (methods) 。 比 如 下 面 两 行 语句 : 


jmethodID mid = env->GetMethodID(cls, "methodExample", "(ILjava/1l 
/* 首 先 通 过 名 称 ^“methodExample” 和 它 的 type signature 来 找到 这 个 7 
jdouble result = env->CallDoubleMethod(obj, mid, 10, str); 
/* 通 过 相应 的 Cal1l1XXXMethod( ) 来 访问 到 此 ID 值 所 指向 的 方法 */ 





除了 域 和 方法 ，JNI 其 实 还 提供 了 一 系列 的 函数 来 完成 对 Java 的 各 
种 访问 和 控制 ， 如 异常 处 理 、 本 地 和 全 局 引用 、 字 符 串 操作 、 数 组 操作 
和 反射 支持 等 。 这 些 函 数 都 包含 在 了 JNIEnv 这 个 变量 中 ， 因 而 每 个 本 地 


函数 都 能 使 用 它 的 第 一 个 参数 来 获取 JN1 为 它们 提供 的 丰富 的 功能 接 
口 。 


由 于 这 个 函数 指针 列表 中 包含 的 接口 数量 众多 ， 接 下 来 我 们 只 挑选 
其 中 常用 的 一 部 分 操作 来 做 简单 的 介绍 。 有 需要 的 读者 可 以 参阅 官方 文 
档 来 做 进一步 了 解 : (http://docs. oracle. com/ javase/ 
6/docs/technotes/guides/ jni/spec/functions. html) 。 


Version Information 
jint GetVersion(JNIEnv *env); 


返回 本 地 方法 接口 的 版 本 号 ， 即 : 
JDK/JRE 1.1, GetVersion() --> 0x00010001. 
JDK/JRE 1.2, GetVersion() --> 0x00010002. 


JDK/JRE 1.4, GetVersion() --> 0x00010004. 
JDK/JRE 1.6, GetVersion() --> 0x00010006. 


Class Operations 
jclass FindClass(JNIEnv *env, const char *name); 
参数 说 明 : 


env: JNI Interface Pointer 
name: fully-qualified class name， 即 用 “/ 隔 开 的 完整 的 package name 


从 Java2 SDK release 1.2 开 始 ，FindClass 自 动 定 位 与 此 本 地 方法 
相关 联 的 class loader 。 如 果 此 本 地 方法 属于 system class， 则 不 会 有 
相对 应 的 class loader 。 此 时 便 会 使 用 : ClassLoader. getSystem 
ClassLoader; 否则 将 由 相应 的 1oader 来 完成 name 所 指定 的 class 的 加 
载 。 


Accessing Fields of Objects 


(1) jfieldID GetFieldID (JNIEnv *env, jclass clazz, const 
char *name, const char *sig) ; 


参数 说 明 : 


env: JNI Interface Pointer 


clazz: Java class object 
name: 以 9 为 结束 符 的 UTF- 8 编码 字符 串 ， 表 示 域 名 
Sig: 以 90 为 结束 符 的 UTF- 8 编码 字条 串 ， 表 示 域 名 的 标签 


返回 值 : 成 功 则 返回 field 1D， 否 则 就 是 nul1。 


EAA RETARA 〈 非 静态 ) 中 的 域 的 1D， 这 个 域 由 参数 中 的 
name 和 signature 指 定 。 只 有 先 得 到 了 某 个 域 的 1D 值 ， 才 能 使 用 Get 和 
set 方 法 来 继续 对 它 进 行 操 作 。 


(2) NativeType Get<type>Field(JNIEnv *env, jobject 
obj, jfieldID fieldID) ; 


过 上 面 接口 获取 到 field 1D 后 ， 我 们 可 以 进一步 取得 此 field 的 
a. 


SUERA M#lGetField |IDS—HA, WAR Ba. BPS 
<type> 代 表 了 不 同 数据 类 型 的 fie1d， 如 0bject、Boolean、Byte 等 : 


GetObjectField() //Field 的 类 型 为 object 
GetBooleanField()  //Field 的 类 型 为 boolean 


GetByteField() //Field 的 类 型 为 byte 
GetCharField() //Field 的 类 型 为 char 
GetShortField() //Field 的 类 型 为 short 


(3) void Set<type>Field(JNIEnv *env, jobject obj, 
jfieldID fieldID, NativeType value); 


设置 fie1d 的 值 ， 它 和 Get<type>Fie1d 的 参数 差别 在 于 最 后 的 
NativeType， 即 需要 给 这 个 域 设 定 新 的 值 。 和 和 Get 一样，type 指 代 了 不 
同 数据 类 型 的 fiel1d。 


Calling Instance Methods 


(1) jmethodID GetMethodID (JNIEnv *env, jclass 
clazz, const char *name, const char *sig) ; 


返回 一 个 类 或 接口 对 象 中 的 方法 〈 非 静态 ) 的 1D 值 。 
BH 


env: JNI Interface Pointer 

clazz: Java class object 

name: 以 9 为 结束 符 的 UTF- 8 编码 字符 串 ， 代 表 方 法 名 称 

Sig: 以 0 为 结束 符 的 UTF-8 编 码 字 符 串 ， 代 表 方 法 的 method signature 

















(2) NativeType Call<type>Method (JNIEnv *env, jobject 
obj, jmethod|ID methodID, ...); 


NativeType Call<type>MethodA(JNIEnv *env, jobject obj, jmethodID m 
NativeType Call<type>MethodV(JNIEnv *env, jobject obj, jmethodID m 


通过 GetMethod1D 获 得 万 法 的 ID 后， 就 可 以 利用 这 个 值 来 调用 相应 
的 Java 方 法 了 。 上 面 列 出 的 3 个 函数 的 区 别 在 于 它们 传递 参数 的 机 制 不 
同 。 


e Call<type>Method 


从 函数 的 声明 可 以 看 出 ， 这 种 方式 的 调用 会 将 参数 全 部 直接 放 在 
method 1D 后 面 。 


e Call<type>MethodA 
以 数组 的 形式 传递 参数 ， 即 先 将 所 有 参数 放 入 args 变 量 中 。 
e Call<type>MethodV 
以 va_list 的 形式 传递 参数 。 
“type> 类 型 和 之 前 提 到 的 几 个 函数 都 是 一 样 的 ， 下 面 举 几 个 例子 : 


CallVoidMethod( ) 
CallVoidMethodA( ) 
CallVoidMethodV() 
CallObjectMethod( ) 
CallObjectMethodA( ) 
CallObjectMethodV() 
CallBooleanMethod() 
CallBooleanMethodA( ) 
CallBooleanMethodv( ) 


我 们 在 描述 方法 和 域 的 访问 函数 时 ， 都 特别 强调 了 是 针对 非 静态 的 
情况 。 对 于 静态 的 方法 与 域 ，JNI 还 有 专门 的 访问 方式 。 不 过 原理 都 是 


大 同 小 异 的 ， 请 读者 参考 相关 文档 。 而 JN1 提 供 的 诸如 字符 串 、 数 组 等 
操作 都 比较 简单 ， 这 里 不 再 详细 讨论 。 


在 后 续 章节 的 分 析 中 ， 我 们 还 会 针对 具体 场景 对 JN1 做 进一步 讲 


解 


4.10 Java 中 的 反射 机 制 | 
Java 中 创建 一 个 Class 类 最 常见 的 方式 如 下 : 


FileOutputStream fout = <strong>new</strong> FileOutputStream( fd) 


这 种 情况 意味 着 我 们 在 编译 期 便 可 以 确定 Class 类 型 。 此 时 编译 器 
可 以 对 new 关 键 字 做 很 多 优化 工作 ， 所 以 这 种 场景 下 的 运行 效率 通常 是 
最 好 的 ， 是 开发 人 员 的 首选 方式 。 


而 对 于 那些 无 法 在 编译 阶段 就 得 到 确定 的 Class 类 的 情况 ， 我 们 希 
望 有 一 种 技术 可 以 在 程序 运行 过 程 中 去 动态 地 创建 一 个 对 象 一 一 这 就 是 
反射 机 制 。 反 射 机 制 能 够 赋予 程 序 检 查 和 修正 运行 时 行为 的 能 力 ， 下 面 
我 们 就 以 Class 类 的 动态 创建 为 例 ， 简 单 分 析 一 下 其 内 部 的 实现 原理 : 


Class<?> clazz = null; 
try { 
clazz = Class.forName("android.media.MediaMetadataRet 
instance = clazz.newInstance(); 
Method method = clazz.getMethod("setDataSource", Stri 
method.invoke(instance, filePath); 





Class. forName 通 过 nat ive 国 数 classForName 调 用 到 本 地 层 ， 在 
Android N 版 本 中 对 应 的 具体 函数 如 下 : 


/*art/runtime/native/java_lang_Class.cc*/ 
static jclass Class_classForName(JNIEnv* env, jclass, jstring jav 
jboolean initialize, jobject javaLoader) { 
ScopedFastNativeObjectAccess soa(env); 
ScopedUtfChars name(env, javaName); 


Handle<mirror::ClassLoader> class_loader(hs.NewHandle(soa.Decod 
ClassLinker* class_linker = Runtime: :Current()->GetClassLinker ( 
Handle<mirror::Class> c( 
hs.NewHandle(class_linker->FindClass(soa.Self(), descriptor 
class_loader))); 


return soa.AddLocalReference<jclass>(c.Get()); 


} 


可 见 ，forName 最 终 是 通过 C1assLinker::FindClass 来 找到 目标 类 
对 象 的 。 反 射 机 制 提供 的 其 他 接口 也 是 类 似 的 只 有 经 过 虚拟 机 的 统 





一 管理 ， 才 有 可 能 既 为 程序 提供 灵活 多 样 的 动态 能 力 ， 同 时 又 保证 了 程 
序 的 正常 运行 。 


对 于 ClassLinker 的 进一步 分 析 ， 读 者 可 以 参考 本 书 的 虚拟 机 章 
api 


4.11 学 习 Android 系 统 的 两 条 线索 


本 章 详细 讲解 了 操作 系统 的 一 系列 基础 知识 ， 包 括 计算 机 体系 的 结 
构 、 操 作 系统 的 概念 以 及 操作 系统 的 一 大 核心 ， 即 进程 间 通信 和 内 存 管 
理 机 制 。 另 外 ， 我 们 还 穿插 讲解 了 这 些 知识 点 在 Android 系 统 中 的 应 用 
与 扩展 〈 其 中 Android 的 进程 /线程 管理 和 进程 间 通 信 因 为 内 容 较 多 ， 将 
在 后 面 两 个 章节 进行 专门 讲解 ) 一 一 目的 就 是 为 读者 分 析 Android 的 各 
子 系统 原理 打下 坚实 的 理论 基础 。 


本 书 接 下 来 的 内 容 编 排 有 两 条 线索 。 

。 主线 : 操作 系统 的 体系 结构 、 硬 件 组 成 。 

o HR 在 主线 的 基础 上 ， 以 Android 系 统 的 5 层 框架 为 辅 ， 逐 一 解析 
各 层 框架 中 的 重要 元 素 ， 或 拾级 而 上 ， 或 深入 浅 出 ， 直 至 问题 的 最 
根源 处 。 


通过 以 上 解释 ， 读 者 应 该 可 以 想象 得 到 本 书 的 内 容 编排 其 实 是 立体 
的 ， 即 平面 《各 子 系统 ) + 高 度 《〈 每 个 元 素 在 5 层 结 构 上 都 有 所 体现 ) 的 
形式 一 一 更 为 重要 的 一 点 ， 这 同时 也 是 Android 系 统 的 设计 线索 。 


我 们 以 “进程 管理 ”为 例 ， 如 图 4-22 所 示 。 





进程 管理 


一 Android 五 层 结构 





全 图 4-22 本 书 内 容 的 编排 架构 


”希望 读者 无 论 是 阅读 本 书 ， 还 是 研究 Android 系 统 ， 都 能 牢 牢 把 握 
住 这 两 条 线索 一 一 相信 一 定 会 有 不 少 收获 。 


Android 进 程 /线程 和 程序 内 存 优化 


5.1 Android 进 程 和 线程 


进程 (Process) 是 程序 的 一 个 运行 实例 ， 以 区 别 于 “程序 ”这 一 
静态 的 概念 ; 而 线程 〈Thread) 则 是 CPU 调度 的 基本 单位 。 当 前 大 部 分 
的 操作 系统 都 支持 多 任务 运行 ， 这 一 特性 让 用 户 感到 计算 机 好 像 可 以 同 
oo 显然 在 只 有 一 个 CPU 核心 的 情况 下 ， 这 种 “同时 ”是 
一 种 假象 。 它 是 操作 系统 采用 分 时 的 方法 ， 为 正在 运行 的 多 个 任务 分 配 
合理 的 、 单独 的 CPU 时 间 片 来 实现 的 。 举 一 个 例子 ， 假 设 当前 系统 中 有 5 
个 任务 ， 如 果 采 用 “平均 分 配 ” 法 且 时 间 片 为 10ms 的 话 ， 那 么 各 个 任务 
每 隔 40ms 惑 能 被 执行 一 次 。 只 要 机 器 速度 够 快 ， 用 户 的 感觉 融 是 所 有 任 
务 都 在 同步 运行 。 


那么 ，Android 中 的 程序 和 进程 具体 是 什么 概念 呢 ? 

我 们 知道 ， 一 个 应 用 程序 的 主 入 口 一 般 都 是 main 函数 ， 这 基本 上 成 
了 程序 开发 的 一 种 规范 一 一 它 是 “一 切 事 物 的 起 源 ”。 而 main () 函数 的 
工作 也 是 千篇一律 的 。 总 结 如 下 : 

。 初始 化 

比如 Windows 环 境 下 通常 要 创建 窗口 、 向 系统 申请 资源 等 。 
。 进入 死 循环 

并 在 循环 中 人 处理 各 种 事件 ， 直 到 进程 退出 。 


这 种 模型 是 “以 事件 为 驱动 ”的 软件 系统 的 必然 结果 ， 因 此 几乎 存 
在 于 任何 操作 系统 和 编程 语言 中 。 


当然 ， 这 种 “一 切 从 零 开 始 ” 的 开发 模式 显然 太 过 费时 费力 。 为 了 
简化 开发 人 员 的 工作 ， 很 多 IDE (Integrated Development 
Environment) 工具 将 程序 编制 中 烦琐 而 又 一 成 不 变 的 部 分 抽取 出 来 ， 

以 向 导 模 板 的 方式 自动 完成 。 这 样 工程 人 员 就 可 以 把 精力 放 在 更 多 有 意 
义 的 事情 上 。 比 如 MFC 编 程 ， 它 提供 给 软件 人 员 的 入 口 就 摆脱 了 传统 的 
主 函 数 ， 而 是 强调 “图 形 控件 ”为 中 心 的 开发 模式 一 一 只 要 通过 简单 的 
操作 就 可 以 得 到 带 各 种 U1 界面 的 程序 框架 。Android 的 做 法 与 此 相似 。 
比如 可 以 通过 Ec1ipse 环 境 搭配 Android 专 用 的 ADT 工 具 ， 来 快速 生成 各 
种 应 用 程序 的 原型 ， 也 可 以 利用 1ayout 来 布局 自己 的 U1 界面 。 


IDE 也 带 来 了 一 些 炊 端 。 对 于 Android 应 用 开发 者 而 言 ， 通 常 面 对 的 
都 是 Activity、Service 等 组 件 ， 并 不 需要 特别 关心 进程 是 什么 。 因 而 
产生 了 一 些 误区 ， 如 部 分 研发 者 认为 系统 四 大 组 件 就 是 进程 的 载体 。 


这 些 组 件 确实 很 符合 我 们 对 进程 的 印象 。 不 过 很 可 惜 ， 它 们 不 能 算 
是 完整 的 进程 实例 ， 最 多 只 能 算是 进程 的 组 成 部 分 。 从 
AndroidMani fest. xml 中 也 可 以 得 到 一 点 提示 一 一 这 个 xm| 文 件 是 对 应 用 
程序 的 声明 和 摘 述 ， 如 范例 所 示 : 


<manifest xmlns:android="http://schemas.android.com/apk/res/andro 
android. launchperf"> 
<application android:label="Launch Performance"> 
<activity android:name="SimpleActivity" android:label="Simple Ac 
<intent-filter> 
<action android:name="android.intent.action.MAIN" /> 
<category android:name="android.intent.category.DEFAULT" /> 
</intent-filter> 
</activity> 





可 以 看 到 ，Activity 的 外 围 有 一 个 名 为 application> 的 标签 。 换 
句 话 说 ， 四 大 组 件 只 是 “application” 的 “零件 ”。 本 小 节 接 下 来 的 
内 容 中 将 通过 几 个 实验 来 让 读者 有 个 更 全 面 的 认识 ， 这 将 对 大 家 后 续 理 
解 ActivityManagerService，Binder 进 程 间 通信 产生 积极 的 意义 。 


实验 内 容 如 表 5-1 所 示 。 


表 5-1 进程 和 线程 实验 列表 


实验 内 容 


通过 Debug 一 个 普通 的 Activity 工 


ActivityThreadTest 程 ， 来 观 RE iz 4 F 时 的 进程 情 况 





通过 Debug 一 个 普通 的 Service 工 
ServiceThreadTest | 程 ， 来 观察 它 运 行 时 的 进程 情况 ， 
并 与 第 一 个 例子 进行 比较 





在 实验 1 的 package 包 中 新 增 一 个 
ActivityThreadTest, 上 Activity， 并 且 前 一 个 Activity 将 通过 
ActivityThreadTest2|lstartActivityO 启 动 后 者 。 观 察 进程 
的 变化 情况 


% 


在 实验 3 的 基础 上 ， 论 证 同一 个 包 中 
的 两 个 组 件 是 否 运行 于 相同 的 进程 
空间 中 





ActivityThreadTest, 
ActivityThreadTest2 








实验 1 


首先 我 们 在 Ec1ipse 中 通过 ADT 向 导 新 建 一 个 普通 的 Activity 工 程 ， 
命名 为 “ActivityThreadTest”， 如 图 5-1 所 示 。 


EF New Android App 


New Blank Activity 


Creates a new blank activity, with optional inner navigation, 








Activity Name @ | Activity ThreadTest 








Layout Name® activity_activity_thread_test 








Navigation Type® QMIS v 














Hierarchical Parent © | 网 











Title® Activity ThreadTest 








(The type of navigation to use for the activity 











全 图 5-1 新 创建 一 个 普通 的 Activity 工 程 


然后 在 自动 生成 的 源码 中 的 onCreate () 函数 入 口 处 打上 断 点 ， 如 下 
PIT ZR 


- @Override 
public void onCreate (Bundle savedInstanceState) { 
super.onCreate (savedInstanceState) 





那么 当 这 个 Activity 局 动 后 ， 将 会 生成 几 个 Thread 呢 〈 是 不 是 只 会 
有 一 个 主线 程 ) ? 如 图 5-2 所 示 。 


ActivityThreadTest [Android Application] 
3-6 DalvikvM[localhost:8616] 
由 :只 Thread [<1> main] (Suspended (breakpoint at line 11 in ActivityThreadTest)) 
p® Thread [<10> Binder_2] (Running) 
p® Thread [<9> Binder_1] (Running) 


全 图 5-2 一 个 Activity 程 序 所 包含 的 线程 数 


一 个 由 向 导 诞 生 的 、 没 有 任何 实际 功能 的 Activity 程 序 ， 居 然 启动 
了 这 么 多 线程 。 其 中 除了 有 我 们 最 熟悉 的 main thread〈 即 图 5-2 中 的 
Thread[<1> main]) 外 ， 还 有 两 个 Binder Thread. 


我 们 还 需要 从 这 个 实验 中 解决 一 个 重要 问题 ， 即 主线 程 到 底 是 怎么 
产生 的 。 很 简单 ， 看 下 函数 堆栈 束 知 道 了 ， 如 图 5-3 所 示 。 


E ActivityThreadTest [Android Application] 
-GÈ DalvikyM[localhost:8616] 
Sg Thread [<1> main] (Suspended (breakpoint at line 11 in ActivityThreadTest)) 
= ActivityThreadTest.onCreate(Bundle) line: 11 
= Activity ThreadTest( Activity), performCreate(Bundle) line: 5008 
= Instrumentation, callActivityOnCreate(Activity, Bundle) line: 1079 
= ActivityThread, performLaunchactivity( Activity Thread$ActivityClientRecord, Intent) line: 2023 
= ActivityThread,handleLaunchactivity( Activity Thread$ActivityClientRecord, Intent) line: 2084 
= ActivityThread, access$600(ActivityThread, ActivityThreadactivityClientRecord, Intent) line: 130 
Activity Thread$H, handleMessage(Message) line: 1195 
ActivityThread$H(Handler), dispatchMessage(Message) line: 99 
= Looper. loop() line: 137 
= ActivityThread,main(String[]) line: 4745 
= Method. invokeNative(Object, Object[], Class, Class[], Class, int, boolean) line: not available [native method] 
=} Method. invoke(Object, Object...) line: 511 
三 Zygotelnit$}MethodAndarasCaller.run() line: 786 
三 Zygotelnit.main(String[]) line: 553 
三 NativeStart.main(String[]) line: not available [native method] 


全 图 5-3 ERN BAIR 


可 以 清楚 地 看 到 ， 主 线程 由 zygotelnit 局 动 ， 经 由 一 系列 调用 后 最 
终 才 执行 Activity 本 身 的 onCreate () 函数 。 最 重要 的 是 ， 我 们 从 中 了 解 
到 Zygote 为 Activity 创 建 的 主线 程 是 ActivityThread: 


/*frameworks/base/core/java/android/app/ActivityThread. java*/ 

public static void main(String[] args) { 
SamplingProfilerIntegration.start(); 
CloseGuard.setEnabled(false); 


Process.setArgV0O("<pre-initialized>") ; 
Looper .prepareMainLooper(); /* 只 有 主线 程 才能 调用 这 个 函数 ， 普 通 ; 
请 参见 本 章 后 续 小 节 对 Looperl 





if (sMainThreadHandler == null) { 
sMainThreadHandler = new Handler()，/* 主 线程 对 应 的 Hand1 
} 


ActivityThread thread = new ActivityThread(); /* 这 个 main() 
因此 在 这 : 

thread.attach(false); /*Activity 是 有 界面 显示 的 ， 这 个 函数 将 与 Wi 

建立 联系 。 详 见 本 书 中 的 显示 系统 章节 */ 


Looper .loop(); /* 主 循环 开始 */ 
throw new RuntimeException("Main thread loop De 


行 到 这 里 ， 说 明 退 出 了 上 面 凶 








} 


那么 ， ie 时 候 创建 的 呢 ? 这 个 问题 留 
到 后 面 Binder 章 节 再 做 详细 解答 


实验 2 


Zygote 为 实验 1 中 的 应 用 程序 分 配 的 主线 程 是 ActivityThread。 这 
是 不 是 说 所 有 Android 应 用 程序 的 主线 程 ， 都 是 ActivityThread? 所 以 
这 个 实验 中 ， 我 们 将 使 用 男 外 一 个 组 件 一 Service 来 构建 应 用 程序 
(其 他 组 件 也 是 类 似 的 ， 大 家 可 以 试验 ) 。 另 外 ， 读 者 还 可 以 思 
下 ， 如 果 是 Servi ce 组 件 ， 它 局 动 时 是 否 也 会 有 这 么 多 线程 。 EE 
说 ， 上 面 看 到 的 Binder 线 程 是 不 是 Activity 应 用 进程 独 有 的 。 


我 们 局 动 一 个 Serv ice 程 序 来 揭 开 其 中 的 真相 。 服 务 本 身 并 没有 什 


么 实质 功能 ， 而 且 为 了 突出 重点 很 多 细节 部 分 都 省 略 了 ， 和 希望 读者 注意 
这 


过 人 a 


/*ServiceThreadTest 的 AndroidManifest.xml*/ 


<application android:label="@string/app_name" 
android:icon="@drawable/ic_launcher" 
android:theme="@style/AppTheme"> 
<service android:name=".ServiceThreadTest"> 
<intent-filter/> 
</service> 
</application> 


下 面 是 ServiceThreadTest 的 一 些 主要 函数 实现 : 


/*ServiceThreadTest.java*/ 
public class ServiceThreadTest extends Service 


{ 


























public void onCreate() 


{ 
t 


Log.i("ServiceThreadTest", "Service created") ;/* 将 断 点 设 


@Override 
public void onDestroy() 


{ 


super.onDestroy()j; 
Log.i("ServiceThreadTest", "Service destroyed"); 


@Override 
public void onStart(Intent intent, int startId) 


{ 


super.onStart(intent, startId); 
Log.i("ServiceThreadTest", "Service started"); 


这 样 一 个 简单 的 Servi ce 程序 就 构建 完成 了 。 接 下 来 通过 
startService () 来 局 动 这 个 服务 ， 并 将 断 点 设 在 onCreate () 中 ， 如 图 5- 
4 所 示 。 


= & Thread Grön [main] 


oÊ Thread [<1> main] (Suspended (breakpoint at line 20 in com. example. servicethreadtest. ServiceThreadTest)) 
E] QM does not provide monitor information) 





com, example. servicethreadtest. ServiceThreadTest. onCreate() line: 20 
android. app. ActivityThread. handleCreateService (android. app. ActivityThreadfCreateServiceData) line: 2363 

android, app. ActivityThread. access$1600 (android. app. ActivityThread, android. app. ActivityThread$CreateServiceData) line: 13 
android. app. ActivityThread$H. handleMessage (android. os. Message) line: 1277 

android. app. ActivityThread$H (android. os. Handler). dispatchMessage (android. os. Message) line: 99 

android. os. Looper. loop () line: 137 

android, app. ActivityThread. main (java. lang. String[]) line: 4745 

java. lang. reflect. Method. invokeNative (java.lang.Object, java. lang. Object[], java lang. Class, java. lang. Class[], java. lang 
java. lang. reflect. Method. invoke (java. lang Object, java.lang.Object...) line: 511 

com, android. internal. os. ZygoteInit$MethodAndArgsCaller. run() line: 786 

com, android, internal. os. ZygoteInit. main (java. lang. String[]) line: 553 

dalvik. system. NativeStart. main (java. lang. String[]) line: not available [native method] 


pÊ Thread [<10> Binder_2] (Running) 
pÊ Thread [<9> Binder_1] (Running) 


全 图 5-4 一 个 简单 的 Service 程 序 


根据 图 5-4 摘 述 的 内 容 ， 可 以 得 到 以 下 两 个 结论 。 





e Service 也 是 寄存 于 ActivityThread 之 中 的 ， 并 且 启 动 流程 和 Activity 基 
本 一 致 。 
e 局 动 Setvice 时 ， 也 同样 需要 两 个 Bindet 线 程 的 支持 。 


先 记 住 这 两 点 ， 后 期 我 们 在 源码 分 析 中 会 找到 根源 所 在 。 
实验 3 


上 面 已 经 证 明了 Activity 和 Service 应 用 程序 的 主线 程 都 是 
ActivityThread。 那 么 如 果 同 一 个 程序 包 中 有 两 个 Activity 《或 
Service) ， 它 们 是 什么 关系 ? 需要 有 多 少 线程 的 支持 ? 


这 个 实验 的 代码 同样 很 简单 ， 只 是 在 第 一 个 例子 的 基础 上 又 增加 了 
一 个 Activity， 命 名 为 ActivityThreadTest2: 


/*AndroidManifest.xml*/ 
<activity android:name=".ActivityThreadTest" /* 第 一 个 Activity*/ 
android: label="@string/title_activity_activity_thread_t 
<intent-filter> 
<action android:name="android.intent.action.MAIN" /> 
<category android:name="android.intent.category.LAUNCHER" /> 
</intent-filter> 
</activity> 
<activity android:name=".ActivityThreadTest2" /* 新 增 的 Activity*/ 
android: label="@string/title_activity_activity_thread_t 
</activity> 


在 具体 源码 的 实现 上 ， 我 们 在 ActivityThreadTest 中 通过 
startActivity 来 启动 第 二 个 Activity， 即 ActivityThreadTest2。 这 里 
有 一 个 知识 点 要 清楚 : 当 后 者 运行 起 来 后 ， 前 一 个 ActivityThreadTest 

没有 完全 退出 ， 而 是 被 压 入 Activity 栈 中 。 所 以 当 
ActivityThreadTest2 退 出 时 ， 它 可 以 被 重新 显示 出 来 : 
/*ActivityThreadTest.java*/ 
public void onCreate(Bundle savedInstanceState) 


{ 





super .onCreate(savedInstanceState) ; 
Log.i("ActivityThreadTesti", "We are in ThreadTesti"); 


程 的 














=) Thread 


setContentView(R.layout.activity_activity_thread_test); 
Intent intentThread2 = new Intent(this, ActivityThreadT 
startActivity(intentThread2) ;/* Aa —tActivity*/ 


J 


看 看 当 断 点 停 在 ActivityThreadTest2 的 onCreate () 国 数 中 时 ， 线 
分 布 情况 ， 如 下 所 示 。 






pÊ Thread [<11> Binder_3] (Running) 
p? Thread [<10> Binder_2] (Running) 
pÊ Thread [<9> Binder_1] (Running) 


其 中 揭示 了 以 下 几 个 现象 。 


当 ActivityThreadTest2 被 执行 时 ， 主 线程 始终 只 有 一 个 。 
此 时 ActivityThreadTest 暂 时 退出 了 运行 。 

Binder 线 程 数量 有 所 变化 ， 读 者 在 学 习 了 Binder 章 市 后 就 应 该 知道 
是 什么 原因 了 。 


天 着 这 些 感 观 印象 ， 我 们 进入 下 一 个 实验 。 
实验 4 
按照 Android 系 统 的 设计 : 


“By default, all components of the same application run 


in the same process and thread (called the "main" thread)” . 


上 面 这 句 话 还 可 以 理解 为 : 对 于 同一 个 AndroidManifest. xml PE 


义 的 四 大 组 件 ， 除 非 有 特别 声明 《参见 后 面 的 讲解 〉， 否 则 它们 都 运行 
于 同一 个 进程 中 并 且 均 由 主线 程 来 处 理事 件 ) 。 


那么 ， 如 何 证 明 呢 ? 
根据 操作 系统 的 基础 知识 ， 如 果 两 个 对 象 处 于 同一 个 进程 空间 中 ， 


那么 内 存 区 域 应 该 是 可 共享 访问 的 。 所 以 在 本 实验 中 ， 我 们 将 利用 这 个 
原理 来 论证 实验 3 中 先后 局 动 的 同一 个 包 里 的 两 个 Activity 是 否 共存 于 


一 个 进程 中 。 


先 让 ActivityThreadTest 拥 有 一 个 static 的 变量 ， 如 下 所 示 。 


/*ActivityThreadTest.java*/ 
public class ActivityThreadTest extends Activity 








{ 
static int <strong>TestForCoexist</strong> = -1; // 这 个 变量 一 了 
@Override 
public void onCreate(Bundle savedInstanceState) 
{ 
super .onCreate(savediInstanceState) ; 
Log.i("ActivityThreadTesti", "We are in ThreadTesti"); 
setContentView(R.layout.activity_activity_thread_test); 
Intent intentThread2 = new Intent(this, ActivityThreadT 
<strong>TestForCoexist</strong> = 2; /* 在 启动 第 二 个 Activi 
程 中 的 话 ，ActivityThreadTest 是 没有 办 
startActivity(intentThread2); 
} 
上 


ActivityThreadTest 中 有 一 个 静态 的 变量 TestForCoexist。 其 初始 
值 为 1， 并 在 Activity 局 动 后 (onCreate 中 ) 被 修改 为 2。 


接着 看 看 ActivityThreadTest2 的 源码 实现 : 


/*ActivityThreadTest2.java*/ 
public class ActivityThreadTest2 extends Activity 





{ 

@Override 

public void onCreate(Bundle savediInstanceState) 

{ 
super.onCreate(savedInstanceState); 
Log.i("ActivityThreadTest2", "We are in ThreadTest2"); 
setContentView(R.layout.activity_activity_thread_test); 
Log.i("ActivityThreadTest2", "TestForCoexist=" 

+ ActivityThreadTest.TestForCoexit); // KRA 
} 


我 们 运行 这 个 应 用 程序 ， 来 看 看 最 终 的 输出 ， 如 下 所 示 。 


PID TID lication Ta Text 
2236 2236 com. example. activitythreadtest Trace error opening trace file: No such fil 
2236 2236 com. example. activitythreadtest ActivityThreadTestl We are in ThreadTestl 
2236 2236  com.example.activitythreadtest ActivityThreadTest2 We are in ThreadTest2 
2236 2236 con. example.activitythreadtest ActivityThreadTest2  TestForCoexit=2 











这 就 足够 证 明 两 个 Act ivity 是 在 同一 个 进程 空间 中 了 。 理 由 如 下 : 


° 第 二 个 Activity 得 到 的 值 是 2。 假 设 二 者 不 是 在 相同 的 进程 
中 ，ActivityThreadTest2 只 是 单纯 地 import 了 
ActivityThreadTest， 那 么 它 得 到 的 值 应 该 是 初始 值 1; 而 
ActivityThreadTest 对 自己 进程 中 变量 的 修改 ， 对 于 其 他 进程 是 不 
可 见 的 。 


仔细 观察 ， 还 会 发 现 二 者 所 处 的 应 用 程序 PID 和 TID 值 是 相同 
的 。 这 都 证 明了 一 个 结论 ， 那 就 是 同一 个 程序 包 里 的 两 个 Activity 
默认 确实 都 运行 于 同一 个 进程 中 。 
当然 ，Android 还 提供 了 特殊 的 方式 让 不 是 同一 个 包 里 的 组 件 也 可 
以 运行 于 相同 的 进程 中 。 优 势 就 是 ， 它 们 可 以 非常 方便 地 进行 资源 共 
享 ， 而 不 用 经 过 费时 费力 的 进程 间 通 信 。 分 为 两 种 情况 : 


1. 针对 个 别 组 件 


可 以 在 AndroidManifest. xm| 文 件 中 的 activity>、<service>、 
<receiver> 和 《provider>〈 四 大 组 件 都 支持 ， 可 以 根据 需要 来 添加 ) 标 
签 中 加 入 android:process 属 性 来 表明 这 一 组 件 想 要 运行 在 哪个 进程 空 
间 中 。 


2. 针对 整个 程序 包 


可 以 直接 在 <application> 标 签 中 加 入 android:process 属 性 来 指明 
想 要 依存 的 进程 环境 。 


结论 


经 过 本 节 的 4 个 实验 ， 相 信 大 家 对 Android 中 的 进程 和 线程 已 经 有 了 
新 的 认识 。 下 面 再 来 做 个 小 结 。 


四 大 组 件 并 不 是 程序 GEE) 的 全 部 ,而 只 是 它 的 “零件 ”。 
应 用 程序 启动 后 ， 将 创建 ActivityThread 主 线程 。 

同一 个 包 中 的 组 件 将 运行 在 相同 的 进程 空间 中 。 

不 同 包 中 的 组 件 可 以 通过 一 定 的 方式 运行 在 一 个 进程 空间 中 。 
一 个 Activity 应 用 启动 后 至 少 会 有 3 个 线程 : 即 一 个 主线 程 和 两 个 
Bindet 线 程 。 


5.2 Handler，MessageQueue，Runnable 与 Looper 
相信 不 少 人 对 这 几 个 概念 “深恶痛绝 ”， 因 为 它们 “ 像 终 像 雨 又 像 


风 自我 感 党 都 很 熟识 ， 如 果 下 一 次 再 相遇 ， 却 又 陌生 得 很 。 这 
种 “ 陋 靴 授 痒 ”的 感觉 促使 我 们 必须 与 这 些 “ 顽 固 分 子 ” 来 个 彻底 的 决 





先 不 要 想 太 多 ， 任 头脑 中 随意 画 一 下 对 这 些 概 念 的 第 一 印象 ， 如 图 
5-5 所 示 。 


Event, Msg... 


Message: | Some 
Information 


~ 


MessageQueue: Loper. / ` 
o] 


SN 


Runnable: | Something 
can be run 





全 图 5-5 概念 初探 


图 5-5 是 我 们 对 这 几 个 概念 的 “感官 ”释义 ， 读 者 可 以 尝试 着 思考 
下 是 否 和 自己 所 想 的 基本 一 致 。 


那么， 如 果 把 这 些 概念 炉 合 在 一 起 ， 又 会 是 怎样 的 呢 ? 如 图 5-6 所 
示 。 


下 面 来 解释 图 5-6 的 含义 。 


e Runnable 和 Message 可 以 被 压 入 某 个 MessageQueue 中 ， 形 成 一 个 集合 





全 图 5-0 Runnable, Message, MessageQueue, LooperfeHandler 49 & A fj A 


注意 ， 一 般 情 况 下 某 种 类 型 的 MessageQueue 只 人 允许 保存 相同 类 型 的 


0bject。 图 中 我 们 只 是 为 了 叙述 方便 才 将 它们 混 放 在 同一 个 
MessageQueue 中 ， 实 际 源码 中 需要 先 对 Runnalbe 进 行 相应 转换 。 


。 Loopet 循 环 地 去 做 某 件 事 


比如 在 这 个 例子 中 ， 它 不 断 地 从 MessageQueue 中 取出 一 个 item， 然 
Rieter 如 此 循环 往复 。 假 如 队列 为 空 ， 那 么 它 会 j 
入 休 眼 。 


e Handler 是 真正 “处 理事 情 ” 的 地 方 


它 利用 自身 的 处 理 机 制 ， 对 传 入 的 各 种 0bject 进 行 相应 的 处 理 并 产 
生 最 终结 果 。 


用 一 句 话 来 概括 它们 ， 就 是 : 


Looper 不 断 获 取 MessageQueue 中 的 一 个 Message， 然 后 由 Handler 来 
处 理 。 


z 接 下 来 的 一 系列 分 析 无 论 多 复杂 ， 都 是 基于 这 句 话 展开 的 ， 和 希望 读 
牢记 。 


可 以 看 出 ， 上 面 的 几 个 对 象 是 缺 一 不 可 的 。 它 们 各 司 其 职 ， 很 像 一 
台 计 算 机 中 CPU 的 工作 方式 : 中 央 处 理 器 (Looper) 不 断 地 从 内 存 
(MessageQueue) 中 读 取 指令 (Message) ， 执 行 指令 (Handler) ， 最 
终 产生 结果 。 当 然 ， 到 目前 为 止 我 们 还 只 是 从 还 辑 的 层面 理 清 了 它们 的 
关系 ， 接 下 来 将 从 代码 的 角度 来 验证 这 些 假设 的 真实 可 靠 性 。 


1. Handler 
代码 路 径 : 
frameworks/base/core/ java/android/os/Handler. java 
读者 有 没有 注意 过 ，Handler 和 线程 Thread 是 什么 关系 : 
public class Handler 4.. 
final MessageQueue mQueue; 


final Looper mLooper; 
final Callback mCallback; 








本 小 节 中 几 个 主要 元 素 的 类 关系 如 图 5-7 所 示 。 


从 图 中 可 以 看 出 ，Hand1er 和 Thread 确 实 没 有 在 表象 上 产生 直接 的 
联系 。 但 是 因为 : 


D 每 个 Thread 只 对 应 一 个 Looper ; 

D 每 个 Looper 只 对 应 一 个 MessageQueue; 

@) 每 个 MessageQueue 中 有 N 个 Message; 

© 每 个 Message 中 最 多 指定 一 个 Handler 来 处 理事 件 。 
由 此 可 以 推断 出 ，Thread 和 Handler 是 一 对 多 的 关系 。 


Handler 是 应 用 开发 人 员 经 常会 使 用 到 的 一 个 类 。 概 言 之 ， 它 有 两 
个 方面 的 作用 。 


。 处 理 Message， 这 是 它 作 为 “处 理 者 ”的 本 职 所 在 。 
e 将 3 Message Jk A MessageQueue 中 。 








Handler 


~MessageQueue mQueue 


-Looper mL ooper 
-Callback mCallback 





全 图 5-7 Thread 和 Handlet 的 关系 图 
实现 第 一 个 功能 的 相应 函数 声明 如 下 : 


public void dispatchMessage(Message msg);// 对 Message 进 行 分 发 
public void handleMessage(Message msg);// 对 Message 进 行 处 理 


Looper 从 MessageQueue 中 取出 一 个 Message 后 ， 首 先 会 调用 
Handler. dispatchMessage 进 行 消息 派发 ;后 者 则 根据 具体 的 策略 来 将 
Message 分 发 给 相应 的 责任 人 。 默 认 情况 下 Handler 的 派发 流程 是 : 


Message.callback(Runnable 对 象 ) 是 否 为 空 


在 不 为 空 的 情况 下 ， 将 优先 通过 cal lback 来 处 理 。 














Handler. mCallback# THF 


在 不 为 空 的 情况 下 ， 调 用 mCal lback. handleMessage. 
如 果 前 两 个 对 象 都 不 存在 ， 才 调用 Handler .handleMessage 
由 此 可 见 ，Handler 的 扩展 子 类 可 以 通过 重 载 di spatchMessage 或 者 


handleMessage 来 改变 它 的 默认 行为 。 具 体 选 择 何 种 方式 取决 于 项 目的 
实际 需求 。 


Handler 的 第 二 个 功能 是 容易 引起 开发 人 员 困 惑 之 所 在 ， 因 为 这 样 
的 设计 形成 了 Handler MessageQueueMessageHandler 的 “循环 较 ” COL 
图 5-7) 。 


相应 的 功能 函数 声明 如 下 : 


1. Post 系列 : 
final boolean post(Runnable r); 
final boolean postAtTime(Runnable r, long uptimeMillis); 


2. Send 系 列 : 


final boolean sendEmptyMessage(int what); 

final boolean sendMessageAtFrontOfQueue(Message msg); 
boolean sendMessageAtTime(Message msg, long uptimeMillis); 
final boolean sendMessageDelayed(Message msg, long delayMill 


Post 和 Send 两 个 系列 的 共同 点 是 七 们 都 负责 将 茶 个 消息 压 入 
MessageQueue 中 ; 区 别 在 于 后 者 处 理 的 函数 参数 直接 是 Message， 而 
Post 则 需要 先 把 其 他 类 型 的 “零散 ”信息 转换 成 Message， 有 再 调用 Send 
系列 函数 来 执行 下 一 步 。 


我 们 只 挑选 第 一 个 Post 函 数 来 分 析 源 码 ， 其 逻辑 流程 如 图 5-8 所 


小 。 


Runnable 


Message 


sendMessageDelayed sendMessageAtTime 





A 5-8 post0 的 调用 逻辑 
public final boolean post(Runnable r) 


return sendMessageDelayed(<strong>getPostMessage(r)</stro 


因为 调用 者 提供 的 是 Runnab le 对 象 ，post 需 要 先 将 其 封装 成 一 个 
Message， 接 着 通过 对 应 的 send 卫 数 把 它 推送 到 MessageQueue 中 : 


private static Message getPostMessage(Runnable r) { 
Message m = Message.obtain(); /*Android 系 统 会 维护 一 个 全 局 的 Mt 
用 Message 时 ， 可 以 通过 obtain 直 接 获得 ， 而 不 是 自行 创建 。 这 样 的 设计 可 以 
m.callback = r;/* 将 Runnable 对 象 设置 为 Message 的 回调 函数 */ 
return m; 











} 


当 准 备 好 Message 后 ， 程 序 调用 sendMessageDelayed 来 执行 下 一 步 
IRIE. XNR 数 可 以 设 定 延 迟 多 长 时 间 后 再 发 送 消息 息 ， 其 内 部 又 通过 当 
前 时 间 + 延 时 时 长 计算 出 具体 是 在 哪个 时 间 点 (sendMessageAtTime) 发 
送 消息 。 


sendMessageAtTime 函 数 的 源码 如 下 ; 


public boolean sendMessageAtTime(Message msg, long uptimeMill 
MessageQueue queue = mQueue;/*Handler 对 应 的 消息 队列 */ 
if (queue == null) {/* 正 常情 况 下 ， 每 个 Thread 都 会 有 一 个 Message( 
除非 发 生 了 意外 queue 才 会 为 空 */ 











RuntimeException e = new RuntimeException( 

this + " sendMessageAtTime() called with no m 
Log.w( "Looper", e.getMessage(), e); 
return false; 


return enqueueMessage(queue, msg, uptimeMillis);/*}#ix‘+ i! 


i 


这 样 我 们 就 将 一 条 由 Runnab le 组 成 的 Message 通 过 Handler 成 功 地 压 
入 了 MessageQueue 中 。 读 者 可 能 会 觉得 很 奇怪 ， 最 终 仍 然 是 依靠 
Handler 来 处 理 这 一 消息 的 ， 为 什么 它 不 直接 执行 操作 ， 而 是 大 费 周 折 
地 先 把 Message 压 入 MessageQueue 中 ， 然 后 再 处 理 昵 ?这 其 实体 现 了 程 
序 设计 一 个 良好 的 习惯 ， 即 “有 序 性 ”。 


比如 某 天 你 和 朋友 去 健身 房 运动 ， 正 当 你 在 跑步 机 上 气喘 吁 吁 时 ， 
旁边 有 个 朋友 跟 你 说 : “哥们 ， 最 近 手 头 紧 ， 借 点 钱 伦 伦 。 ”那么 这 时 
候 你 就 有 两 个 选择 : 


。 马上 执行 


这 就 意味 着 你 要 从 跑步 机 上 下 来 ， 问 清 借 多 少 钱 ， 然 后 马上 打开 电 
脑 进 行 网 上 转账 。 


。 稍 后 执行 


上 面 的 方法 在 某 些 场合 下 是 有 用 且 必 需 的 比如 你 的 朋友 等 着 这 
笔 钱 急用 。 不 过 大 部 分 情况 下 “ 借 钱 ”这 种 事 并 不 是 刻不容缓 的 ， 因 而 
你 可 以 跟 朋 友 说 : “ 借 钱 没 问 题 ， 你 先 和 我 秘书 约 时 间 ， 改 天 我 们 具体 
谈 细节 。” 那 么 在 这 种 情况 下 ，“ 借 钱 事件 ”就 先 通 过 秘书 写 入 了 
MessageQueue 进 行 排 队 。 这 意味 着 你 并 不 需要 马上 从 跑步 机 上 下 来 ， 中 
断 愉 悦 的 健身 运动 。 


之 后 秘书 会 一 件 件 通知 你 MessageQueue 上 的 待 办 事宜 〈 当 然 你 也 可 
以 主动 问 秘书 ) ， 直 到 茶 个 Message 上 标明 “ 借 钱 事件 ”时 才 需 要 和 这 
位 朋友 做 进一步 商谈 。 在 一 些 场合 下 这 样 的 处 理 方 式 是 合情合理 的 。 比 
如 说 健身 房 一 小 时 花费 是 10 万 元 ， 而 你 朋友 只 借 100 元 ， 那 么 显然 “ 借 
钱 事件 ”优先 级 较 小 ， 排 队 处 理 就 是 必要 的 。 


下 面 以 框图 的 形式 来 加 深 大 家 的 理解 ， 如 图 5-9 所 示 。 





Give me momey 


Hz 
Case | cull None None of my business | None of my business | business 
m 


hi... 


Case 2 
(GTA) 有 一 个 借 钱 事宜 


好 的 ， 开 始 处 理 





全 图 5-9 ”两 种 消息 处 理 方 式 类 比 
2. MessageQueue 
源码 路 径 : frameworks/base/core/ java/android/os. 


MessageQueue 正 如 其 名 ， 是 一 个 消息 队列 ， 因 而 它 具 有 “队列 ”的 
所 有 常规 操作 。 包 括 : 


。 新 建 队 列 
由 其 构造 函数 和 本 地 方法 nativelnit 组 成 。 
其 中 ，nativelnit 会 在 本 地 创建 一 个 NativeMessageQueue 对 象 ， 然 
后 直接 赋 给 MessageQueue 中 的 成 员 变量 。 这 一 系列 的 操作 实际 上 都 是 通 
过 内 存 指针 进行 的 ， 详 见 本 书 JNI 章 节 的 描述 。 
。 元 素 入 队 
final boolean enqueueMessage (Message msg, long when) ; 
。 元 素 出 队 
final Message next () ; 


。 删除 元 素 


final void removeMessages (Handler h, int what, Object 
ob ject) ; 


final void removeMessages (Handler h, Runnable r, Object 
ob ject) ; 


e 销毁 队列 
和 创建 过 程 一 样 ， 也 是 通过 本 地 函数 nativeDestroy 来 销毁 一 个 


MessageQueue 。 


整个 MessageQueue 类 的 源码 数量 不 多 ， 也 并 不 难 理解 ， 这 里 先 不 做 
深入 分 析 。 接 下 来 涉及 MessageQueue 的 具体 应 用 场景 时 ， 我 们 再 有 重点 
地 进行 了 解 。 


3. Looper 
源码 路 径 : frameworks/base/core/ java/android/os. 


Looper 有 点 类 似 于 发 动机 一 一 正 是 由 于 它 的 推动 ，Handler 甚 至 整 
个 程序 才 成 为 活 源 之 水 ， 不 断 地 处 理 新 的 消息 。 


还 记得 前 面 我 们 将 Handler、MessageQueue、Looper 等 概念 迷 合 在 
一 起 组 合成 的 那个 “大 脑 印象 图 ” 吗 ? 实际 上 它们 在 Android 系 统 中 的 
源码 实现 和 这 个 图 是 比较 接近 的 ， 只 不 过 还 需要 做 一 点 修改 ， 如 图 5-10 
所 示 。 


MessageQueue: | 


| 


\ 
Looper \ Post Send 





全 图 5-10 更 贴近 Android 实 现 的 “印象 图 ” 
图 中 传达 了 一 个 信息 ， 即 Looper 中 包含 了 一 个 MessageQueue。 


此 ， 整 个 框图 就 只 剩 下 Looper 和 Handler 〈 还 有 多 数 情况 下 隐藏 得 很 深 
的 Thread) 之 间 的 关系 了 。 
应 用 程序 使 用 Looper 分 为 两 种 情况 。 
e 主线 程 (MainThread) 
也 就 是 ActivityThread， 下 一 小 节 有 详细 介绍 。 
。 普通 线程 
下 面 是 一 个 使 用 Looper 的 普通 线程 范例 ， 名 为 LooperThread: 
class LooperThread extends Thread { 
public Handler mHandler; 
public void run() { 
Looper .prepare( ) ;/* 一 句 简单 的 prepare， 究 竟 做 了 些 什么 工作 ? */ 
mHandler = new Handler() { 
public void handleMessage(Message msg) { 


..V/* 处 理 消 息 的 地 方 。 继 承 HandJler 的 子 类 通常 需要 修改 这 个 函数 */ 


} 
}; 
Looper .loop( );/* 进 入 主 循 环 */ 








这 段 代 码 在 Android 线 程 中 很 有 典型 意义 。 概 括 起 来 只 有 3 个 步骤 : 
(1) Looper 的 准备 工作 (prepare) ; 

(2) 创建 处 理 消息 的 handler; 

(3) Looper 开 始 运 作 〈loop) o 

虽然 代码 给 人 的 感觉 非常 简洁 ， 不 过 乍 一 看 仍 有 不 少 地 方 难以 理 


解 。 比 如 整个 过 程 我 们 都 没有 看 到 Looper 对 象 的 创建 ， 程 序 最 后 也 只 是 
调用 了 Looper. loop， 整 个 系统 的 循环 消息 处 理 机 制 就 “ 跑 ” 起 来 了 。 


另外 ，mHandler 是 如 何 保证 把 外 部 的 消息 投递 到 Looper 所 管理 的 
MessageQueue 中 的 ， 或 者 说 Looper 和 Handler 之 间 有 何 隐藏 的 联系 呢 ? 


下 面 结 合 上 面 那 段 LooperThread 代 码 ， 来 逐一 品味 Android 呈 现 出 
的 这 一 台 好 戏 。 


Be: 
Looper .prepare(); 


既然 要 使 用 Looper 类 的 函数 ， 那 么 LooperThread 中 肯定 就 得 执行 如 
下 操作 : 


import android.os.Looper; 
仔细 观察 ，Looper 里 有 个 非常 重要 的 成 员 变 量 : 
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<L 


这 是 一 个 静态 类 型 的 变量 ， 意 味 着 一 旦 import 了 Looper 后 ， 
sThreadLocal 就 已 经 存在 并 构建 完毕 。ThreadLoca1 对 象 是 一 种 特殊 的 
全 局 变量 ， 因 为 它 的 “全 局 ”性 只 限于 自己 所 在 的 线程 ， 而 外 办 所 有 线 
程 〈 即 便 是 同一 进程 ) 一 概 无 法 访问 到 它 。 这 从 侧面 告诉 我 们 ， 每 个 线 
程 的 Looper 都 是 独立 的 。 


可 以 猜想 下 ， 虽 然 Looper 提 供 了 若干 stat ic 的 成 员 函 数 以 方便 开发 
者 进行 调用 ， 但 是 它们 毕竟 只 代表 了 “公共 的 行为 ”， 其 内 部 一 定 还 需 
要 有 针对 每 个 Thread 的 特定 数据 存储 空间 。 举 个 例子 ，Looper 中 的 这 些 
stat ic 操作 有 点 类 似 于 银行 的 普通 业务 服务 窗口 ， 它 并 不 指定 任何 特定 
的 客户 ， 但 是 去 办 理 业 务 的 人 却 又 是 完全 可 以 区 分 开 来 的 。 为 什么 呢 ? 
因为 大 家 手头 都 会 持 有 反映 自己 身份 的 各 种 证 件 和 申请 表格 一 一 


sThreadLocal. 


因而 sThreadLocal 肯 定 会 创建 一 个 只 针对 当前 线程 的 Looper 及 其 他 
相关 的 数据 对 象 ， 而 且 这 个 操作 很 可 能 是 在 prepare (Looper 总 共 就 两 
行 ， 这 个 就 很 明显 了 ) 中 。 下 面 来 验证 一 下 是 不 是 这 样 的 : 

private static void prepare(boolean quitAllowed) { 


if (sThreadLocal.get() != null) {/*sThreadLocal.getik HW) 
这 个 判断 保证 一 个 Thread 只 会 有 一 





throw new RuntimeException("Only one Looper may be cre 


sThreadLocal.<strong>set</strong>(new Looper (quitAllowed ) 


} 


上 面 的 最 后 一 个 语句 验证 了 我 们 的 猜想 : sThreadlocal 的 确保 存 了 
一 个 新 创建 的 Looper 对 象 。 其 实 sThreadLoca1 这 个 名 字 取 和 导 不 太 好 ， 容 
易 引 起 误解 。 如 果 改 成 sThreadLocalData， 估 计 大 家 就 能 看 得 更 明白 些 
了 ; 而 且 它 还 是 一 个 模板 类 ， 这 就 说 明 它 并 不 存 信 特 定 类 型 的 数据 ， 而 
i Se “柜子 ”， 而 不 是 “ 鞋 
E” 


接 下 来 创建 一 个 Handler 对 象 ， 我 们 单独 将 它 提 取出 来 以 方便 阅 


读 。 
public Handler mHandler; 


mHandler = new Handler() { 
public void handleMessage(Message msg) {... 


} 
}; 


可 见 ，mHandler 是 LooperThread 的 成 员 变 量 ， 并 通过 new 操 作 创 建 
了 一 个 Handler 实 例 。 仅 从 这 两 行 代码 来 看 ， 并 没有 什么 蹊跷 的 地 方 。 
Handler 到 底 是 如 何 与 Looper 关 联 起 来 的 呢 ? RGR, ewe 
Z 


Handler 有 多 个 构造 函数 ， 比 如 : 


public Handler(); 

public Handler(Callback callback); 

public Handler(Looper looper); 

public Handler(Looper looper, Callback callback); 


之 所 以 有 这 么 多 构造 函数 ， 是 因为 Handler 有 如 下 内 部 变量 需要 初 
始 化 : 
final MessageQueue mQueue; 


final Looper mLooper; 
final Callback mCallback; 


我 们 就 以 LooperThread 例 子 中 采用 的 第 一 个 函数 来 讲解 下 它 的 构造 


ey : 


public Handler() { 
/*.. 省 上 略 部 分 代码 */ 
mLooper =Looper .myLooper();/* 还 是 通过 sThreadLocal.get 来 获取 当前 


<strong> mQueue </strong>= mLooper.mQueue; /*mQueue 是 Looper 与 H 
mCallback = null; 
} 


这 样 Handler 和 Looper，MessageQueue 就 联系 起 来 了 。 后 续 Handler 
执行 Post/Send 两 个 系列 的 函数 时 ， 会 将 消息 投递 到 mQueue 也 就 是 
mLooper. mQueue 中 。 一 旦 Looper 处理 到 这 一 消息 ， 它 又 会 从 中 调用 
Handler 来 进行 处 理 。 


到 目前 为 止 ， 代 码 就 只 剩 下 最 后 的 一 名 Looper. loop() 了 。 因 为 和 
ActivityThread 中 的 内 容 有 重 又 ， 我 们 统一 放 在 下 一 小 节 讲 解 。 





5.3 Ul 主线 程 


前 面 我 们 对 MessageQueue 等 几 个 重要 概念 进行 了 串讲 ， 相 信 读 者 已 
对 它们 有 了 一 定 的 认识 。 这 一 小 节 将 接着 上 面 还 没有 解决 的 问题 做 进 一 
步 分 析 。 因 为 LooperThread 例 子 只 是 一 个 “ 壳 ”， 也 就 是 说 它 让 我 们 非 
常 清楚 地 看 到 Android 典 型 线程 里 的 架构 ， 却 没有 真正 可 以 运行 的 “内 
容 ”。 所 以 要 回答 剩余 的 两 个 问题 ，ActivityThread 是 一 个 很 好 的 示 
例 。 从 名 称 上 看 ， 它 是 Activity 所 属 的 线程 ， 也 就 是 大 家 熟悉 的 U1 主线 


程 : 


ActivityThread 


/*frameworks/base/core/java/android/app/ActivityThread. java* 
public static void main(String[] args) { 


Looper .prepareMainLooper();// 和 前 面 的 LooperThread 不 同 
ActivityThread thread = new ActivityThread( ) ;// 新 建 一 个 Act: 
thread.attach(false); 
if (sMainThreadHandler == null) { 

sMainThreadHandler = thread.getHandler();//=Handler 





AsyncTask.init(); 
Looper .loop(); 
throw new RuntimeException("Main thread loop unexpectedly 


} 


如 果 注 意 比较 上 面 这 段 代 码 与 LooperThread. run () 的 实现 ， 就 可 以 
发 现 它 们 在 整体 架构 上 是 一 致 的 。 区 别 主要 体现 在 : 


e prepareMainLooper 和 prepare 


普通 线程 只 要 prepare 就 可 以 了 ， 而 主线 程 使 用 的 是 


prepareMainLooper。 
e Handlet 不 同 


普通 线程 生成 一 个 与 Looper 绑 定 的 Handler 对 象 就 行 ， 而 主线 程 是 
从 当前 线程 中 获取 的 Handler (thread. getHandler) 。 


(1) 那么 ，prepareMainLooper 有 什么 特殊 之 处 呢 ? 


/*frameworks/base/core/java/android/os/Looper .java*/ 


public static void prepareMainLooper() { 
prepare(false) ;//2¢ii prepare 
synchronized (Looper.class) { 
if (sMainLooper != null) { 
throw new IllegalStateException("The main Looper ha 


sMainLooper = myLooper(); 
} 
} 


可 以 看 到 ，prepareMainLooper 也 需要 用 到 prepare。 人 参数 false 表 
示 该 线程 不 允许 退出 ， 这 和 前 面 的 LooperThread 不 一 样 。 经 过 prepare 
m myLooper 就 可 以 得 到 一 个 本 地 线程 <ThreadLoca1> 的 Looper 对 象 ， 
ee sMainLooper 。 从 这 个 角度 来 讲 ， 主 线程 的 sMainLooper 其 
其 他 线程 的 Looper 对象 并 没有 本 质 的 区 别 。 


是 不 是 DE SAR EG BS? 图 5- 11 应 该 会 对 你 有 所 帮助 。 


prepare — prepareMamLooper  getMainLooper 


sMainLooper 


sThreadLocal sThreadLocal 


Looper 


线程 | EAF 线程 2 (普通 线程 


全 图 5-11 Loopet 揭 密 


这 个 图 描述 的 是 一 个 进程 和 它 内 部 两 个 线程 的 Looper 情 况 ， 其 中 线 
程 1 是 主线 程 ， 线 程 2 是 普通 线程 。 方 框 表示 它们 能 访问 的 范围 ， 如 线程 
1 AN 能 直接 访问 到 线程 2 中 的 Looper 对 象 ， 但 二 者 都 可 以 接触 到 进程 中 
的 各 元 素 。 


线程 1: 因为 是 Main Thread， 它 使 用 的 是 prepareMainLooper () ， 
这 个 函数 将 通过 prepare () 为 线程 1 生成 一 个 ThreadLocal 的 Looper 对 
象 ， 并 i 上 LsMainLooper 指 向 它 。 这 样 做 的 目的 就 是 其 他 线程 如 果 要 获取 
主线 程 的 Looper， 只 需 调用 getMainLooper © 即 可 。 


线程 2: 作为 普通 线程 ， 它 调用 的 是 prepare 0; 同时 也 生成 了 一 个 





ThreadLocal 的 Looper 对 象 ， 只 不 过 这 -1 个 对 象 只 能 在 线程 内 通过 
myLooper () 访问 。 当 然 ， 主 线程 内 部 也 可 以 通过 这 个 函数 访问 它 的 
Looper 对象。 


由 此 可 见 ，Google 玩 了 一 个 小 技巧 ， 从 而 巧妙 地 区 分 开 各 线程 的 
Looper， 并 珊 定 了 它们 的 访问 权限 。 


(2) sMainThreadHandler。 当 ActivityThread 对 象 创 建 时 ， 会 在 
内 部 同时 生成 一 个 继承 自 Handler 的 H 对 象 : 


final H mH = new H(); 


ActivityThread. main 中 调用 的 thread. getHandler 0 返回 的 就 是 
mH 。 


也 就 是 说 ，ActivityThread 提 供 了 一 个 “事件 管家 ”， 以 处 理 主线 
程 中 的 各 种 消息 。 


接 下 来 我 们 分 析 下 1oop 0 函数 ， 不 过 在 此 之 前 还 需要 了 解 点 基础 知 
识 。 本 章 的 开头 曾 简单 提 到 了 main 函 数 ， 它 的 经 典 模型 用 伪 代码 表示 
《以 Windows 下 的 图 形 程序 开发 为 例 ) 如 人 下: 


main() 


initialize(); // 初 始 化 操作 

CreateWindow( );// 创 建 窗口 

ShowWindow( );// 显 示 窗 口 

while(GetMessage()) // 不 断 地 获取 并 执行 消息 ， 直 至 收 到 退出 的 消息 
{ 


TranslateMessage(); // 对 消息 进行 必要 的 前 期 处 理 
DispatchMessage(); // 分 配 消息 给 相应 元 素 进行 处 理 

















这 个 模型 在 每 个 系统 平台 上 的 实现 细节 会 有 所 差异 ， 但 本 质 都 是 一 
样 的 。 概 括 起 来 重点 只 有 两 个 : 


。 创建 处 理 消 息 的 环境 ; 
。 循环 处 理 消 息 。 


也 就 是 说 ， 消 息 是 推动 整个 系统 动 起 来 的 基础 ， 即 便 操作 系统 本 身 


也 是 如 此 。 
有 了 这 个 前 提 ， 我 们 再 回 过 头 来 看 Android 中 Looper. loop 的 实现 : 


public static void loop() { 

final Looper me = myLooper();V/*1oop 函 数 也 是 静态 的 ， 所 以 它 只 能 访 让 
则 调用 sThreadLocal. get( ) 来 获取 与 之 匹 
就 是 取出 之 前 prepare 中 创建 的 那个 Looper 








final MessageQueue queue = me.mQueue;/* 正 如 我 们 之 前 所 说 ，Loope 


for (;;) {// 消 息 循环 开始 
Message msg = queue.next();/* 从 MessageQueue 中 取出 一 个 消息 ， 
if (msg == null) {/* 如 果 当 前 消息 队列 中 没有 msg， 说 明 线 程 要 退出 
伪 代 码 例 子 中 的 while 判 断 条 件 为 0， 这 样 就 会 结束 循 
return; /* 直 接 人 返回， 结束 程序 */ 














} 


msg.target.dispatchMessage(msg); /* 终 于 开始 分 派 消息 了 ， 重 心 
实 是 一 个 Handler， 所 以 dispatchMessage 最 终 调用 的 是 Hant 














msg .recycle();/* 消 息 处 理 完毕 ， 进 行 回收 */ 
} 
} 


可 以 看 到 ，loop () 函数 的 主要 工作 就 是 不 断 地 从 消息 队列 中 取出 需 
要 处 理 的 事件 ， 然 后 分 发 给 相应 的 责任 人 。 如 果 消 息 队 列 为 空 ， 它 很 可 
能 会 进入 睡眠 以 让 出 CPU 资源 。 而 在 具体 事件 的 处 理 过 程 中 ， 程 序 会 
post 新 的 事件 到 队列 中 。 另 外 ， 其 他 进程 也 可 能 投递 新 的 事件 到 这 个 队 
列 中 。APK 应 用 程序 就 是 不 停 地 执行 “处 理 队 列 事件 ”的 工作 ， 直 到 它 
退出 运行 ， 如 图 5-12 所 示 。 






ActivityThread 
Post 


全 图 5-12 基于 ActivityThread 的 进程 模型 


在 这 个 模型 图 中 ，ActivityThread 这 个 主线 程 从 消息 队列 中 取出 
Message 后 ， 调 用 它 对 应 的 Runnable. run 进 行 具体 的 事件 处 理 。 在 处 理 
的 过 程 中 ， 很 可 能 还 会 涉及 一 系列 其 他 类 的 调用 在 图 中 用 0bject1， 
0bject2 表 示 ) 。 而 且 它 们 可 能 还 会 向 主 循环 投递 新 的 事件 来 安排 后 续 
操作 。 另 外 ， 其 他 进程 也 同样 可 以 通过 1PC 机 制品 这 一 进程 的 主 循环 发 
送 新 事件 ， 如 触摸 事件 、 按 键 事件 等 。 这 就 是 APK 应 用 程序 能 “ 动 起 
来 ”的 根本 原因 。 


以 上 我 们 看 到 了 Looper. loop 的 处 理 流程 ， 从 而 知道 它 和 前 面 讨论 
的 Windows 消 息 处 理 机 制 是 类 似 的。 最 后 再 来 解决 一 个 问题 : 
MessageQueue 是 怎么 创建 出 来 的 ? 


Flin, Looper Pit AME——-MMessageQueue, HA ZIXHN 
IE? 


/* 以 下 代码 还 是 Looper . java 中 的 ， 不 过 只 提取 出 MessageQueue 相 关 的 部 分 */ 
final MessageQueue mQueue; /* 注 意 它 不 是 static 的 */ 
private Looper(boolean quitAllowed) { 
mQueue = new MessageQueue(quitAllowed); /*new s—~ Message 
也 就 是 说 ， 当 Looper 创 建 时 ， 消 息 队 列 也 





mRun = true; 
mThread = Thread,.currentThread();//Looper 与 当前 线程 建立 对 应 





} 


事实 证 明 Looper 内 部 的 确 管 理 了 一 个 MessageQueue， 它 将 作为 线程 
的 消息 存储 仓库 ， 配 合 Hand1er 、Looper 一 起 完成 一 系列 操作 。 


5.4 Thread 类 


首先 ， 提 醒 大 家 要 正确 地 区 分 线程 和 线程 类 的 概念 。 线 程 是 操作 系 
统 CPU 资 源 分 配 的 调度 单元 ， 属 于 抽象 的 范畴 ; 而 线程 类 的 本 质 仍 是 可 
执行 代码 ， 在 Java 中 当然 也 就 对 应 一 个 类 。 从 这 一 点 上 看 Thread 和 其 他 
类 并 没有 任何 区 别 ， 只 不 过 Thread 的 属性 和 万 法 仅 用 于 完成 “线程 管 
理 ” 这 个 任务 而 已 。 在 Android 系 统 中 ， 我 们 经 常 需要 启动 一 个 新 的 线 
程 ， 这 些 线程 大 多 从 Thread 这 个 类 继承 。 

5.4.1 Thread 类 的 内 部 原理 


/*libcore/libdvm/src/main/java/java/lang/Thread. java*/ 
public class Thread implements <strong>Runnable</strong> { 


可 以 看 到 ，Thread 实 现 了 Runnable， 也 就 是 说 线程 是 “可 执行 的 代 
但 ” : 


/*libcore/luni/src/main/java/java/lang/Runnable. java*/ 
public interface Runnable { 
public void run(); 


Runnable 是 一 个 抽象 接口 类 ， 唯 一 提供 的 方法 就 是 run () 。 一 般 情 
况 下 ， 我 们 是 这 样 使 用 Thread 的 : 
e 方法 1， 继 承 自 Thread 


定义 一 个 MyThread 继 承 自 Thread， 重 写 它 的 run 方 法 ， 然 后 调用 : 


MyThread thr = new MyThread(...); 
thr.start(); 


e 方法 2， 直 接 实现 Runnable 
Thread 的 关键 就 是 Runnable， 因 而 下 面 是 另 一 个 常见 用 法 : 


new Thread(Runnable target).start(); 


这 两 种 方法 最 终 都 通过 start 启 动 ， 它 会 间接 调用 上 面 的 run 实 现 。 
如 下 : 


public synchronized void start() { 
checkNotStarted(); 
hasBeenStarted = true; 
VMThread.<strong>create</strong>(this, stackSize);/*iX##HiEG! 


t 


在 此 之 前 ， 我 们 一 直 都 运行 在 “ 老 线 程 ” 中 ， 直 到 
VMThread. creat 示 上 真正 在 新 线程 中 运行 的 只 有 Run 方 法 ， 这 
解释 了 上 面 第 二 种 方法 通过 传 入 一 个 Runnable 也 可 以 奏 效 的 原因 。 从 这 
个 角度 来 理解 ，Thread 类 只 能 算是 一 个 中 介 ， 任 务 就 是 启动 一 个 线程 来 
运行 用 户 指定 的 Runnab le， 而 不 管 这 个 Runnyb le 是 否 属于 自身 ， 如 图 5- 
13 所 示 。 





Thread 


Runnable 


Runnable 





A 45-13 创建 Thread 的 两 种 方法 
线程 有 如 下 几 种 状态 : 


public enum State { 
NEW，// 线 程 已 经 创建 ， 但 还 没有 start 
RUNNABLE, // 处 于 可 运行 状态 ， 一 切 就 绪 
BLOCKED, // 处 于 阻塞 状态 ， 比 如 等 待 某 个 锁 的 释放 
WAITING, // 处 于 等 待 状态 
TIMED _WAITING, // 等 待 特定 的 时 间 














TERMINATED // 终 止 运行 
} 


5.4.2 Thread 休眠 和 唤醒 


休眠 、 等 待 以 及 激活 唤醒 是 多 线程 编程 非常 重要 的 环节 ， 也 是 令 很 
多 开发 人 员 难 以 理解 的 地 方 。 从 逻辑 上 来 讲 ， 线 程 无 非 就 是 运行 与 不 运 
行 两 种 可 能 。 但 是 因为 不 运行 的 原因 有 很 多 ， 运 行 的 条 件 也 不 少 ， 就 使 
得 我 们 不 得 不 对 它们 进行 细 化 ， 从 而 出 现 诸如 休眠 、 等 待 、 唤 醒 等 一 系 
列 掏 口 的 木 语 。 


可 以 先 来 想 一 想 线 程 中 与 此 相关 的 控制 方法 都 有 哪些 。 


至 少 有 : wait() 、notify() 、notifyAll() 、interrupt O., joinQ 
sleep) 。 


1. waitfenotify/notifyAll 


和 其 他 接口 方法 不 同 ， 这 3 个 函数 是 由 0bject 类 定义 的 一 一 也 就 意 
味 着 它们 是 任何 类 的 共有 “属性 ”。 那 么 ， 为 什么 要 这 么 设计 呢 ? 


官方 文档 对 wait 的 解释 是 : 
"Causes the calling thread to wait until another thread calls the 


我 们 以 WindowManagerService 中 的 一 段 代 码 作为 例子 来 讲解 : 


/*frameworks/base/services/java/com/android/server/SystemServer , j 
HandlerThread wmHandlerThread = new HandlerThread("WindowManager" 
wmHandlerThread.start();/* 启 动 线程 */ 
Handler wmHandler = new Handler (wmHandlerThread.getLooper ( 
wmHandlerThread 4 
wmHandler.post(new Runnable() { 
@Override 
public void run() { 
android.os.Process.setThreadPriority(android.os.Proc 
android.os.Process.setCanSelfBackground( false); 


} 
}); 
上 面 这 段 代 码 的 主要 目的 是 启动 一 个 HandlerThread， 并 由 


wmHandler 变 量 post 一 个 Runnable 给 它 ， 以 完成 线程 优先 级 等 参数 的 设 
置 。 当 SystemServer 调 用 WindowManagerService 的 main 国 数 时 ， 将 传 入 
wmHandler 人 参数 ， 具 体 如 下 所 示 : 


/*frameworks/base/services/java/com/android/server/wm/WindowManag 
public static WindowManagerService main(final Context context 
final DisplayManagerService dm, final InputMa 
final Handler uiHandler, final Handler wmHand 
final boolean haveInputMethods, final boolean showBootMs 
final WindowManagerService[] holder = new WindowManagerServ 
wmHandler.runWithScissors(new Runnable() { 
@Override 
public void run() { 
holder[0] = new WindowManagerService(context, pm, dm 
uiHandler, haveInputMethods, showBootMsgs, on 


} 
}, 9); 
return holder[0]; 
} 


这 个 main 函 数 的 核心 是 runWithScissors， 注 意 此 时 CPU 仍然 运行 于 
SystemServer 所 在 的 线程 中 。 根 据 代 码 注 释 ，runWithScissors 虽 然 是 
Handler. java 中 的 方法 ， 但 并 没有 在 SDK 中 提供 ; 而 且 有 意思 的 是 源码 
作者 自己 也 认为 函数 名 取得 不 是 很 恰当 ， 如 果 要 对 外 发 布 最 好 改 为 


runUnsafe () 。 


下 面 来 分 析 下 它 的 作用 : 
public final boolean runWithScissors(final Runnable r, long ti 


if (Looper.myLooper() == mLooper) {/* 当 前 线程 的 Looper 和 Handle 
r ,run();/* 是 的 话 直接 执行 Runnable， 返 回 true*/ 
return true; 


BlockingRunnable br = new <strong>BlockingRunnable</strong> 
return br.<strong>postAndwait</strong>(this, timeout); 


} 


前 面 说 过 ，runWithScissors 还 是 在 SystemServer 这 个 线程 运行 
的 ， 所 以 Looper. myLooper () != mLooper。 这 也 意味 着 程序 接 下 来 将 涉 
及 线程 等 待 ， 具 体 实现 在 postAndWait 中 ， 它 所 属 的 类 是 


BlockingRunnable: 


public boolean postAndWait(Handler handler, long timeout) { 
if ('!handler.post(this)) {/* 投 递 Runnable 到 Handler 所 属 的 Loo 
return false; 


} 
/* 如 果 成 功 投递 ， 接 下 来 就 需要 等 待 了 */ 
synchronized (this) { 
if (timeout > 0) {// 如 果 等 待 是 有 时 间 限 制 的 话 
, .// 在 本 场景 中 ，WindowManagerService 传 入 的 值 为 0O， 所 以 不 
} else {// 如 果 需 要 无 限期 等 待 的 话 
while (!mDone) { 
try { 
Wait( ) ;/* 走 过 于 山 万 水 后 ， 主 角 终 于 出 现 了 *V/ 
} catch (InterruptedException ex) { 











} 
t 


return true; 


Í 


WindowManagerService 中 关于 “线程 等 待 ”的 这 一 段 代 码 在 多 个 
Android 版 本 中 改动 很 大 。 个 人 认为 Android 4. 3 中 的 写法 并 不 是 太 好 ， 
可 读 性 也 一 般 ， 不 如 Android 4. 1 中 的 做 法 来 得 简洁 高 效 。 从 范 数 本 身 
的 注解 来 看 ， 开 发 人 员 似 乎 只 是 把 这 一 改动 当成 一 种 试验 ， 相 信和 后 续 版 
本 还 会 有 更 好 的 解决 方案 。 

函数 postAndWait 在 Handler 中 起 到 的 作用 就 是 “投递 并 等 待 ”。 所 
以 国 数 一 开头 就 把 一 个 Runnable 〈 即 this) post 到 handler 所 在 Looper 
中 去 ， 大 家 应 该 能 想到 这 个 handler 还 是 wmHandler 。 接 着 分 为 两 种 情 
况 : 


e timeout 大 于 0 
说 明 调 用 者 希望 是 有 条 件 限 制 的 等 待 ， 即 当 timeup 时 会 被 认为 出 
错 ， 直 接 返 回 。 这 样 做 的 目的 是 避免 异常 情况 下 的 “ 死 等 待 ”。 不 过 对 
于 WindowManagerService 这 类 系统 关键 组 件 ， 如 果 它 运行 不 正常 整个 设 
备 也 就 基本 上 “Game0ver” 了 。 所 以 这 里 的 传 值 是 0(， 即 下 一 种 情况 。 


e timeout 为 0 


无 限期 等 待 ， 直 到 有 人 来 唤醒 它 。 


让 线程 〈 即 SystemServer 的 运行 环境 ) 进入 等 待 所 用 的 是 wait () ， 
那么 唤醒 它 的 就 是 notify/notifyAl11。 后 者 是 在 什么 时 候 被 执行 的 呢 ? 


可 以 看 看 post 出 去 的 Runnable 究 竟 做 了 些 人 什么。 摘录 如 下 : 


public void run() { 
holder[Q] = new WindowManagerService(context, pm, dm 
uiHandler, haveInputMethods, showBootMsgs, onl 


} 


其 实 也 就 是 新 建 了 一 个 WindowManagerService 对 象 ， 并 没有 我 们 想 
要 的 notify。 大 家 可 以 想 一 想 还 有 哪些 地 方 比较 可 疑 。 


ue lockingRunnable。 这 个 对 象 在 执行 run 函 数 时 同时 会 
~~ | 7 RIE, 如 下 : 


public void run() { 
try { 
mTask.run(); 
} finally { 
synchronized (this) { 
mDone = true; 
notifyAll( ) ;// 通 知 所 有 正在 等 待 它 的 人 , “我 运行 成 功 了 ?7. 


} 
} 


其 实 WindowManagerService 的 作者 绕 了 个 大 圈 圈 ， 就 是 为 了 表达 图 
5-14 所 示 的 功能 。 
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当 某 个 线程 〈 比 如 SystemServer 所 在 线程 ) 调用 一 个 0bject (比如 
BlockingRunnable) 的 wait 万 法 时 ， 系 统 就 要 在 这 个 0bject 中 记录 这 个 
请 求 。 因 为 调用 者 很 可 能 不 止 一 个 ， 所 以 可 使 用 列表 〈 见 图 5-15 的 
waiting list) 的 形式 来 逐一 添加 它们 。 当 后 期 唤醒 条 件 〈 也 就 是 
BlockingRunnable 执 行 了 run 后 ) 满足 时 ，0bject 既 可 以 使 用 not ify 来 
唤醒 列表 中 的 一 个 等 待 线程 ， 也 可 以 通过 notifyAll 来 唤醒 列表 中 的 所 
有 线程 ， 如 图 5-15 所 示 。 


值得 特别 注意 的 是 ， 调 用 者 只 有 成 为 0bject 的 monitor 后 ， 才 能 调 
用 它 的 wait 方 法 。 而 成 为 一 个 对 象 的 monitor 有 以 下 3 种 途径 。 


© 执行 这 个 object 的 synchtonized 方 法 。 
e 执行 一 段 synchronized 代 码 ， 并 且 是 基于 这 个 object 做 的 同步 。 
e 如 果 object 是 Class 类 ， 可 以 执行 它 的 synchronized static 方 法 。 


Object 








Caller 


Caller 


全 图 5-15 wait, notify/notifyAl49 FM 


2. interrupt 


如 果 说 wait 是 一 种 “自愿 ”的 行为 ， 那 么 interrupt 就 是 “被 
迫 ” 的 了 。 调 用 一 个 线程 的 interrupt 的 目的 和 这 个 单词 的 字面 意思 一 
样 ， 就 是 “中 断 ” 它 的 执行 过 程 。 此 时 有 以 下 3 种 可 能 性 。 


e 如 果 Thtead 正 被 blocked 在 某 个 object 的 wait 上 ， 或 者 join0 ，sleep(0 方 
法 中 ， 那 么 会 被 唤醒 ， 中 断 状 态 会 被 清除 并 接收 到 
IntettuptedException 。 

e 402 Thread # blocked Æ InterruptibleChannel iy I/O W F, Ab A FBT 
状态 会 被 置 位 ， 并 接收 到 ClosedByInterruptException， 此 时 channel 
会 被 关闭 。 

e 如 果 Thtread 被 blocked 在 Selectot 中 ， 那 么 中 断 状 态 会 被 置 位 并 且 马 上 
返回 ， 不 会 收 到 任何 exception。 











3. join 
join 方法 有 如 下 几 个 原型 : 
public final void join () 


public final void join (long millis, int nanos); 
public final void join (long millis); 


比如 : 
Thread t1 = new Thread(new ThreadA()); 
Thread t2 = new Thread(new ThreadB()); 
ti.start(); 
t1.join(); 


t2.start(); 


它 希 望 达 到 的 目的 就 是 只 有 当 t1 线 程 执 行 完成 时 ， 我 们 才 接着 执行 
后 面 的 t2. start () 。 这 样 就 保证 了 两 个 线程 的 顺序 执行 。 而 带 有 时 间 参 
数 的 join 0 则 多 了 一 个 限制 ， 即 假如 在 规定 时 间 内 t1 没 有 执行 完成 ， 那 
么 我 们 也 会 继续 执行 后 面 的 语句 ， 以 防止 “无 限 等 待 ” 拖 垮 整个 程序 。 


4. sleep 


这 个 方法 是 工程 项 目 中 使 用 最 广泛 的 ， 它 和 wait 一 样 都 是 属于 “ 自 


愿 ” 的 行为 。 只 不 过 wait 是 等 待 某 个 object， 而 sleep 则 是 等 待 时 间 ， 
一 旦 设置 的 时 间 到 了 就 会 被 唤醒 。 原 型 如 下 : 


public static void sleep (long millis, int nanos); 
public static void sleep (long time); 


这 个 方法 比较 简单 ， 这 里 就 不 详细 讲解 了 。 
最 后 结合 这 两 小 节 的 内 容 给 出 Thread 状 态 的 迁移 ， 有 具体 如 图 5-16 所 
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A 5-16 Thread 状态 迁移 图 


5.4.3 Thread 实例 


为 了 加 深 大 家 对 Thread 的 理解 ， 这 一 小 节 讲 解 实 际 项 目 工程 中 的 一 
个 典型 范例 。 


其 目标 是 使 用 SeekBar ( 当 用 户 的 选择 有 变化 后 ， 会 回调 
onProgressChanged:e MM) 来 控制 系统 的 音效 〈 比 如 调整 高 音 部 分 增 
fm, S@f12~+12db) 。 要 求 UI 界 面 的 响应 流畅 (要 求 1) ， 并 且 要 能 实 
时 反映 出 音效 的 变化 (要 求 2) ， 另 外 系统 必须 稳定 〈 要 求 3) 。 


假设 有 如 下 几 个 前 提 。 


。 向 系统 发 送 音效 调整 的 命令 是 一 个 费时 的 操作 (前 提 1) 。 

。 频繁 向 系统 发 送 调 整 命令 将 导致 死机 (前提 2) 。 

。 用户 的 操作 是 随意 没有 规律 的 。 有 的 用 户 很 可 能 会 迅速 拉动 SeekBar 
的 滑 杆 ， 也 可 能 慢 慢 拖 动 ， 或 者 快速 来 回 拖 动 ， 这 都 是 未 知 的 。 但 
我 们 必须 保证 UI 界 面 不 出 现 延 沾 现 象 〈 前 提 3) 。 


对 于 要 求 1， 我 们 首先 可 以 想到 的 是 ， 将 发 送 命令 这 一 费时 的 操作 
人 这 样 就 不 会 影响 主线 程 刷 新 U1， 保 证 了 青 


而 根据 上 述 的 前 提 描 述 ， 要 求 2 和 要 求 3 是 有 矛盾 的 一 一 如 果 我 们 需 

要 实时 听 到 音效 的 变化 ， 则 意味 着 SeekBar 在 变化 过 程 中 的 数值 应 该 不 

断 地 发 送 给 系统 ， 而 不 是 等 到 用 户 松 开 手 后 才 发 送 最 终 调整 值 。 但 如 果 

按照 这 样 的 设计 ， 那 么 当 用 户 的 操作 非常 迅速 或 者 不 俘 地 来 回 拖 动 时 ， 

ea 这 将 导致 系统 死机 ， 从 而 违 
背 了 要 求 3。 


另外 ， 既 然 向 系统 发 送 命令 是 非常 耗 时 的 ， 那 么 频繁 地 发 送 命令 也 
是 没有 意义 的 。 举 个 例子 ， 用 户 在 1 秒 以 内 一 下 子 从 12 拖 到 了 +12 的 位 
置 ， 从 而 产生 了 24 个 调整 值 〈 当 然 ，SeekBar 实 际 上 可 能 不 会 产生 这 么 
多 次 onProgressChanged， 这 里 假设 会 有 24 个 ) ， 而 发 送 每 个 调整 值 则 
需要 500ms 。 换 句 话说 ， 即 便 系统 能 稳定 快速 地 人 处理 调整 请 求 ， 也 需要 
等 到 用 户 松 开 手 后 的 0. 5*241=11 秒 后 才能 逐步 听 到 音效 的 变化 ， 这 显然 
没有 达到 我 们 的 设计 目标 。 





所 以 解决 的 办 法 就 是 既 要 向 系统 不 断 地 发 送 调整 值 ， 以 保证 用 户 能 
实时 听 到 声音 变化 ; 而 且 又 不 能 过 于 频繁 ， 以 保证 系统 稳定 和 UI 珊 面 的 


流畅 。 
那么 ， 如 何 做 到 呢 ? 


一 种 理论 的 办 法 就 是 计算 用 户 在 单位 时 间 内 产生 的 调整 次 数 ， 然 后 
进行 适当 取舍 。 缺 点 是 明显 的 一 一 程序 很 难 弄 定 什么 样 的 情况 是 “ 频 
繁 ”， 而 且 程序 的 逻辑 会 由 此 变 得 异常 复杂 ， 不 利于 维护 和 升级 。 


再 来 想 息 有 没有 其 他 简单 的 方法 。 


当局 动 一 个 新 线程 用 于 处 理 调 整 请 求 时 ， 显 然 需要 把 这 些 请 求 先 放 
入 消息 队列 中 再 排队 处 理 。 根 据 前 面 的 假设 ， 如 果 用 户 在 1 秒 内 产生 了 
24 个 调整 值 ， 那 么 队列 中 的 数量 将 陆续 增加 ， 直 到 用 户 操作 结束 〈 因 为 
500ms 才 能 处 理 一 个 ) 。 这 些 请 求 值 实际 上 是 有 优先 级 的 ， 即 后 产生 的 
调整 值 更 贴近 于 用 户 想 得 到 的 效果 。 根 据 这 一 思想 ， 我 们 可 以 适当 控制 
消息 队列 中 的 元 素数 量 。 比 如 : 


。 当 产 生 一 个 新 的 调整 值 时 ， 先 清空 消息 队列 ， 然 后 才 把 请 求 入 队 ; 
。 当 产 生 一 个 新 的 调整 值 时 ， 先 判断 消息 队列 的 数量 ， 根 据 实 际 情况 
删除 部 分 消息 ， 然 后 才 把 请 求 入 队 。 


另外 ， 采 用 这 种 方式 可 以 保证 最 后 一 个 入 队 的 请 求 总 是 可 以 被 处 理 
(没有 后 续 的 请 求 能 清除 它 ) 。 这 也 就 意味 着 用 户 最 终 选择 的 音效 值 是 
可 以 体现 出 来 的 。 


参考 代码 如 下 (BusinessThread) : 


private Thread mBusinessThread = null; 

private boolean mBusinessThreadStarted = false; 

private BusinessThreadHandler mBusinessThreadHandler = null; 
private void startBusinessThread() 


if (true == mBusinessThreadStarted) 

return; 
else 

mBusinessThreadStarted = true; 
mBusinessThread = new Thread(new Runnable( ) 


{ 


@Override 
public void run() 


{ 
Looper.prepare(); 
mBusinessThreadHandler = new BusinessThreadHandler 
Looper .loop(); 

} 


}); 


mBusinessThread.start(); 


BusinessThread 重 写 了 run 方 法 ， 并 使 用 Looper. preparei 
Looper. 1oop 来 不 断 处 理 调 整 请 求 。 这 些 请 求 是 通过 
mBus inessThreadHandler& 33¢lBusineseThread fi 肖 息 队列 中 的 。 具 体 
如 下 所 示 : 


publicclass BusinessThreadHandler extendsHandler 


publicboolean sendMessage(int what, int argi, int arg2)// 重 写 
{ 











removeMessages(what); // 清 理 消息 队列 中 未 处 理 的 请 求 
returnsuper.sendMessage(obtainMessage(what, argi, arg2) 








publicvoid handleMessage(Message msg) 
switch(msg.what ) 


caseMSG_CODE: 
// 在 这 里 执行 耗 时 操作 
break; 

default: 
break; 

} 


}; 


在 sendMessage 方 法 中 ， 首 先 清除 了 消息 队列 中 还 未 被 处 理 的 请 求 
《可 以 根据 实际 需求 来 调整 这 里 的 操作 ) 。 这 样 一 方面 降低 了 程序 向 系 
统 发 送 请 求 的 频率 ， 加 快 了 响应 速度 和 UI 珊 面 的 流畅 性 ; 另 一 方面 也 保 
证 了 BusinessThreadHandler 下 次 取 到 的 是 优先 级 较 高 的 调整 请 求 值 
一 一 最 重要 的 是 ， 用 户 能 实时 听 到 音效 的 变化 。 


这 样 我 们 就 通过 Thread+Handler+Looper 的 组 合 解决 了 工程 项 目 中 


的 


alt 


这 个 典型 问题 。 


个 例 为 了 说明 问题 ， 简 化 了 一 些 控 制 操作 ， 读 者 可 以 根据 需要 补充 


5.5 Android 应 用 程序 如 何 利用 CPU 的 多 核 处 理 能 


2012 年 的 时 候 ，lntel 曾 发 表 过 非 官方 声明 ， 称 Android 系 统 还 没 为 
CPU 的 多 核能 力 做 好 充足 的 准备 一 一 多 核 所 带 来 的 “ 卡 ” 甚 至 多 
于 “ 利 ”。 这 种 情况 显然 不 能 被 Gboogle 所 容忍 ， 并 在 随后 的 版 本 中 不 断 
被 优化 和 改善 ， 使 得 Android 系 统 不 再 为 此 而 广 受 诉 病 。 


那么 ， 开 发 人 员 如 何 主动 去 利用 CPU 的 多 核能 力 ， 从 而 有 效 提高 自 
身 应 用 程序 的 性 能 呢 ? 


答案 就 是 针对 Java-Based 的 并 行 编程 技术 。 听 起 来 有 点 复杂 ， 但 实 
际 上 相信 大 部 分 人 都 已 经 接触 过 了 。 第 一 种 方式 就 是 前 面 小 节 我 们 所 提 
到 的 Java 线 程 ， 它 在 Android 系 统 中 同样 适用 。 使 用 上 也 和 Java 没 有 太 
多 区 别 ， 我 们 只 要 继承 Thread 类 或 者 实现 Runnable 接 口 就 可 以 了 。 不 过 
采用 这 类 方法 有 一 点 比较 麻烦 的 地 方 ， 就 是 和 主线 程 的 通信 和 需要 通过 
Message Queue 一 一 因为 只 有 主线 程 才 能 处 理 U1 相 关 的 事务 ， 包 括 UI 家 
面 更 新 。 


男 一 种 可 选 的 并 行 编程 方法 是 AsyncTask， 它 是 Android 开 发 的 专门 
用 于 简化 多 线程 实现 的 Helper 类 型 的 类 。 优 点 很 上 明显， 就 是 可 以 不 需要 
通过 繁琐 的 Looper 、Hand1er 等 机 制 来 与 U1 线程 通信 。Android 官 方 对 其 
的 描述 是 : 





“AsyncTask enables proper and easy use of the UI thread. 
This class allows to perform background operations and publish 
results on the Ul thread without having to manipulate threads 
and/or handlers” àù 


AsyncTask 在 设计 时 的 目标 是 针对 比较 短 时 间 的 后 台 操 作 ， 换 句 话 
说 ， 如 果 你 需要 在 后 台 长 时 间 执 行 某 些 事务 的 话 ， 我 们 建议 你 还 是 使 用 
java. util. concurrent 包 所 提供 的 Executor 、ThreadPoo1Executor 和 
FutureTask 等 其 它 AP1 接 口 。 


第 三 种 比较 常用 的 “工作 线程 ”实现 模型 是 IntentService。 大 家 
应 该 已 经 猜 到 了 ， 它 是 四 大 组 件 之 一 的 Service 的 子 类 ， 区 别 就 在 于 
IntentService 可 以 帮助 开发 人 员 以 相当 简洁 的 语句 〈 只 需要 实现 
onHandlelntent 接 口 ) 来 对 Servi ce 进行 后 台 处 理 ， 而 无 需 理会 其 中 各 


种 琐 届 的 中 间 过 程 。 


总 的 来 说 ， 在 Android 系 统 中 通过 多 线程 编程 模型 来 利用 CPU 的 多 核 
能 力 的 途径 还 是 比较 多 的 。 除 上 本 小 节 例 举 的 几 个 方式 外 ， 大 家 还 可 以 
a A a a E 
需求 场景 中 。 


5.6 Android 应 用 程序 的 典型 启动 流程 


从 上 面 小 节 的 分 析 中 ， 我 们 了 解 到 Android 系 统 中 一 个 应 用 程序 的 
主体 是 由 ActivityThread 构 成 的 。 不 过 这 里 面 还 涉及 很 多 细节 ， 如 
ActivityThread 是 由 谁 来 创建 的 ， 又 是 在 什么 时 间 创 建 的 呢 ? 它 和 系统 
服务 程序 ， 如 ActivityManagerService，WindowManagerService 之 间 又 
seh a 了 解 这 些 知识 有 助 于 我 们 分 析 Android 系 统 中 应 用 程序 框 

Wt 


由 于 Android 系 统 是 基于 Linux 的 ， 原 则 上 说 它 的 应 用 程序 并 不 只 是 
APK 一 种 类 型 。 换 名 话说， 所 有 Linux 支 持 的 应 用 程序 都 可 以 通过 一 定 方 
式 运 行 在 Android 系 统 上 〈 比 如 一 些 系统 级 应 用 程序 就 是 以 这 种 方式 存 
在 的 ， 后 面 章节 我 们 会 逐步 接触 到 ) 。 为 了 叙述 的 统一 ， 在 没有 特别 说 
明 的 情况 下 ， 我 们 所 指 的 应 用 程序 都 是 APK 类 型 的 应 用 程序 。 它 们 通常 
由 两 种 方式 在 系统 中 被 启动 。 


e 在 Launcher 中 点 击 相 应 的 应 用 程序 图 标 启动 
这 种 局 动 方式 大 多 是 由 用 户 发 起 的 。 默 认 情 况 下 APK 应 用 程序 在 
Launcher 主 表面 上 会 有 一 个 图 标 ， 通 过 点 击 它 可 以 局 动 这 个 应 用 程序 指 
定 的 一 个 Activity。 


e 通过 stattActivity 启动 


这 种 启动 方式 通常 存在 于 源码 内 部 。 比 如 在 Activity1 中 通过 
startActivity 来 启动 Activity2。 


这 两 种 启动 方式 的 流程 基本 上 是 一 致 的 ， RRRS 调用 
ActivityManagerService 的 startActivity 来 完成 。 整 个 调用 流程 的 描 
述 如 图 5-17 所 示 。 


startActivily 


| | | | 
| | | 

Application Thread schedule | i 
| PauscActivity | | | 
| | | | 
| | | 
| | | | 
| | 了 | 了 | 
| | Activity Thread.handlePauseActivity | 
| | | | 
| | | | 
| | | 
| | | remove | 
i 

| activity Paused | | l 
| | | | 
| | | 

| | | | 
| | | | 
| completePauseLocked | | | 
| | | | 
| | | | 
| | | | 
| | | | 
| Process.start( “android.app.ActivityThread” ... | 
| | | 
| | | 
| attachA pplication | 
| 

| | | 
| | | 
| | | 
rcalStartActivityLockcd l l 
| | | 
| | 

| | 

| | 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 
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performLaunchActivity 


Activity.attach 


Activity.onCreate 


w 
Q 
| 


全 图 5-17 应 用 程序 的 典型 启动 流程 


无 论 以 什么 方式 发 起 一 个 Activity 的 启动 流程 ， 最 终 都 会 调用 到 
AMS 的 startActivity 函 数 。 在 AMS 真 正 启 动 一 个 Activity 之 前 ， 需 要 经 
过 众多 烦琐 的 判断 和 准备 工作 一 一 这 些 工作 在 AMS 内 部 都 由 一 系列 以 
startActivity 开 头 的 函数 来 进行 逐步 处 理 。 关 于 这 部 分 内 容 ， 我 们 将 
在 ActivityManagerService 章 节 进 行 详细 的 分 析 ， 这 里 暂时 跳 过 。 


如 果 一 切 顺 利 ，AMS 才 会 最 终 尝 试 启动 指定 的 Activity。 如 果 读 者 
写 过 APK 应 用 程序 ， 应 该 清楚 Activity 的 生命 周期 中 除了 onCreate， 
onResume 外 ， 还 有 onPause，onStop 等 。 其 中 的 onPause 就 是 在 此 时 被 调 
用 的 因为 Android 系 统 规 定 ， 在 新 的 Activity 启 动 前 ， 原 先 处 于 
resumed 状 态 的 Activity 会 被 pause。 这 种 管理 方式 相 比 于 Windows 的 多 
窗口 系统 简单 很 多 ， 同 时 也 完全 可 以 满足 移动 设备 的 一 般 需 求 。 将 一 个 
Activity 置 为 pause 主 要 是 通过 此 Act ivity 所 属 进 程 的 
ApplicationThread. schedulePauseActivity 方 法 来 完成 的 。 
ApplicationThread 是 应 用 程序 进程 提供 给 AMS 的 一 个 Binder 通 道 ， 后 面 
还 会 讲 到 。 


当 收 到 pause 请 求 后 ， 此 进程 的 ActivityThread 主 线程 将 会 做 进 一 
步 处 理 。 除 了 我 们 熟悉 的 调用 Activity. onPause () 等 方法 外 ， 它 还 需要 
通知 WindowManagerService 这 一 变化 因为 用 户 珊 面 也 需要 发 生 改 
变 。 做 完 这 些 以 后 ， 进 程 通 知 AMS 它 的 pause 请 求 已 经 执行 完成 ， 从 而 使 
得 AMS 可 以 接着 完成 之 前 的 startActivity 操 作 。 


假如 即将 启动 的 Activity 所 属 的 进程 并 不 存在 ， 那 么 MMS 还 需要 先 
把 它 启 动 起 来 。 这 一 步 由 Process. start 实 现 ， 它 的 第 一 个 入 参 
Æ “android. app. ActivityThread”， 也 就 是 我 们 上 一 小 节 讨 论 的 应 用 
程序 的 主线 程 ， 然 后 调用 它 的 main 函 数 。 


和 前 面 一 样 ，ActivityThread 启 动 并 做 好 相应 初始 化 工作 后 ， 需 要 
调用 attachApplication 来 通知 AMS， 后 者 才能 继续 执行 未 完成 的 
startActivity 流 程 。 具 体 而 言 ，AMS 通 过 ApplicationThread. 
scheduleLaunchActivity 请 求 应 用 程序 来 启动 一 个 指定 的 Activity。 之 
后 的 一 系列 工作 就 要 依靠 应 用 进程 自己 来 完成 ， 如 Activity 创 建 
Window, ViewRootImp|, #alAView Tree 等 。 关 于 Activity 中 的 详细 显 
示 过 程 ， 我 们 将 在 本 书 显示 系统 章节 分 两 部 分 前 述 一 一 第 一 部 分 以 View 











和 ViewRoot1mp1 为 核心 ;第 二 部 分 则 以 WindowManagerService 为 核心 。 


在 进入 后 面 章节 的 学 习 前 ， 建议 读者 先 熟 悉 本 小 节 所 述 的 
PE ar 个 调用 流程 。 实 际 上 ， 这 一 看 似 简 单 的 启动 过 程 ， 
基本 涵盖 了 Android 系 统 中 的 方方面面 ， 如 AMS、WMS、 
ActivityThread、Activity、ViewRoot、SurfaceFlinger、Window 以 及 
Binder 通 信 等 ， 因 而 可 以 作为 我 们 深入 分 析 系 统 的 一 条 线索 。 


5.7 Android 程序 的 内 存 管 理 与 优化 


相对 于 传统 宋 面 型 的 应 用 程序 ， 移 动 终端 设备 在 内 存 、CPU 和 电池 
等 关键 资源 上 对 应 用 程序 提出 了 更 严 苛 的 要 求 。 其 中 内 存 管理 与 优化 的 
好 坏 ， ee 因而 是 所 有 开发 人 员 不 容 忽 
视 的 核心 环 市 


5.7.1 Android 系 统 对 内 存 使 用 的 限制 


Android 是 一 个 支持 多 任务 运行 的 系统 ， 这 意味 着 每 个 程序 所 占用 
的 内 存 越 小 ， 理 论 上 可 以 同时 运行 的 进程 REE 随 着 硬件 设备 的 
不 断 升级 换代 ，Android 虚 拟 机 系统 允许 单个 进程 所 能 使 用 的 Heap Size 
的 上 限 也 在 呈现 上 升 趋 势 。 具 体 来 说 ， 这 个 值 是 由 特定 的 系统 属 
性 “dalvik. vm. heapsize” 决 定 的 。 壁 如 Android 5. 0 版 本 中 的 堆 大 小 


xe: 


root@generic_x86:/ # getpropigrep dalvik.um.heapsize 





C[dalvik.um.heapsizel: [48m] 


一 旦 进程 申请 的 heap 空 间 超过 系统 的 阀 值 ， 就 会 引发 
OutOfMemory E 的 错误 。 不 过 发 生 这 种 情况 通常 只 能 说 明 个 体 情况 
的 “违规 ”， 而 不 是 设备 真 地 已 经 没有 任何 可 用 的 内 存 空间 了 。 


在 Android 系 统 中 查看 某 个 进程 中 的 内 存 使 用 情况 可 以 使 用 dumpsys 
命令 ， 如 图 5-18 是 针对 Calendar 的 一 个 范例 。 


root@generic_x86:/ # dumpsys meminfo 2668 
Applications Memory Usage 《kB>: 
ptime: 661262 Realtime: 661262 


MEMINFO in pid 2068 [com.android.calendar] ** 
Private Swapped 


Native Heap 
Dalvik Heap 
Dalvik Other 
Stack 

Other dey 
-SO mmap 
-apk mmap 
-dex mmap 
code mmap 


~J 
NM A 


image mmap 


Other mmap 


Unknown 


TOTAL 
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全 图 5-18 范例 


可 以 看 到 Heap 区 域 分 为 两 类 ， 即 Native 和 Dalvik。 前 者 是 指 本 地 代 
码 的 情况 ， 而 Dalvik Heap 特 指 虚 拟 机 中 的 堆 分 配 。 


值得 一 提 的 是 ，Android 系 统 允 许 开发 人 员 在 AndroidManifest. xml 
的 <application> 中 将 android:largeHeap 赋 值 为 true， 以 便 获 得 更 大 的 
Heap Size. Large Heap Size 的 具体 值 可 以 通过 
getLargeMemoryClass () 来 取得 。 不 过 ， 这 个 方法 只 限于 一 些 确实 需要 
大 内 存 空 间 的 程序 〈 如 图 像 处 理 类 程序 ) ， 切 忌 在 出 现 00M 时 为 了 偷懒 
而 直接 使 用 它 ， 这 样 所 带 来 的 最 终 后 果 通 常 是 得 不 偿 失 的 。 


PSS 是 Proportional Set Size 的 缩写 。 和 简单 来 讲 ，PSS= 进 程 独 占 的 
内 存 页 + 按 比例 分 配 与 其 他 进程 共享 的 内 存 页 。 举 个 例子 来 说 ， 如 果 有 2 
个 内 存 页 被 2 个 进程 共享 ， 那 么 它们 的 PSS 数 量 值 各 增加 1。 


Private RAM 表 示 被 你 进程 独占 的 那 部 分 内 存 空 间 ， 所 以 ， 在 程序 
销毁 后 会 被 系统 回收 。 它 又 可 以 分 为 两 类 ， 其 中 Pr ivate Dirty RAM 指 
的 是 必须 常 驻 内 存 的 那些 页 面 ， 相反 的 ，Private Clean RAM 则 是 可 能 
被 paged out 的 那些 页 面 〈 如 果 长 时 间 没 用 〉 。 


其 他 各 种 “mmap” 内 存 (如 . so、. dex、. oat) 特 指 映 射 这 些 对 象 


ee 当然 ， 实 际 的 值 很 可 能 比 我 们 在 meminfo 中 看 到 
JEK. 


有 了 这 些 基础 后 ， 我 们 在 下 一 小 节 就 可 以 进一步 分 析 如 何 做 内 存 监 
测 和 内 存 问题 的 定位 了 。 
5.7.2 Android 中 的 内 存 泄露 与 内 存 监 测 


Android 提 供 了 多 种 工具 来 辅助 开发 人 员 定 位 与 解决 内 存 相关 问 
题 ， 例 如 Logcat、Memory Monitor, Heap Viewer 等 。 


(1) Logcat 
根据 虚拟 机 类 型 的 不 同 分 为 两 种 情况 ， 即 Dalvik 和 ART。 
其 中 Dav|1ik 下 与 GC 相关 的 logcat 格 式 是 : 
D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_m 
下 面 是 一 个 范例 : 


D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991 
5261K, paused 2ms+2ms 


_ GC Reason 表 示 发 生 垃圾 回收 的 原因 ， 可 选项 比较 多 ， 如 表 5-2 所 
示 。 


表 5-2 GC _ Reason 及 释义 


se | 


当 堆 空间 超过 国 值 时 〈 换 名 话说， 
GC_CONCURRENT 内 存 分 配 已 经 成 功 ) ， 产 生 的 并 行 
垃圾 回收 事件 
















当 程 序 试图 去 分 配 堆 无 法 满足 的 空 
间 大 小 时 ， 系 统 需 要 暂停 你 的 程序 





GC_FOR MALLOC 


| ilies 内 存 | 
G 


主动 请 求 的 GC， 比 如 可 以 调用 gc0) 


GC_EXTERNAL ALLOC | 只 适用 于 API 等 级 10 及 以 下 的 版 本 








《<Amount_freed》 表 示 本 次 GC 释放 的 内 存 数量 。 


“Heap_stats> 表 示 剩 余 堆 大 小 占 堆 空间 总 大 小 的 百分比 。 
《External _memory_stats> 只 适用 于 AP1 等 级 10 及 以 下 的 版 本 。 


《Pause time> 表 示 GC 导 致 的 程序 暂停 时 间 。Concurrent 类 型 下 的 暂 
停 时 间 包 含 两 部 分 : 开始 时 和 临近 结束 时 。 在 我 们 这 个 范例 中 具体 值 


是 “paused 2ms+2ms” 。 


ART 虚 拟 机 和 Dalvik 有 不 小 的 差异 ， 它 只 会 在 我 们 主动 请 求 6C 的 情 
况 下 才 会 打印 出 logcat 《或 者 GC 的 暂停 时 间或 者 总 操作 时 间 超 过 上 
BR) 。 关 于 ART 下 的 6GC 选 项 ， 请 大 家 参考 官方 文档 说 明 。 


(2) Memory Monitor 


Memory Monitor 可 以 在 Android Studio 中 局 动 ， 用 于 跟 足 程序 当前 
已 经 分 配 的 和 剩余 的 内 存 空间 大 小 。 如 下 范例 如 图 5-19 所 示 。 
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全 图 5-19 内存 空 间 大 小 


深 色 的 表示 已 经 分 配 的 内 存 ， 浅 色 的 表示 空闲 内 存 数 。 左 侧 的 ， 
人 
列 如 : 


1532-1539/com. android. launcher |/art : Explicit concurrent 
mark sweep GC freed 146(4KB) AllocSpace objects, 0(0B) LOS 
objects, 24% free, 4MB/6MB, paused 1. 629ms total 15. 895ms. 


Memory Monitor 可 以 帮助 用 户 快 速 定 位 垃圾 回收 是 否 会 引起 应 用 程 
序 响应 缓慢 ， 或 者 程序 宕 机 是 否 与 内 存 不 足 有 关 等 问题 。 不 过 ， 更 多 的 
时 候 我 们 需要 把 它 和 其 他 内 存 工具 结合 使 用 才能 发 挥 更 大 的 作用 。 

(3) Heap Viewer 


Heap Viewer 可 以 从 1DE 或 者 Android 的 Android Device Monitor 
启动 ， 界 面 如 图 5-20 所 示 。 
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全 图 5-20 Heap Viewer tH A 


在 图 5-20 所 示 的 例子 中 ， 我 们 为 com. android. launcher 抓 取 了 当前 
的 Heap Status。Heap Viewer 会 特别 提示 开发 人 员 : “Heap updates 
will happen after every GC for this client”。 右 侧 的 上 半 部 分 展 
示 的 是 最 新 的 Heap Size, Allocated Size, Free Size 等 信息 ; 中 间 部 
分 是 对 各 种 类 型 的 对 象 进行 空间 占用 分 析 的 结果 。 比 如 在 这 个 场景 下 
class object 共 有 329 个 ， 占 用 268734KB 大 小 ; 下 半 部 分 则 会 对 这 些 对 
象 进行 图 形 化 分 布 ， 直 观 显示 出 各 种 size 下 的 对 象 的 具体 数量 。 


(4) Allocation Tracker 


开发 人 员 使 用 Android 提 供 的 这 些 内 存 工 具 来 定位 问题 的 典型 流程 
是 : 我 们 首先 使 用 Memory Monitor 来 观察 程序 是 否 会 经 常 性 地 发 生 GC 事 
件 〈 问 题 是 否 存在 ) 一 一 答案 如 果 是 肯定 的 话 ， 有 再 进一步 利用 Heap 
Viewer 来 甄别 出 可 疑 的 对 象 类 型 〈 导 致 问题 的 可 疑 对 象 是 什么 ) ， 最 后 
再 借助 于 Allocation Tracker 来 确定 发 生 问题 的 代码 在 哪个 位 置 〈 问 题 
是 如 何 产 生 的 ) 。 


Allocation Tracker 也 支持 从 1DE 或 者 Android Device Monitor 
启动 。 以 后 者 为 例 ， 它 的 整体 界面 如 图 5-21 所 示 。 
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全 图 5-21 
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Allocation Tracker m 


Allocation Tracker 可 以 获取 各 个 对 象 的 分 配 情况 ， 包 括 它 们 的 时 


间 顺 序 、 线 程 号 ， 以 及 对 象 创建 时 的 调用 堆栈 等 完整 信息 。 有 了 这 些 数 
据 ， 我 们 融 可 以 针对 可 疑 对 象 “ 刨 根 究 底 ”地 分 析出 导致 问题 的 源头 在 
哪里 了 ， 从 而 采取 有 效 的 措施 彻底 解决 这 些 问 题 。 


(5) Memory Analyzer Tool 


MAT (Memory Analyzer Tool) 是 由 Eclipse 社区 贡献 的 一 个 非常 著 


名 的 内 存 分 析 工 具 ， 也 是 Java 开 发 人 员 常 用 的 内 存 泄 露 和 内 存 优化 的 诊 
断 利器 。MAT 支 持 HPROF 文 件 格式 ， 我 们 可 以 通过 多 种 方式 采集 到 它 所 需 
的 数据 。 壁 如 DDMS 就 提供 了 Dump HPROF 文 件 的 功能 ， 如 图 5-22 所 示 。 


e613 2/0 
Dump HPROF file | 
tar SS -hn~ 


全 图 5-22 文件 的 功能 





值得 一 提 的 是 ，MAT 是 通用 的 Java Heap Analyzer， 意 味 着 它 的 应 
用 范围 绝 不 仅 限 于 Android 系 统 。 如 果 大 家 有 其 他 平台 上 的 Java 内 存 问 
题 ， 同 样 可 以 利用 这 个 工具 进行 分 析 。 从 DDMS 中 导出 的 HPROF 需 要 通过 
转换 才能 变 成 标准 的 J2SE HPROF 文 件 。Android SDK 在 platform-tools 
目录 下 提供 了 现成 的 hprof-conv 工 具 来 完成 这 个 工作 。 


MAT 的 功能 比较 全 面 ， 我 们 下 面 只 介绍 开发 者 最 关心 的 核心 功能 ， 
如 图 5-23 所 示 。 


(Inspector $ = O Geomandroidlauncherhprot .java pid112840001 prot 2 =u 























@ 031bt7558 i WW Ble glg 
[Marile - 
mt 1 Overview i Ey daa epart org.ecipse metaptsuspects 
Edess javauiljarJarFle @ OvBlaSebad wu j 
Q jnautizipliprie 
Bjniala yiClsstoade @ 0x0 
1) 64(Ghalow sie 
+) 484,648 (retained size) 45.38 
a noGC root 
Statics | Attributes | Class Hierarchy | Value p 
Type Name Vale 
bool hasCheck. tue 
bool hasClassP., false 
bool. verify tue 
bool. initialized true ae 
ef y java.utljarJarVertfier @ Ox8idae2t Total: 3 7 如 
ef manEntry ot @) aula @ bbs 
ret manRst —_javalang.retScttReterence @ 0x81. 
tef inflaterCaw javautlArrayDequc @ (x81bb773t Salon Size 64 8 Retained Ste: 473.3 KB 
ref streams java.util WeakFashMap @ ()81bbi - 
EE T l i iii iici 
bool. coseReq. false Jil Histogram Lsts number of instances per Leak Suspects: includes leak suspects anda Component Report: Analyze objects wrich 
bool, locsig tue class system overview beongto a common roct package or class 
int total a10 a, Dominator Tree: list the biggest objects Top Components: ist reports for lower 
reframe Users ys0\dppDtaocal Temp and what they keep alve, components bigger than 1 percent of the 
ng jafle 435973440 Top Consumers; Print the most expensive up 
objects grouped by class and by package, 
Duplicate Classes: Detect classes loaded by 
: : multiple class loaders, ; 








全 图 5-23 MAT 的 功能 


0verview 页 中 包含 了 堆 空 间 中 的 各 种 对 象 的 统计 信息 。 其 中 饼 状 图 
表示 的 是 排名 前 几 位 的 大 文件 对 象 。Hi stogram View 是 一 个 包含 所 有 
class 的 列表 ， 以 及 每 个 class 有 多 少 个 对 象 实例 。 某 些 特定 类 型 的 
class (譬如 Android 应 用 程序 中 的 Activity) 通常 只 有 一 个 实例 ， 
而 ， 如 果 在 列表 中 发 现 这 些 对 象 的 数量 和 预期 不 符 ， 那 么 很 可 能 是 出 现 
了 问题 ， 如 图 5-24 所 示 。 


Dominator tree 从 不 同 角度 为 开发 者 审视 内 存 分 配 提 供 了 便利 ， 如 
图 5-25 所 示 。 


0bjects 列 表示 对 应 的 类 的 数量 。Shallow Heap 代 表 类 对 象 本 身 所 
占用 的 内 存 空间 ， 与 之 相对 应 的 是 Retained Heap 一 一 这 个 值 是 指 对 象 
本 身 ， 以 及 它 引 用 的 其 他 对 象 〈 如 果 一 个 对 象 被 引用 ， 那 么 它 很 可 能 
法 被 6GC 回 收 ) 所 占 的 空间 之 和 。 


Memory Analyzer Tool 同 时 提供 了 各 类 分 析 报 告 ， 其 中 对 开发 人 员 
最 有 价值 的 可 能 是 Memory Leak Report。 一 个 范例 报告 如 图 5-26 所 示 。 


报告 会 先 以 饼 状 图 的 形式 直观 给 出 最 有 可 能 发 生 内 存 泄露 的 几 个 对 
象 ， 紧 随 其 后 的 是 针对 这 些 对 象 的 逐一 分 析 ， 如 图 5-27 所 示 。 

















| Class Name Objects Shallow Heap Retained Heap 
| <Regex> «Numeric» «Numeric» <Numeric> 
|O char] 16,404 1,747,208 >= 1,747,208 
|G java.lang.String 15,925 382,200 >= 1,833,504 
(© java.util HashMap$Node 5,214 166,848 >= 984616 
Ging 846 95,832 >= 95,832 
| java.util HashMap$Nodel] 1,879 93,480 >= 1,038,784 
 javautil HashMap 1,887 90,576 >= 1,028,784 
| java.util Hashtable$Entry 2,222 71,104 >= 517,248 
| (c) java.util, LinkedHashMap$Entry 1,437 57,480 >= 226,224 
| @ java.util concurrent.ConcurrentHashMap$Node 1,773 56,736 >= 152,824 
| @ java.util jarAttributes$Name 1,812 43,488 >= 45,272 
| Q java.lang.Object] 721 37,960 >= 442,632 
| javalang.Class 2,069 35,976 >= 1,564,384 
AC) java.util, TreeMap$Entry 892 35,680 >= 224952 
| Qjavalang String] 620 28,768 >= 152,216 
| @ com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDec| 139 27,800 >= 60,192 
| 6 java.util jar Attributes 1,717 27,472 >= 451,208 


全 图 5-24 Histogram View 


i Overview lil Histogram s dominator tree 33 |E Compared Tables 





Class Name Objects Shallow Heap Retained Heap Percentage 
<Numeric> «Numeric» <Numeric> «Numeric» 
> @ javalang.Class 1,561 19,848 1,325,368 33.75% 
> Q javautiljarJarfile 23 1,472 616,216 15.69% 
> © sunnetwww.protocoljar,URUarfile 5 400 499,576 12.72% 
> © sunmmisc.Launcher$AppClassLoader 1 80 327,256 8,33% 
> Q javalang String 1,918 46,032 233,192 5,94% 
>  comandroid.sdklib.repository.local.LocalSdk 1 40 176,472 4,49% 
»@ com.android.sdkuilib,internal.widgets.AvdSelector$16 1 32 147,000 3.74% 
> © sunnio.cs.extExtendedCharsets 1 40 78,976 2.01% 
>» O char] 4 58,944 58,944 1.50% 
> © sunmisc.Launcher$ExtClassLoader 1 80 52,664 1.34% 
> O charg] 1 1,040 51,440 1.31% 
> @ comandroid.sdklib.internal.androidTargetPlatformTarget 1 64 46,408 1.18% 
> @ sunsecurity.x509.X509Certimpl 5 400 37,976 0.97% 
> ® comandroid.utls,GrabProcessOutput$2 1 128 25,432 0.65% 
> © comandroid.utils.GrabProcessOutput$1 1 128 25,232 0.64% 
> Q javaio.PrintStream 1 32 25,112 0.64% 
> © comsun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDec! 92 18,400 24,176 0.62% 
> © java.util, PropertyResourceBundle 1 40 22,760 0.58% 


全 图 5-25 内 存 分 配 
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范例 报告 


a (a) Problem Suspect 1 
a (b) Problem Suspect 2 
a (c) Problem Suspect 3 
B (d) Remainder 


= @ Problem Suspect 1 


: One instance of "sun.net.www.protocol.jar-URLJarFile" loaded by "<system class 
_ loader>" occupies 496,904 (12.65%) bytes. The memory is accumulated in one 

_ instance of "sun.net.www.protocol.jar-URLJarFile” loaded by "<system class 

. loader>". 


| Keywords 
. sun.net.www.protocol.jar.URLJarFile 


: Details » 





One instance of "java.util.jar.JarFile" loaded by "<system class loader>" occupies 
| 484,648 (12.34%) bytes. The instance is referenced by 

_ sun.misc.URLClassPath$JarLoader @ 0x81bceb80 , loaded by "<system class 

_ loader>". The memory is accumulated in one instance of "java.util.jar.JarFile" 

‘ loaded by "<system class loader>". 


~ Keywords 
. java.util.jar.JarFile 


: Details » 





全 图 5-27 对象 的 分 析 


单 击 图 5-27 中 的 “Details” 后 还 会 有 与 可 疑 对 象 相关 的 更 多 详细 
信息 。 总 的 来 说 ，Memory Leak 与 程序 业务 逻辑 有 一 定 关 系 ， 并 没 
有 “ 放 之 四 海 缘 准 ” 的 评价 标准 。 但 是 MAT 提 供 的 信息 可 以 让 开发 人 员 
从 “浩瀚 ” 的 代码 中 更 快速 地 筛选 出 嫌疑 对 象 ， 以 此 为 基础 来 最 终 确定 
和 解决 问题 。 这 也 是 MAT 在 Java 程 序 开发 中 广 受 欢迎 的 一 个 重要 原因 。 
heli 关于 MAT 更 多 强大 的 功能 ， 和 希望 大 家 可 以 自行 查阅 相关 
资料 来 了 解 。 


FEES Fa {S=——8 i inder 


我 们 知道 ， 同 一 个 程序 中 的 两 个 函数 之 间 能 直接 调用 的 根本 原因 是 
处 于 相同 的 内 存 空间 中 。 


比如 有 以 下 两 个 范 数 A 和 B: 


/*Simple.c*/ 
void A() 
{ BC); } 


void B() 
La 


因为 是 在 一 个 内 存 空间 中 ， 虚 拟 地 址 的 映射 规则 完全 一 致 〈 还 记得 
我 们 在 计算 机 基础 章节 中 讨论 过 的 虚拟 内 存 吗 ) ， 所 以 函数 A 和 B 之 间 的 
调用 关系 很 简单 ， 如 图 6-1 所 示 。 


全 图 6-1 同一 进程 空间 中 的 函数 调用 
反之 ， 两 个 不 同 的 进程 ， 如 某 Application1 和 


ActivityManagerService〈 所 在 的 进程 》， 它 们 是 没有 办 法 直接 通过 内 
存 地 址 来 访问 到 对 方 内 部 的 函数 或 者 变量 的 ， 如 图 6-2 所 示 。 


Application yE AMS 所 在 进程 


AR 





全 图 6-2 跨 进 程 时 无 法 直接 访问 到 对 方 的 内 存 空间 


既然 无 法 “直接 ”访问 到 对 方 进 程 的 内 存 空 间 ， 那 有 没有 “ 间 


接 ” 的 方法 呢 ? 简 而 言 之 ， 这 就 是 Binder 所 要 做 的 工作 ， 如 图 6-3 所 
7J“ o 


Application tte AMSTE 


Application! fh £22 AMS 内 存 空间 





全 图 6-3 基于 Binder 的 跨 进 程 内 存 访问 


Binder 给 人 的 第 一 印象 是 “捆绑 者 ”， 即 将 两 个 需要 建立 关系 的 


object 用 某 些 工具 束缚 在 一 起 。 同 时 ， 它 又 是 “黏合 剂 ”一 一 正 因 为 有 
了 Binder，Android 系 统 中 形形色色 的 进程 与 组 件 才能 真正 地 统一 成 有 
机 的 整体 。 


简单 地 说 ，Binder 是 Android 中 使 用 最 广泛 的 1PC 机 制 。 我 们 在 之 前 
的 计算 机 基础 章节 中 已 经 讲解 过 操作 系统 经 典 的 进程 间 通 信 方 式 ， 如 信 
号 量 、 管 道 、Socket 等 。 那 么 ， 为 什么 Android 还 要 再 自己 创造 一 个 新 
的 1PC 机 制 呢 ? 既然 Binder 可 以 “ 力 压 群雄 ”而 成 为 主流 ， 必 然 有 
其 下 过 从 一 之 人 处; 


本 章 接 下 来 将 为 Binder 做 一 个 全 面 而 彻底 的 “体检 ”: 


Bindet 驱 动 ; 
Service Manager ; 
Binder Client; 
Binder Server. 


因为 Binder 机 制 涉及 的 东西 既 多 且 杂 ， 根 据 项 目 实践 中 的 经 验 ， 很 
多 新 手 往往 学 习 到 中 途 就 迷失 了 方向 。 为 了 避免 类 似 情况 的 发 生 ， 我 们 
有 必要 先 讲述 下 即将 登场 的 几 个 主角 的 概念 与 功能 。 希 望 读者 可 以 先 了 
解 “ 它 是 什么 、 有 哪些 组 成 元 素 ”， 进 而 上 升 到 “为 什么 会 有 这 些 组 
成 、 内 部 原理 是 什么 ”。 


如 果 统 观 Binder 中 的 各 个 组 成 元 素 ， 就 会 惊奇 地 发 现 它 和 TCP/ZIP 网 
络 有 很 多 相似 之 处 : 


e。 Bindet 驱 动 一 路 由 器 ，; 

e Service Manager—DNS; 
e Binder Client 一 客户 端 ; 
e Binder Setvet 一 服务 器 。 


TCPZIP 中 一 个 典型 的 服务 连接 过 程 〈 比 如 客户 端 通过 浏览 器 访问 
Google 主 页 ) 如 图 6-4 所 示 。 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
=) 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


| 
| 
| 
| 
d 
= x | 
© = | 
= x I 
2 * | 
D p 
元 So a) 
ln a OPE ES eg OE OR EO TR EE 
D D wl l 
AN aE BH | 
= So | 
5 oi I 
D ow, l i T3 | 
y >| 3 2 
ay D 2 | 
el = = | 
I S 51 
I = Oy 
| I 
2 4 t 
5 一 一 一 一 一 一 一 一 一 一 一 一 一 一 天 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 
© = B * 
S $ | 
2 g! = | 
> a = = 
5 a = zf 
aa Bo I 2 = 
© 5l SD Dl 
Oy © | 三 =| 
= Sea D 
D Sl = | 
Gy | = | 
= | 一 二 | 二 一 _ 
= A zZ 
K S 


全 图 6-4 一 个 典型 的 TCP/IP 访 问 过 程 


在 这 个 简化 的 流程 图 中 共 出 现 了 四 种 角色 ， 即 Client，Server， 
DNS 和 Router。 它 们 的 目标 是 让 C1ient 与 Server 建 立 连 接 ， 主 要 分 为 如 


下 几 个 步骤 。 
e Client 向 DNS 查 询 Google.com 的 IP 地 址 。 


显然 ，Client 一 定 得 先知 道 DNS 的 1P 地 址 ， 才 有 可 能 向 它 发 起 查 
询 。DNS 的 1P 设 置 是 在 客户 端 接 入 网 络 前 就 完成 了 的 ， 否 则 C1ient 将 无 
法 正常 访问 域名 服务 器 。 


当然 ， 如 果 Client 已 经 知晓 了 Server 的 IP， 那 么 完全 可 以 跨越 这 一 
步 而 直接 与 Server 连 接 。 比 如 Windows 操 作 系 统 就 提供 了 一 个 hosts 文 
件 ， 用 于 查询 常用 网 址 域名 与 其 1P 地 址 的 对 应 关系 。 当 用 户 需 要 访问 某 
个 网 址 时 ， 系 统 会 先 从 这 个 文件 中 判断 是 否 已 经 存 有 这 个 域名 的 对 应 
IP。 如 果 有 就 不 需要 再 大 费 周 折 地 向 DNS 查询 了 ， 从 而 加 快 访问 速度 。 


e DNS 将 查询 结果 返回 Client。 


因而 Client 的 1P 地 址 对 于 DNS 也 必须 是 可 知 的 ， 这 些 信息 都 会 被 封 
装 在 TCP/1P 包 中 。 


e Client 发 起 连接 。 
e Client 在 得 到 Google.com 的 也 地 址 后 ， 就 可 以 据 此 来 向 Goople 服 务 器 
发 起 连接 了 。 


在 这 一 系列 流程 中 ， 我 们 并 没有 特别 提 及 Router 的 作用 。 因 为 它 所 
担负 的 责任 是 将 数据 包 投递 到 用 户 设 定 的 目标 1P 中 ， 即 Router 是 整个 通 
信和 结构 中 的 基础 。 


从 这 个 典型 的 TCPZIP 通 信 中 ， 我 们 还 能 得 到 什么 提示 呢 ? 


首先 ， 在 TCP/1P 人 参考 模型 中 ， 对 于 1P 层 及 以 上 的 用 户 来 说 ，1P 地 址 
orn 凭证 一 一 任何 用 户 在 整个 互联 网 中 的 1P 标 志 符 都 是 唯 


其 次 ，Router 是 构建 一 个 通信 和 网络 的 基础 ， 它 可 以 根据 用 户 填 写 的 
目标 1P 正 确 地 把 数据 包 发 送 到 位 。 


最 后 ，DNS 角 色 并 不 是 必需 的 ， 它 的 出 现 是 为 了 帮助 人 们 使 复杂 难 
记 的 1P 地 址 与 可 读 性 更 强 的 域名 建立 关联 ， 并 提供 查询 功能 。 而 客户 端 
能 使 用 DNS 的 前 提 是 它 已 经 正确 配置 了 DNS 服务 器 的 1P 地 址 。 


清楚 了 网 络 通 信 中 各 个 功能 模块 所 扮演 的 角色 ， 接 下 来 把 它 与 
Binder 做 一 个 对 比 。 


Binder 的 原型 如 图 6-5 所 示 。 


进程 | 进程 2 


全 图 6-5 Binder 的 原型 


Binder 的 本 质 目标 用 一 句 话 来 描述 ， 就 是 进程 1 《客户 端 ) ABA 
进程 2〈 服 务 器 ) 进行 互 访 。 但 因为 它们 之 间 是 跨 进程 〈 跨 网 络 ) 的 ， 
所 以 必须 借助 于 Binder 驱 动 〈 路 由 器 ) 来 把 请 求 正确 投递 到 对 方 所 在 进 
程 〈 网 络 ) 中 。 而 参与 通信 的 进程 们 需要 持 有 Binder “颁发 ”的 唯一 标 
志 〈1IP 地 址 ) ， 如 图 6-6 所 示 。 


和 TCP/1P 网 络 类 似 ，Binder 中 的 “DNS” 也 并 不 是 必需 的 一 一 前 提 
是 客户 端 能 记 住 它 要 访问 的 进程 的 Binder 标 志 (IP 地 址 ) ; 而 且 要 特别 
注意 这 个 标志 是 “动态 IP”， 这 就 意味 着 即使 客户 端 记 住 了 本 次 通信 过 
程 中 目标 进程 的 唯一 标志 ， 下 一 次 访问 仍然 需要 重新 获取 ， 这 无 疑 加 大 
了 客户 端的 难度 。 “DNS” 的 出 现 可 以 完美 地 解决 这 个 问题 ， 用 于 管理 
a A “域名 ” 间 的 对 应 关系 ， 并 向 用 户 提 供 查 询 
功能 。 


那么 在 Binder 机制 中 ，DNS 的 角色 又 由 谁 来 诠释 呢 ? 


没 错 ， 就 是 Service Manager， 如 图 6-7 所 示 。 


Binder Driver 





全 图 6-6 Binder 了 驱动 是 进程 间 “ 路 由 ”的 关键 


Service Manager 


Binder Driver 





A 6-7 Service Manager 所 扮演 的 角色 


读者 可 能 会 问 ， 既 然 Service Manager 是 DNS， 那 么 它 的 “1P 地 
址 ”是 什么 呢 ? Binder 机 制 对 此 做 了 特别 规定 。 


Service Manager 在 Binder 通 信 过 程 中 的 唯一 标志 永远 都 是 0。 
这 样 所 有 问题 都 解决 了 。 
本 章 接 下 来 几 个 小 节 将 逐一 深入 分 析 Binder 的 各 组 成 元 素 。 


6.1 智能 指针 


智能 指针 在 整个 Android 工 程 中 使 用 很 广泛 ， 特 别 是 在 Binder 的 源 
码 实 现 中 更 可 谓 “ 比 比 皆 是 ”。 所 以 ， 我 们 有 必要 先 花 费 一 定 的 时 间 来 


学 习 它 。 
6.1.1 智能 指针 的 设计 理念 


Java 和 C/C++ 的 一 个 重大 区 别 ， 就 是 它 没 有 “指针 ”的 概念 。 这 并 
个 代表 Java 不 需要 使 用 指针 ， 而 是 这 个 “超级 武器 ”被 隐藏 了 起 
来 。“ 水 能 载 入 ， 亦 能 覆 舟 ”， 如 果 读 者 曾 使 用 C/C++ 开发 过 一 些 大 型 
项 目 ， 就 会 知道 开发 人 员 最 头疼 的 事情 莫 过 于 概率 性 极 低 (Once) 的 死 
机 问题 一 一 而 造成 系统 宕 机 的 根源 ， 往 往 就 是 指针 异常 。 所 以 Java 以 其 
他 更 “安全 ”的 形式 向 开发 人 员 提 供 了 隐 和 性 的 “指针 ”， 使 得 用 户 既 能 
享受 到 指针 的 强大 功能 ， 又 能 尽量 避免 指针 带 来 的 灾难 。 


C/C++ 项 目 中 常见 的 指针 间 题 可 以 归纳 为 : 
。 指针 没有 初始 化 


对 指针 进行 初始 化 是 程序 员 必 须 养 成 的 民 好 习惯 ， 也 是 指针 问题 中 
最 容易 解决 和 控制 的 一 个 《其 实 不 仅 是 指针 的 初始 化 ， 新 分 配 的 内 存 块 
在 进行 操作 前 都 应 视 实际 情况 进行 初始 化 ) 。 


e new 了 对 象 后 没有 及 时 delete 


a 动态 分 配 的 内 存 对 象 ， 其 生命 周期 的 控制 不 当 常 常会 引 来 不 少 麻 
AW 


当代 码 数量 不 多 而 且 这 些 动态 对 象 只 由 一 名 程序 员 自 己 维护 时 ， 问 
题 通常 不 大 ， 因 为 只 要 稍微 留心 就 可 以 实现 new 和 delete 的 配套 操作 ; 
但 如 果 是 一 个 大 型 工程 〈 特 别 是 多 地 协同 研发 的 软件 项 目 ) ， 由 于 沟通 
的 不 及 时 或 者 人 员 素 质 的 参差 不 齐 ， 束 很 可 能 会 出 现 动态 分 配 的 内 存 没 
有 回收 的 情况 一 一 由 此 造成 的 内 存 泄露 问题 往往 是 致命 的 。 


比如 FunctionA () 中 new 了 一 个 对 象 ， 并 作为 函数 结果 返回 给 调用 
者 ， 那 么 原则 上 这 个 对 象 就 应 该 由 调用 者 自行 delete。 但 是 由 于 某 些 原 





因 ， 调 用 者 并 没有 执行 (或 者 它 并 不 知道 要 执行 ) 这 样 的 操作 ， 久 而 久 
之 就 会 成 为 系统 死机 的 罪魁 祸首 。 类 似 的 bug 因 为 只 在 芭 些 特定 情况 下 
才 会 发 生 〈 比 如 内 存 不 足 ) ， 最 后 表现 出 来 的 问题 就 是 偶发 性 系统 宕 机 
一 一 要 彻底 找 出 这 类 问题 的 根源 很 可 能 会 是 “大 海 授 针 ”。 


。 野 指 针 


假设 有 这 样 一 个 场景 : 我 们 new 了 一 个 对 象 A， 并 将 指针 ptr 指 向 这 
个 新 对 象 〈 即 ptr=new A) 。 当 对 A 的 使 用 结束 后 ， 我 们 也 主动 delete 了 
TE (delete A) ， 但 唯一 没 做 的 是 将 ptr 指 针 置 空 ， 那 么 可 能 出 现 什么 
问题 呢 ? 


没 错 ， 这 就 是 野 指 针 。 因 为 此 时 如 果 有 “第 三 方 ” 试 图 用 ptr 来 使 
用 内 存 对 象 ， 它 首先 通过 判断 发 现 ptr 并 不 为 空 ， 自 然而 然 地 就 认为 这 
个 对 象 还 是 存在 的 ， 其 结果 也 将 导致 不 可 预料 的 死机 。 


还 有 一 种 更 头疼 的 情况 : 假设 ptr1 和 ptr2 都 指向 对 象 ， 后 来 我 们 
通过 ptr1 释 放 了 A 的 内 存 空间 ， 并 且 将 ptr1 也 置 为 nul1; 但 是 ptr2 并 不 
知道 它 所 指向 的 内 存 对 象 已 经 不 存在 ， 此 时 如 果 通 过 ptr2 来 访问 A 也 会 
导致 同样 的 问题 。 


既然 6/C++ 中 的 指针 有 如 此 “洪水 猛 幅 ”的 倾向 ， 那 么 我 们 有 没有 
办 法 来 对 它 进 行 适当 的 改善 呢 ? 这 就 是 智能 指针 出 现 的 意义 。 


在 分 析 Android 中 智能 指针 的 实现 原理 前 ， 读 者 应 该 先 思考 一 下 
一 一 如 果 让 我 们 自己 来 设计 智能 指针 ， 该 怎么 做 呢 ? 


显然 ， 前 面 提 到 的 指针 常见 问题 点 是 解决 的 重点 。 所 以 问题 就 转化 
为 ， 如 何 设 计 一 个 能 有 效 防止 以 上 几 个 致命 弱点 的 智能 指针 方案 。 


第 一 个 没有 初始 化 的 问题 很 好 解决 ， 只 要 让 智能 指针 在 创建 时 置 为 
nul | BY Ay. 


第 二 个 问题 是 实现 new 和 delete 的 配套 。 换 名 话说 ，new 了 一 个 对 象 
就 需要 在 某 个 地 方 及 时 地 delete 它 。 既 然 是 智能 的 指针 ， 那 就 意味 着 它 
应 该 是 一 个 默默 奉献 的 辛勤 工作 者 ， 尽 可 能 自动 地 帮 程 序 员 排 忧 解难 ， 
而 不 是 所 有 事情 都 需要 程序 员 手 工 来 完成 。 


要 让 智能 指针 自动 判断 是 否 需要 回收 一 块 内 存 空 间 ， 应 该 如 何 设 


以 下 我 们 称 内 存 对 象 为 object， 称 智能 指针 为 snartPointer， 那 
A: 


e SmartPointer 是 个 类 


首先 能 想到 的 是 ，SmartPointer 要 能 记录 object 的 内 存 地 址 。 也 就 
是 说 ， 它 的 内 部 应 该 有 一 个 指针 变量 指向 object， 所 以 SmartPointer 是 
一 个 类。 即 : 


class SmartPointer 


{ 
private: 

void * m_ptr; // 指 向 object 对 象 
} 


e SmartPointer 是 一 个 模板 类 


智能 指针 并 不 是 针对 某 种 特定 类 型 的 对 象 设计 的 ， 因 而 一 定 是 模拟 
类 。 具 体 如 下 所 示 : 


template <typename T> 
class SmartPointer 


{ 
private: 

T* m_ptr;// 指 癌 object 对 象 
} 


e SmartPointer 的 构造 函数 


根据 第 一 个 问题 的 描述 ， 智 能 指针 的 构造 水 数 应 将 m_ptr 置 空 。 具 
体 如 下 所 示 : 


template <typename T> 
class SmartPointer 
1 
inline SmartPointer() : m_ptr(0) { } 
private: 
T* m_ptr;//slobject 


。 引用 计数 


这 是 关键 的 问题 点 ， 智 能 指针 怎么 知道 应 该 在 什么 时 候 释 放 一 个 内 
存 对 象 呢 ? 答案 就 是 “ 当 不 需要 的 时 候 ” 释 放 一 一 这 上 听 起 来 像 一 句 废 
话 ， 却 引导 我 们 从 “什么 是 需要 和 不 需要 ”这 个 入 口 点 来 思考 问题 : 假 
设 有 一 个 指针 指向 这 个 object， 那 就 必然 代表 后 者 是 “被 需要 ”的 ; 直 
到 这 个 指针 解除 了 与 内 存 对 象 的 关系 ， 我 们 就 可 以 认为 这 个 内 存 对 象 已 
经 “不 被 需要 ”。 

如 果 有 两 个 以 上 的 指针 同时 使 用 内 存 对 象 呢 ?也 好 办 ， 只 要 有 一 个 
计数 器 记录 着 该 内 存 对 象 “ 被 需要 ”的 个 数 即 可 。 当 这 个 计数 器 递减 到 
零 时 ， 就 说 明 该 内 存 对 象 应 该 “寿终正寝 ”了 。 这 就 是 在 很 多 领域 都 获 
得 了 广泛 应 用 的 “引用 计数 ”的 概念 。 

个 过 又 有 一 个 问题 点 接 星 而 至 ， 那 就 是 由 谁 来 管理 这 个 计数 器 。 


下 面 我 们 设计 两 种 计数 器 管理 方式 ， 大 家 可 以 比较 下 它们 的 优 缺 


1. 计数 器 由 智能 指针 拥有 
这 时 的 情况 如 图 6-8 所 示 。 
如 果 当 前 只 有 一 个 智能 指针 引用 了 object， 看 上 去 并 没有 什么 大 问 


题 。 那 么 ， 如 果 有 两 个 〈 或 以 上 ) 的 智能 指针 都 需要 使 用 ob ject 呢 ? 如 
图 6-9 所 示 。 


object 





SmartPomnter 


全 图 6-8 计数 器 由 智能 指针 管理 (1/2) 





SmartPomter| SmartPomter? 


AK69 计数 器 由 智能 指针 管理 (2/2) 


当 SmartPointer1 释 放 了 自己 与 object 的 连接 后 ， 会 将 mCount 减 1 
这 时 候 发 现 计数 值 已 经 为 零 ， 所 以 根据 设计 需要 去 delete 





object。 然 而 令 SmartPointer1 意 想不到 的 情况 是 此 时 SmartPointer2 却 
还 在 使 用 ob ject 一 一 显然 这 将 引发 致命 的 问题 。 


2. 解决 这 一 问题 的 唯一 方法 





计数 器 由 object 自 身 持 有 


我 们 可 以 为 有 计数 器 需求 的 内 存 对 象 实现 一 个 统一 的 “ 父 类 ”一 一 
这 样 只 要 object 继 承 于 它 就 具备 了 计数 的 功能 。 比 如 下 面 的 范例 : 


template <class T> 


class LightRefBase 


{ 
public: 
inline LightRefBase() : mCount(0) { } 
inline void incStrong() const {/* 增 加 引用 计数 */ 
android_atomic_inc(&mCount); 
} 


inline void decStrong() const {/* 减 小 引用 计数 */ 
if (android atomic dec(&mCount) == 1 
delete static_cast<const T*>(this);/* 删 除 内 存 对 象 */ 
} 
} 


protected: 
inline ~LightRefBase() { } 





private: 
mutable volatile int32_t mCount;/* 引 用 计数 值 */ 
}; 


以 上 代码 段 中 的 LightRefBase 类 主要 提供 了 两 个 方法 ， 即 
incStrong 和 decStrong， 分 别 用 于 增加 和 减少 引用 计数 值 ， 而 且 如 果 当 
前 已 经 没有 人 引用 内 存 对 象 〈 计 数值 为 0) ， 它 还 需要 自动 释放 自己 。 


那么 ，incStrong 和 decStrong 这 两 个 函数 在 什么 情况 下 会 被 调用 
Ne? 既然 是 引用 计数 ， 当 然 是 在 “被 引用 时 ”， 所 以 这 个 工作 应 该 由 
SmartPointer 完 成 。 如 下 所 示 : 


SmartPointer<TYPE> smartP = new object; 


当 一 个 智能 指针 引用 了 ob ject 时 ， 其 父 类 中 的 | ncStrong 就 会 被 调 
用 。 这 也 意味 着 SmartPointer 必 须要 重 载 它 的 “=” 运 算 符 GES: 多 
数 情 况 下 只 重 载 “等 号 ”是 不 够 的 ， 应 视 具 体 设 计 需 求 而 定 ) : 


template <typename T> 
class SmartPointer 


{ 

inline SmartPointer() : m ptr(0) { } 

~wp(); 

SmartPointer& operator = (T* other);// 重 载运 算 符 
private: 


T* _m_ptr;V// 指 向 object 对 象 
} 


template<typename T> 
SmartPointer<T>&SmartPointer<T>: :operator = (T* other) 


if(other != null) 


m_ptr = other;/* 指 向 内 存 对 象 */ 
other-> incStrong();/* 主 动 增加 计数 值 */ 





return *this; 


当 SmartPointer 析 构 时 ， 也 应 该 及 时 调用 decStrong 来 释放 引用 : 


template<typename T> 
wp<T>::~wp() 


if (m_ptr)m_ptr->decStrong(); 


LightRetBase 


mCount=2 m ptr 


SmartPointer| SmartPointer2 


全 图 6-10 引用 计数 器 由 内 存 对 象 管理 


解决 了 第 二 个 问题 ， 实 际 上 第 三 个 问题 也 就 迎刃而解 了 。 引 用 计数 
器 的 出 现 使 得 释放 内 存 对 象 不 再 是 个 别 指 针 的 事情 ， 而 是 对 象 自己 
的 “内 政 ”一 一 只 要 有 人 在 使 用 ， 它 就 不 会 轻易 delete 自 身 ， 也 就 有 效 
地 避免 了 引用 它 的 指针 突然 变 成 “ 野 指针 ”的 情况 。 


理解 了 本 小 节 讲 解 的 这 些 基础 知识 后 ， 接 下 来 将 具体 分 析 Android 
中 的 智能 指针 实现 ， 包 括 强 指针 和 弱 指 针 两 种 。 
6.1.2 强 指针 sp 


看 到 sp 很 多 人 会 以 为 是 SmartPointer 的 缩写 ， 而 实际 上 它 是 
StrongPointer 的 简写 。 与 sp 相对 应 的 另 一 个 类 是 wp (Bll 


WeakPointer) ， 我 们 将 在 下 一 小 节 中 分 析 。 


经 过 几 次 系统 改版 后 ，sp 这 个 类 已 经 被 完全 移出 了 RefBase. h 文 件 
SL a Se Si ne i 
置 在 : 


frameworks/native/include/utils/StrongPointer .h 
而 wp 以 及 前 一 小 节 所 讲述 的 LightRefBase 都 仍 在 RefBase. ht. 
下 面 来 看 看 sp 类 中 一 些 重要 的 接口 实现 : 


template <typename T> 
class sp 


{ 
public: 
inline sp() : m_ptr(0) { } 


sp(T* other );/* 常 用 构造 函数 */ 





.…/* 其 他 构造 函数 */ 

一 Sp();/* 析 构 函 数 */ 

sp& operator = (T* other);// 重 载运 算 符 “=” 

inline T& operator* () const { return *m_ptr; }// Ha 
inline T* operator-> () const { return m_ptr; }// Ha 
inline T* get() const { return m_ptr; } 


private: 
template<typename Y> friend class sp; 
template<typename Y> friend class wp; 
void set_pointer(T* ptr); 
T* m_ptr; 

}; 


大 家 可 能 已 经 注意 到 了 ， 它 和 前 一 小 节 的 SmartPointer 类 在 实现 上 
基本 是 一 致 的 。 比 如 运算 符 等 号 的 实现 为 : 


template<typename T> 
sp<T>& sp<T>::operator = (T* other) 





if (other) other->incStrong(this);/* 增 加 引用 计数 */ 
if (m_ptr) m_ptr->decStrong(this); 

m_ptr = other; 

return *this; 


上 面 这 段 代 码 同 时 考虑 了 对 一 个 智能 指针 重复 赋值 的 情况 。 即 当 
ae 空 时 ， 要 先 撤 销 它 之 前 指向 的 内 存 对 象 ， 然 后 才能 赋予 其 新 


另外 ， 为 sp 分 配 一 个 内 存 对 象 并 不 一 定 要 通过 操作 运算 符 〈 如 等 
号 ) ， 它 的 构造 浮 数 也 是 可 以 的 : 
template<typename T> 
sp<T>: :sp(T* other) 
: m_ptr(other) 


if (other) other->incStrong(this);/* 因 为 是 构造 函数 ， 不 用 担心 mn_ptr 


这 时 m_ptr 就 个 用 先 置 为 nul1， 可 以 直接 指向 目的 对 象 。 
而 析 构 水 数 的 做 法 和 我 们 的 预想 也 是 一 样 的 : 


template<typename T> 
sp<T>: :~sp() 


if (m_ptr) m_ptr->decStrong(this); 


总 的 来 说 ， 强 指针 sp 的 实现 和 前 一 小 节 的 例子 基本 相同 ， 此 处 不 再 


st 


6.1.3 弱 指 针 wp 


前 面 在 前述 智能 指针 的 “设计 理念 ”时 ， 其 实 是 以 强 指针 为 原型 逐 
步 还 原 出 了 智能 指针 作者 的 “意图 ”， 那 么 弱 指 针 又 是 什么 呢 ? 


读者 可 以 起 象 这 样 一 个 景 : 父 对 象 parent 指 向 子 对 象 chi 1d， 然 
后 子 对 象 又 指向 父 对 象 ， 这 就 存在 了 循环 引用 的 现象 。 


比如 有 如 下 两 个 class: 


struct CDad 


CChild *myChild; 
}; 


struct CChild 


CDad *myDad; 


那么 ， 它 们 很 可 能 会 产生 如 图 6-11 所 示 的 关系 。 


CDad CChild 





从 图 6-11 对 象 间 互 相 引用 的 情况 
如 果 不 考 虑 智能 指针 ， 这 样 的 情况 并 不 会 导致 任何 问题 〈 而 且 在 项 
目 开 发 过 程 中 也 并 不 少见 ) 。 但 是 在 智能 指针 的 场景 下 ， 有 没有 特别 要 
注意 的 地 方 呢 ? 
假设 这 两 个 类 都 具有 引用 计数 器 的 功能 。 
° 因为 CDad 指 向 了 CChi1d， 所 以 后 者 的 引用 计数 器 不 为 零 。 
° 而 CChi 1d 又 指向 了 CDad， 同 样 也 会 使 它 的 计数 器 个 为 零 。 


这 有 点 类 似 于 操作 系统 中 的 死 锁 一 一 因为 内 存 回收 者 发 现 两 者 都 是 
处 于 “被 需要 ”的 状态 ， 当 然 不 能 释放 ， 从 而 形成 了 恶性 循环 。 


解决 这 个 矛盾 的 一 种 有 效 方法 是 采用 “ 弱 引 用 ”。 具 体 措施 如 下 。 


CDad 使 用 强 指针 来 引用 CChi 1d， 而 CChi 1d 只 使 用 弱 引 用 来 指向 父 
类 。 双 方 规定 当 强 引用 计数 为 0 时 ， 不 论 弱 引 用 是 否 为 0 都 可 以 delete 自 
己 《〈 在 Android 系 统 中 这 个 规则 是 可 以 调整 的 ， 后 面 会 介绍 ) 。 这 样 只 
要 有 一 方 得 到 了 释放 ， 就 可 以 成 功 避 免 死 锁 。 聪 明 的 你 一 定 能 马上 想到 
另 一 种 可 能 ， 即 会 不 会 导致 野 指针 的 问题 。 没 错 ， 的 确 会 有 这 方面 的 顾 
虑 。 比 如 CDad 因 为 强 指针 计数 已 经 到 0， 根 据 规则 生命 周期 就 结束 了 ; 
但 此 时 CChi 1d 还 持 有 其 父 类 的 弱 引 用 ， 显 然 如 果 CChi1d 此 时 用 这 个 指针 
来 访问 CDad 将 引发 致命 的 问题 。 鉴 于 此 ， 我 们 还 要 特别 规定 : 


弱 指 针 必 须 先 升级 为 强 指 针 ， 才 能 访问 它 所 指向 的 目标 对 象 。 


弱 指 针 的 主要 使 命 就 是 解决 循环 引用 的 问题 。 下 面具 体 看 看 它 和 强 
指针 有 什么 区 别 : 


template <typename T> 
class wp 


public: 
typedef typename RefBase: :weakref_type weakref_type; 


inline wp() : m_ptr(0) { } 


wp(T* other) ;// 构 造 函 数 

.…/* 其 他 构造 函数 省 略 */ 

~wp(); A 

wp& operator = (T* other); / ZHR ER 


void set_object_and_refs(T* other, weakref_type* refs); 
sp<T> promote() const;/* 升 级 为 强 指针 */ 
.…/* 其 他 方法 省 略 */ 





private: 
template<typename Y> friend class sp; 
template<typename Y> friend class wp; 


T* m_ptr; 
weakref_type* m_refs; 


}; 


和 sp 相 比 ，wp 在 类 定义 上 有 如 下 重要 区 别 。 


除了 指向 目标 对 象 的 m_ptr 外 ， wp 另外 有 一 个 m_refs 指 针 ， 类 型 为 
weakref_type. 

没有 重 载 -> ，* 等 运算 符 。 

。 有 一 个 prmote 方 法 来 将 wp 提升 为 sp。 

目标 对 象 的 父 类 不 是 LightRefBase， 而 是 RefBase。 


J 注意 
这 并 不 是 说 sp 不 能 用 RefBase， 要 视 具体 情况 而 言 。 
先 来 看 看 它 的 构造 水 数 ， 再 有 和 针对 性 地 解释 上 面 所 列 的 几 点 : 
template<typename T> 


wp<T>: :wp(T* other) 
: m_ptr(other) 


if (other) m_refs = other->createWeak(this); 


可 以 和 强 指针 中 的 构造 方法 进行 对 比 ， 如 下 所 示 : 


if (other) other->incStrong(this); 


可 见 wp 并 没有 直接 增加 目标 对 象 的 引用 计数 值 ， 而 是 调用 了 
createWeak 方 法 。 这 个 函数 属于 前 面 提 到 的 RefBase 类 ， 如 下 所 示 : 
class RefBase 
te 


void incStrong(const void* id) const;/* 增 加 强 引 用 计数 值 */ 
void decStrong(const void* id) const;/* 减 少 强 引 用 计数 值 */ 








class weakref_type // 榜 套 类 ，wp 中 用 到 的 就 是 这 个 类 


{ 

public: 
RefBase* refBase() const; 
void incWeak(const void* id);/* 增 加 弱 引 用 计数 值 */ 
void decWeak(const void* id);/* 减 少 弱 引 用 计数 值 */ 





}; 
weakref_type* createWeak(const void* id) const; /*‘En— wee 
weakref_type* getWeakRefs() const; 


typedef RefBase basetype; 


protected: 
RefBase( );/* 构 造 函 数 */ 
virtual ~RefBase( );/* 析 构 函 数 */ 
// 以 下 参数 用 于 修改 object 的 生命 周期 
enum { 
OBJECT_LIFETIME_STRONG = 0x0000, 
OBJECT_LIFETIME_WEAK = 0x0001, 
OBJECT_LIFETIME_MASK = 0x0001 
}; 


weakref_impl* const mRefs; 


}; 


RefBase 崩 人 套 了 一 个 重要 的 类 weakref_type， 也 就 是 前 夯 m_refs 指 
针 所 属 的 类 型 。RefBase 中 还 有 一 个 mRefs 的 成 员 变 量 ， 类 型 为 
weakref_imp1。 从 名 称 上 来 看 ， 它 应 该 是 weakref_type 的 实现 类 。 如 下 
(分 段 阅 读 ) : 


/*frameworks/native/libs/utils/RefBase.cpp*/ 
class RefBase::weakref_impl : public RefBase::weakref_type //f 

















{ 
public: 
volatile int32_t mStrong;/* 强 引用 计数 值 */ 
volatile int32_t mweak;/* 弱 引用 计数 值 */ 
RefBase* const mBase; 
volatile int32_t mFlags; 
#if !DEBUG_REFS/* 不 是 debug 的 情况 下 */ 
weakref_impl(RefBase* base): mStrong(INITIAL_STRONG_VALUE), m 
, mBase(base), mFlags(0) 
{ 


} 
void addStrongRef(const void* /*id*/) { } 
void removeStrongRef(const void* /*id*/) { } 








#else // DEBUG_REFS 宏 ， 即 debug 的 情况 下 
weakref_impl(RefBase* base) 
: mStrong(INITIAL_STRONG_VALUE), mWeak(0), mBase(base), m 
, mStrongRefs(NULL), mWeakRefs(NULL) 





, mTrackEnabled(!!DEBUG_REFS_ENABLED_BY_DEFAULT), mRetain 


{ 
} 


#endif // DEBUG_REFS 宏 结束 
}; // RefBase: :weakref_impl 类 结束 


从 开头 的 几 个 变量 可 以 大 概 猜 出 weakref_imp1 所 做 的 工作 ， 其 中 
mStrong 用 于 强 引 用 计数 ，mWeak 用 于 弱 引 用 计数 。 


宏 DEBUG_REFS 用 于 指示 release 或 debug 版 本 。 可 以 看 到 在 release 
版 本 下 ，addStrongRef，removeStrongRef 等 与 Ref 相 关 的 一 系列 方法 都 
没有 具体 实现 。 也 就 是 说 ， 这 些 方 法 实际 上 是 用 于 调试 的 ， 我 们 在 4 ak 
时 完全 可 以 不 用 理会 。 这 样 一 来 整个 分 析 也 明朗 了 很 多 ， 笔 者 认为 这 
个 类 的 写法 还 是 有 商 榨 的 余地 。 


Debug 和 Release 版 本 都 将 mStrong 初 始 化 为 
INITIAL_STRONG_VALUE。 这 个 值 的 定义 如 下 : 


#define INITIAL_STRONG_VALUE (1<<28) 
而 mWeak 则 初始 化 为 0。 


上 面 #else 到 #endif 之 间 的 部 分 都 是 debug 版 本 要 做 的 工作 ， 所 以 都 
可 以 略 过 不 看 。 因 而 上 述 代 码 段 中 并 没有 引用 计数 器 相关 的 控制 实现 ， 
真正 有 用 的 代码 在 类 声明 的 外 面 。 比 如 我 们 在 wp 构造 函数 中 遇 到 的 
createWeak cy XX : 


RefBase: :weakref_type* RefBase: :createWeak(const void* id) const 





mRefs->incWeak(id) ;/* #400595] Hit Bc* / 
return mRefs;/* 直 接 返 回 weakref_type 对 象 */ 


这 个 函数 先 增加 了 mRefs “也 就 是 weakref_imp1 类 型 的 成 员 变 量 ) 
中 的 弱 引 用 计数 值 ， 然 后 返回 这 个 mRefs。 
相信 很 多 人 已 经 有 点 迷糊 了 ， 其 关系 如 图 6-12 所 示 。 


首先 wp 中 的 m_ptr 还 是 要 指向 目标 对 象 〈 继 承 自 RefBase) 。 
RefBase 的 作用 类 似 于 设计 小 节 中 讨论 的 LightRefBase， 只 个 过 它 还 同 


时 提供 了 弱 引 用 控制 以 及 其 他 新 的 功能 。 


和 LightRefBase 不 同 ，RefBase 不 是 直接 使 用 int 变 量 来 保存 引用 计 
数值 ， 而 是 采用 了 weakref_type 类 型 的 计数 器 。 这 也 是 可 以 理解 的 ， 
为 RefBase 需 要 处 理 多 种 计数 类 型 。 另 外 ，wp 中 也 同时 保存 了 这 个 计数 
器 的 地 址 ， 也 就 是 wp 中 的 m_refs 和 RefBase 中 的 mRefs 都 指向 了 计数 器 。 
其 中 wp 是 通过 在 构造 男 数 中 调用 目标 对 象 的 createWeak 来 获得 计数 器 地 
址 的 ， 而 计数 器 本 身 是 由 RefBase 在 构造 时 创建 的 。 
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全 图 6-12 弱 指 针 机 制 中 各 主要 类 的 关系 





整个 wp 机 制 看 起 来 很 复杂 ， 但 与 强 指 针 相 比 实 际 上 只 是 启用 了 一 个 
新 的 计数 器 weakref_imp1 而 已 ， 其 他 所 有 工作 都 是 围绕 如 何 操作 这 个 计 
数 器 而 展开 的 。 因 而 接 下 来 的 重点 就 是 看 看 这 几 个 类 是 如 何 利用 新 计数 
器 来 达到 设计 目标 的 。 


需要 强调 的 是 ， 虽 然 weakref_imp1 是 RefBase 的 成 员 变量 ， 但 是 wp 
也 可 以 直接 控制 它 ， 所 以 整个 逻辑 显得 稍微 有 点 混乱 ， 不 知道 是 不 是 为 
了 兼容 以 前 版 本 而 遗留 下 来 的 问题 。 


在 createWeak 中 ，mRefs 通 过 incWeak 增 加 了 计数 器 的 弱 引 用 。 即 : 


void RefBase: :weakref_type::incWeak(const void* id) 


{ 
weakref_impl* const impl = static_cast<weakref_impl*>(this); 
imp1->addweakRef (id) ;/* 用 于 调试 目的 *V 
const int32_t c = android_atomic_inc(&impl->mWeak ) ; 
ALOG_ASSERT(c >= 0, "incWeak called on %p after last weak ref 


这 个 函数 真正 有 用 的 语句 就 是 android_atomic_inc(&imp1- 
>mWeak) ， 它 增加 了 mWeak 计 数 咒 值 ， 而 其 他 部 分 都 与 调试 相关 ， 我 们 一 
概略 过 。 


这 样 当 wp 构造 完成 以 后 ，RefBase 所 持 有 的 weakref_type 计 数 器 中 


的 mWeak 就 为 1。 后 面 如 果 有 新 的 wp 指向 这 个 目标 对 象 ，mWeak 还 会 持续 
增加 。 而 如 果 是 sp 指向 它 呢 ? 


我 们 在 上 一 小 节 中 分 析 过 ， 这 时 sp 会 调用 目标 对 象 的 incStrong 方 
法 来 增加 强 引 用 计数 值 。 当 目标 对 象 继 承 自 RefBase 时 ， 这 个 函数 的 实 


现 是 : 
void RefBase::incStrong(const void* id) const 


weakref_impl* const refs = mRefs; 
refs->incWeak(id);/* 增 加 弱 引 用 计数 值 */ 





refs->addStrongRef (id); 

const int32_t c = android atomic inc(&refs->mStrong);/* 增 加 强 3 

ALOG_ASSERT(c > 0, "incStrong() called on %p after last stron 

if (c != INITIAL_STRONG_VALUE) { // 判 断 是 不 是 第 一 次 
return;/* 不 是 第 一 次 ， 直 接 返 回 */ 

} 








android_atomic_add(-INITIAL_STRONG_VALUE, &refs->mStrong); 
refs->mBase->onFirstRef(); 


首先 剔除 与 调试 相关 的 语句 ， 真 正 的 操作 如 下 : 


refs->incWeak(id); 
const int32_t c = android_atomic_inc(&refs->mStrong); 


也 就 是 同时 增加 能 引用 和 强 引 用 计数 值 。 然 后 还 要 判断 目标 对 象 是 
不 是 第 一 次 被 引用 ， 其 中 的 c 变 量 得 到 的 是 “增加 之 前 的 值 ”， 因 而 如 
果 等 于 INITIAL_STRONG_VALUE 就 说 明 是 第 一 次 这 时 候 一 方面 要 回调 
onF irstRef 通 过 对 象 自己 被 引用 ， 另 一 方面 要 对 mStrong 值 做 下 小 调 
整 。 为 什么 呢 ? 


我 们 知道 ，mStrong 先 是 被 置 了 1INITIAL_STRONG_VALUE= 1<<28， 那 
么 当 第 一 次 增加 时 ， 它 就 是 1<《《28+1， 所 以 还 要 再 次 减 掉 
INITIAL STRONG VALUE 才 能 得 到 1。 


看 完 强 弱 指 针对 计数 器 的 操作 后 ， 我 们 再 来 分 析 下 目标 对 象 在 什么 
情况 下 会 被 释放 。 无 非 就 是 考查 减少 强 弱 引 用 时 系统 所 遵循 的 规则 ， 如 
下 所 示 是 decStrong 的 情况 : 





void RefBase::decStrong(const void* id) const 


weakref_impl* const refs = mRefs; 
refs->removeStrongRef (id) ;/* 调 试 目 的 */ 
const int32_t c = android atomic dec(&refs->mStrong);/* 减 少 强 
ALOG_ASSERT(c >= 1, "decStrong() called on %p too many times" 
if (c == 1) {/* 减 少 后 强 引 用 计数 值 已 经 降 为 0*/ 
refs->mBase->onLastStrongRef(id);/* 通 知事 件 */ 
if ((refs->mFlags&OBJECT_LIFETIME_MASK) ==OBJECT_LIFETIME 
delete this;v* 删 除 对 象 */ 
} 


} 
refs->decweak(id);/* 减 少 弱 引用 计数 */ 


du 





首先 减少 mStrong 计 数 器 ， 如 果 发 现 已 经 减 到 0 (Blc==1) , REZ 
回调 onLastStrongRef 通 知 这 一 事件 ， 接 着 执行 删除 操作 〈 如 果 标 志 是 
0BJECT_LIFETIME_STRONG 的 话 ) o 


特别 要 注意 ， 减 小 强 引 用 计数 值 时 还 要 同时 减 小 弱 引 用 计数 值 ， 即 
E 其 实现 如 下 〈 分 两 段 赔 读 ) : 


void RefBase: :weakref_type: :decweak(const void* id) 
{ 
weakref_impl* const impl = static_cast<weakref_impl*>(this); 
impl->removeweakRef (id) ;/* 调 试 目的 *7 
const int32_t c = android_atomic_dec(&imp1->mWeak ) ;/* 减 小 弱 引 用 
ALOG_ASSERT(c >= 1, "decWeak called on %p too many times", th 
if (c != 1) return; 


先 减 小 mWeak 计 数值 ， 如 果 发 现 还 不 为 0〈 即 c!=1) ， 融 直接 返回 ; 
否则 就 是 弱 引 用 计数 值 也 为 0%， 此 时 要 根据 LIFETI ME 标志 分 别处 理 ， 


if ((impl->mFlags&OBJECT_LIFETIME_WEAK) ==OBJECT_LIFETIME_STR 
if (impl->mStrong == INITIAL_STRONG_VALUE) { 
delete impl->mBase; 
} else { 
delete impl; 





} 
} else { 
imp1->mBase ->onLastWeakRef (id); 
if ((imp1->mFlags&OBJECT_LIFETIME_MASK) ==OBJECT_LIFETIME. 
delete impl->mBase; 
} 


上 面 这 上段 代码 是 弱 引 用 的 处 理 核心 ， 主 要 基于 以 下 标志 来 处 理 。 


enum { 


OBJECT_LIFETIME_STRONG = Ox0000, 
OBJECT_LIFETIME_WEAK = 0x0001, 
OBJECT_LIFETIME_MASK = 0x0001 


】 
每 个 目标 对 象 都 可 以 通过 以 下 方法 来 更 改 它 的 引用 规则 。 


void RefBase: :extendObjectLifetime(int32_t mode) 


{ 
} 


android_atomic_or(mode, &mRefs->mFlags); 


实际 上 就 是 改变 了 mFlags 标 志 值 一 一 默认 情况 下 它 是 0， 即 


OBJECT_LIFETIME_STRONG. 


FFY (imp |->mF lags&OBJECT_LIFETIME WEAK) == 
0BJECT_ LIFETIME_STRONG 时 ， 即 释放 规则 受 强 引用 控制 的 情况 。 有 的 读 
者 可 能 会 想 ， 既 然 是 强 引 用 控制 ， 那 能 引用 还 要 做 什么 工作 呢 ? 理论 上 
它 确实 可 以 直接 返回 了 ， 不 过 还 有 些 特 殊 情况 。 前 面 在 incStrong 哆 数 
里 ， 我 们 看 到 它 同 时 增加 了 强 、 弱 引用 计数 值 。 而 增加 弱 引 用 时 是 不 会 
同时 增加 强 引 用 的 ， 这 说 阴 弱 引用 的 值 一 定 会 大 于 等 于 强 引 用 值 。 当 程 
序 走 到 这 里 ， 弱 引用 计数 值 一 定 为 0， 而 强 引 用 值 有 两 种 可 能 。 


一 种 是 强 引 用 值 为 INITIAL STRONG VALUE， 说 明 这 个 目标 对 象 没 有 
被 强 引 用 过 ， 也 就 是 说 没有 办 法 靠 强 指针 来 释放 目标 ， 所 以 需要 
delete imp1->mBase。 


另 一 种 就 是 在 有 强 引 用 的 情况 下 ， 此 时 要 delete imp1， 而 目标 对 
象 会 由 强 引 用 的 decStrong 来 释放 。 


那么 ， 为 什么 是 在 这 里 delete 这 个 计数 器 呢 ? weakref_imp1 既 然 是 
由 RefBase 创 建 的 ， 那 么 按理 来 说 也 应 该 由 它 来 删除 。 实 际 上 RefBase 也 
想 做 这 个 工作 ， 只 是 力不从心 。 其 析 构 函数 如 下 : 


RefBase: :~RefBase() 


if (mRefs->mWeak == 0) { 
delete mRefs; 
} 


在 这 种 情况 下 ，RefBase 既 然 是 由 decStrong 删 除 的 ， 那 么 从 上 面 
decStrong 的 执行 顺序 上 来 看 mWeak 值 还 不 为 0， 因 而 并 不 会 被 执行 。 


如 果 是 弱 引 用 控制 下 的 判断 规则 〈 即 0BJECT_LIFETIME_WEAK) ， 其 
实 和 decStrong 中 的 处 理 一 样 ， 要 首先 回调 通知 目标 对 象 这 一 事件 ， 然 
后 才能 执行 删除 操作 。 


到 此 我 们 就 分 析 完 Android 系 统 中 的 智能 指针 源码 实现 了 ， 小 结 如 


ËN 


。 智能 指针 分 为 强 指针 sp 和 弱 指 针 wp 两 种 。 


通常 情况 下 目标 对 象 的 父 类 是 RefBase 一 一 这 个 基 类 提供 了 一 个 
weaktef impl 类 型 的 引用 计数 器 ， 可 以 同时 进行 强 弱 引用 的 控制 
(内 部 由 mStrong 和 mWeak 提 供 计 数 ) 。 
当 incStrong 增 加 强 引 用 的 ， 也 会 增加 弱 引 用 。 
当 incWeak 时 只 增加 弱 引 用 计数 。 
使 用 者 可 以 通过 extendObjectLifetime 设 置 引用 计数 器 的 规则 ， 不 同 
规则 下 对 删除 目标 对 象 的 时 机 判断 也 是 不 一 样 的 。 
使 用 者 可 以 根据 程序 需求 来 选择 合适 的 智能 指针 类 型 和 计数 器 规 
则 。 
6.2 进程 间 的 数据 传递 载体 

大 家 有 没有 思考 过 ， 进 程 间 该 如 何 传递 数据 的 。 

下 面 先 来 列举 生活 中 的 两 个 例子 ， 以 供 读 者 对 比 参 考 。 

例 1， 快 递 包 右 

比如 从 深圳 快递 一 件 衣 服 给 北京 的 朋友 ， 有 哪些 方法 呢 ? 显然 途径 
是 比较 多 的 。 但 无 论 是 空运 还 是 汽车 、 火 车 运输 ， 在 整个 传递 过 程 
中 “衣服 ”本 身 始终 是 没有 变 过 的 一 一 朋友 拿 到 的 衣服 还 是 原来 那 件 。 

例 2， 通 过 电子 邮件 发 送 图 片 

假设 你 在 深圳 通过 电子 邮件 给 北京 的 朋友 发 送 了 一 张 “ 衣 服 的 图 
片 ”， 那 么 当 朋 友 看 到 它 时 ， 已 经 无 法 估计 这 张 图 片 数据 在 传输 过 程 中 
被 复制 过 多 少 次 了 一 一 但 是 可 以 肯定 的 是 ， 他 看 到 的 图 像 和 原始 图 片 绝 
对 是 一 模 一 样 的 。 

显然 进程 间 的 数据 传递 和 例 2 属 于 同一 种 情况 ， 不 过 略 有 区 别 。 

如 果 只 是 一 个 int 型 数值 ， 不 断 复制 直到 目标 进程 即 可 。 但 如 果 是 
某 个 对 象 呢 ? 我 们 可 以 想象 下 ， 同 一 进程 间 的 对 象 传递 都 是 通过 引用 来 
做 的 ， 因 而 本 质 上 就 是 传递 了 一 个 内 存 地 址 。 这 种 方式 在 跨 进 程 的 情况 


下 就 无 能 为 力 了 。 由 于 采用 了 虚拟 内 存 机 制 ， 两 个 进程 都 有 自己 独立 的 
内 存 地 址 空间 ， 所 以 跨 进 程 传递 的 地 址 值 是 无 效 的 。 














Parcel 


进程 间 的 数据 传递 是 Binder 机 制 中 的 重要 一 环 ， 因 而 有 必要 对 它 进 
行 专门 的 讲解 。Android 系 统 中 担负 这 一 重任 的 就 是 Parce|。 


Parce1 是 一 种 数据 的 载体 ， 用 于 承载 希望 通过 1Binder 发 送 的 相关 
SS 〈 包 括 数 据 和 对 象 引 用 ) 。 正 是 基于 Parcel 这 种 跨 进 程 传输 数据 的 
能 力 ， 进程 间 的 1PC 通 信 才 能 更 加 平滑 可 靠 。 Parce1 的 英文 直译 是 “ 打 
包 ”， 是 对 “进程 间 数 据 传递 ”的 形象 描述 。 上 面 已 经 说 过 ， 直 接 传送 
对 象 的 内 存 地 址 的 做 法 是 行 不 通 的 。 那 么 ， 如 果 把 对 象 在 进程 A 中 占据 
的 内 存 相关 数据 打包 起 来 ， 然 后 寄 送 到 进程 8 中， 由 B 在 自己 的 进程 空间 
中 “ 复 现 ”这 个 对 象 ， 是 否 可 行 呢 ? 


Parce1 就 具备 这 种 打包 和 重组 的 能 力 。 它 提供 了 非常 丰富 的 接口 以 
方便 应 用 程序 的 使 用 ， 详 细 说 明 可 参见 官方 文档 

http ://developer. android. com/reference/android/os/Parcel. html. 
下 面 先 对 这 些 接口 进行 一 个 分 类 。 

1. Parcel 设 置 相关 


毋庸 置疑 ， 存 入 的 数据 越 多 ，Parcel 所 占 内 存 空间 也 就 越 大 。 我 们 
可 以 通过 以 下 方法 来 进行 相关 设置 。 


dataSize () : 获取 当前 已 经 存储 的 数据 大 小 。 


setDataCapacity (int size): 设置 Parcel 的 空间 大 小 ， 显 然 存储 
的 数据 不 能 大 于 这 个 值 。 


setDataPosition (int pos): 改变 Parce1 中 的 读 写 位 置 ， 必 须 介 
于 0 和 dataSize () 间 。 


dataAvai | () : 当前 Parce1 中 的 可 读数 据 大 小 。 
dataCapacity () : 当前 Parce1 的 存储 能 
dataPosition(): 数据 的 当前 位 置 值 ， 有 点 类 似 于 游标 。 
dataSize(): 当前 Parce1 所 包含 的 数据 大 小 。 


2. Primitives 


原始 类 型 数据 的 读 写 操作 。 比 如 : 
writeByte (byte) : 写 入 一 个 byte。 
readByte () : 读 取 一 个 byte。 
writeDouble (double): 写 入 一 个 double。 
readDouble () : 读 取 一 个 double。 


从 中 也 可 以 看 到 读 与 操作 是 配套 的 ， 用 哪 种 方式 与 入 的 数据 就 要 用 


相应 的 方式 正确 读 取 。 另 外 ， 数 据 是 按照 host cpu 的 字 节 序 来 读 写 的 。 


3. Primitive Arrays 


原始 数据 类 型 数组 的 读 写 操作 通常 是 先 写 入 用 4 个 字 市 表示 的 数据 


大 小 值 ， 接 着 才 写 入 数据 本 身 。 另 外 ， 用 户 既 可 以 选择 将 数据 读 入 现 有 
的 数组 空间 中 ， 也 可 以 让 Parce1 返 回 一 个 新 的 数组 。 此 类 方法 如 下 : 


wr iteBooleanArray (boolean[]): 写 入 布尔 数组 。 
readBooleanArray (boolean[]) : 读 取 布尔 数组 。 
boolean[]createBooleanArray(): 读 取 并 返回 一 个 布尔 数组 。 
writeByteArray (byte[]): 写 入 字 节 数组 。 


writeByteArray (byte[], int, int): 和 上 面 几 个 不 同 的 是 ， 这 个 


oe 两 个 参数 分 列表 示 数 组 中 需要 被 写 入 的 数据 起 点 以 及 需要 
BABY. 


readByteArray (byte[]): 读 取 字 节 数组 。 


byte[]createByteArray(): 读 取 并 返回 一 个 数组 。 


9 注意 
如 果 写 入 数据 时 系统 发 现 已 经 超出 了 Parcel 的 存储 能 力 ， 它 会 
自动 申请 所 需 的 内 存 空 间 ， 并 扩展 dataCapacity; 而 且 每 次 写 入 都 
是 从 datapPosition O 开始 的 。 
4. Parcelables 


遵循 Parcelable 协 议 的 对 象 可 以 通过 Parcel 来 存 取 ， 如 开发 人 员 经 
常用 到 的 bundle 就 是 继承 自 Parcelable 的 。 与 这 类 对 象 相 关 的 Parcel1 操 
作 包 括 : 


writeParcelable(Parcelable, int): 将 这 个 Parcelable 类 的 名 字 
和 内 容 写 入 Parce1 中 ， 实 际 上 它 是 通过 回调 此 Parcelable 的 
writeToParcel (方法 来 写 入 数据 的 。 


readParcelable (ClassLoader): 读 取 并 返回 一 个 新 的 Parcelable 
对 象 。 


writeParcelableArray(T[], int): 写 入 Parcelable 对 象 数 组 。 


readParcelableArray (ClassLoader): 读 取 并 返回 一 个 Parcelable 


对 象 数组 。 
5. Bundles 


上 面 已 提 到 ，Bundle 继 承 自 Parcelable， 是 一 种 特殊 的 type-safe 
的 容器 。Bundle 的 最 大 特点 就 是 采用 键 值 对 的 方式 存储 数据 ， 并 在 一 定 
程度 上 优化 了 读 取 效率 。 这 个 类 型 的 Parce1 操 作 包 括 : 

wr i teBunde | (Bundle) : 将 Bundle 写 入 parcel。 

readBundle(): 读 取 并 返回 一 个 新 的 Bund1e 对 象 。 


readBundle (ClassLoader): 读 取 并 返回 一 个 新 的 Bundle 对 象 ， 
ClassLoader 用 于 Bundle 获 取 对 应 的 Parcelable 对 象 。 


6. Active Objects 


Parcel1 的 另 一 个 强大 武器 就 是 可 以 读 写 Active 0bjects。 什 么 是 
Active 0bjects 呢 ? 通常 我 们 存 入 Parce1 的 是 对 象 的 内 容 ， 而 Act ive 
0bjects 写 入 的 则 是 它们 的 特殊 标志 引用 。 所 以 在 从 Parcel 中 读 取 这 些 
对 象 时 ， 大 家 看 到 的 并 不 是 重新 创建 的 对 象 实例 ， 而 是 原来 那个 被 写 入 
六 人 


(1) Binder。Binder 一 方面 是 Android 系 统 1PC 通 信 的 核心 机 制 之 
一 ， 另 一 方面 也 是 一 个 对 象 。 利 用 Parce1 将 Binder 对 象 写 入 ， 读 取 时 就 
能 得 到 原始 的 Binder 对 象 ， 或 者 是 它 的 特殊 代理 实现 〈 最 终 操作 的 还 是 
原始 Binder 对 象 ) 。 与 此 相关 的 操作 包括 : 
writeStrongBinder (IBinder ) 


writeStrongInterface(IInterface) 
readStrongBinder () 


(2) FileDescriptor. FileDescriptor#Linux 中 的 文件 描述 
符 ， 可 以 通过 Parce1 的 如 下 方法 进行 传递 。 


writeFileDescriptor(FileDescriptor), readFileDescriptor() 


为 传递 后 的 对 象 仍然 会 基于 和 原 对 象 相 同 的 文件 流 进 行 操作 ， 
而 可 以 认为 是 Active 0b ject 的 一 种 。 


7. Untyped Containers 
它 是 用 于 读 与 标准 的 任意 类 型 的 java 容 器 。 包 括 : 
writeArray(Object[]), readArray(ClassLoader), writeList(List), re 


Parcel 所 支持 的 类 型 很 多 ， 足 以 满足 开发 者 的 数据 传递 请 求 。 如 果 
要 给 Parce| 找 个 类 比 的话 ， 它 更 像 集装箱 。 理 由 如 下 : 


。 货物 无 关 性 


即 它 并 不 排斥 所 运输 的 货物 种 类 ， 电 子 产品 可 以 ， 汽 车 也 行 ， 或 者 
零 部 件 也 同样 接受 。 


不 同 货物 需要 不 同 的 打包 和 印 货 方案 


比如 运载 易 碎 物品 和 坚硬 物品 的 闭 箱 卸货 方式 就 肯定 会 有 很 大 不 
同 。 


o 远程 运输 和 组 装 
FE 


集装箱 的 货物 通常 是 要 跨 洋 运输 的 ， 有 点 类 似 于 Parcel 的 跨 进 程 能 
力 。 不 过 集装箱 运输 公司 本 身 并 不 负责 所 运送 货物 的 后 期 组 装 。 举 个 例 
子 ， 汽 车 厂商 需要 把 一 辆 整 车 先 拆 印 成 零 部 件 后 才能 进行 装 货运 输 ; 到 
达 目 的 地 后 ， 货 运 公司 只 需要 把 货物 完整 无 缺 地 交 由 接收 方 即 可 ， 并 不 
负 有 组 装 成 整 车 的 义务 。 而 Parce1 则 更 加 敬业 ， 它 会 依据 协议 Glam 
本 

业务 。 


接 下 来 ， 我 们 看 看 Parce1 内 部 是 如 何 实现 的 。 


应 用 程序 可 以 通过 Parcel. obtain 0 接口 来 获取 一 个 Parce1 对 象 。 
如 下 所 示 : 


/*frameworks/base/core/java/android/os/Parcel.java*/ 
public static Parcel obtain() { 
final Parcel[] pool = sOwnedPo01;/* 系 统 预先 产生 了 一 个 Parcel 六 
synchronized (pool) { 
Parcel p; 
for (int i=0; i<POOL_SIZE; i++) { 
p = pool[i]; 
if (p != null) { 
pool[i] = nul1，V/ 引 用 置 为 空 ， 这 样 下 次 就 知道 这 个 Par 





return p; 


} 
} 
return new Parcel(0); // 如 果 Parcel 池 中 己 空 ， 就 新 创建 一 个 





新 生成 的 Parce1 有 何 奥妙 之 处 ， 我 们 来 看 看 它 的 构造 函数 : 
private Parcel(int nativePtr) { 


init(nativePtr); 


t 


这 里 什么 都 没有 做 ， 只 是 调用 了 init 0 函数 ， 注 意 传 入 的 
nativePtr 为 0: 


private void init(int nativePtr) { 
if (nativePtr != 0) { 
mNativePtr = nativePtr; 
mOwnsNativeParcelObject = false; 
} else { //nativePtr Ao 
mNativePtr = nativeCreate(); // 为 本 地 层 代码 准备 的 指针 
mOwnsNativeParcelObject = true; 


J 


Parcel 的 JNI 层 实现 在 /frameworks/base/core/jni 中 ， 实 际 上 
Parcel. java 只 是 一 个 简单 的 中 介 ， 最 终 所 有 类 型 的 读 写 操作 都 是 通过 
本 地 代码 实现 的 : 


/*frameworks/base/core/jni/android_os_Parcel.cpp*/ 
static jint android_os_Parcel_create(JNIEnv* env, jclass clazz) 


Parcel* parcel = new Parcel(); 
return reinterpret_cast<jint>(parcel); 





所 以 上 面 的 mNativePtr 变 量 实际 上 是 本 地 层 的 一 个 Parcel (C++) 对 
象 。 接 下 来 的 内 容 就 围绕 这 个 对 象 展 开 ， 分 为 以 下 两 个 关键 部 分 。 


o Parcel 中 如 何 存储 数据 。 

。 我们 选 其 中 两 个 代表 性 的 数据 类 型 (String 和 Binder) 来 分 析 Parcel 
的 处 理 流程 ， 对 应 的 接口 分 别 是 : writeString( /readString() fn 
writeStrongBinder() /readStrongBinder() 。 


先 来 看 看 Parcel (cpp) 类 的 构造 过 程 : 


/*frameworks/native/libs/binder/Parcel.cpp*/ 
Parcel: :Parcel() 


{ 
initState(); 


void Parcel: :initState() 


i 


mError = NO_ERROR; 
mData = 0; 
mDataSize = 0; 
mDataCapacity = 0; 
mDataPos = 0; 
mObjects = NULL; 
mObjectsSize = 0; 


…// 其 他 成 员 变 量 的 初始 化 省 略 





Parce1 对 象 的 初始 化 过 程 只 是 简单 地 给 各 个 变量 赋 了 初 值 ， 并 没 
我 们 设想 中 的 内 存 分 配 动作 。 这 是 因为 Parce1 遵 循 的 是 “动态 扩展 ”的 
内 存 申 请 原则 ， 只 有 在 需要 时 才 会 申请 内 存 以 避免 资源 瀛 费 。 我 们 先 来 
介绍 上 面 代 码 段 中 出 现 的 几 个 重要 变量 ， 因 为 后 面 的 读 写 操作 实际 上 就 
是 围绕 它们 而 实施 的 : 


status_t mError; // 错 误 码 

uint8_t* mData; //Parcel 中 存储 的 数据 ， 注 意 它 是 一 个 uint8_t 类 
size_t mDataSize; //Parcel 中 己 经 存储 的 数据 大 小 

size t mDataCapacity; // 最 大 存储 能 力 

mutable size_t mDataPos; // 数 据 指针 


本 小 节 剩余 内 容 将 结合 一 个 范例 来 详细 讲解 wr iteString 的 实现 原 
理 ， 而 Binder 对 象 的 读 写 过 程 因为 与 后 续 小 节 关系 紧密 ， 稍 后 将 统一 分 
析 。 这 个 范例 是 ServiceManagerProxy 的 getService () 方法 中 对 Parcel 
的 操作 《后 面 对 ServiceManagerProxy 有 详细 分 析 ) 。 源 码 如 下 : 


Parcel data = Parcel.obtain(); 


data.writeInterfaceToken(IServiceManager.descriptor); 
data.writeString(name) ; 


第 一 句 代 码 用 于 获得 一 个 Parce1 对 象 ， 我 们 已 经 分 析 过 
是 创建 了 一 个 本 地 的 Parce1 实 例 ， 并 做 了 全 面 的 初始 化 操作 。 


第 二 句 中 的 wr itelnterfaceToken 用 于 写 入 1Binder 接 口 标 志 ， 所 带 
参数 是 Str ing 类 型 的 ， 如 1ServiceManager. descriptor = 
"android. os. 1ServiceManager "。 





它 最 终 


第 三 句 通 过 writeString 在 Parce1 中 写 入 需要 向 ServiceManager 查 
询 的 Service 名 称 。 


Parce1 在 整个 IPC 中 的 内 部 传递 过 程 比较 烦琐 ， 特 别 在 承载 Binder 
数据 时 更 是 需要 多 次 转换 ， 因 而 容易 让 人 失去 方向 。 但 不 管 过 程 如 何 曲 
折 ， 有 一 点 是 始终 不 变 的 。 那 就 是 : 

与 入 方 和 读 取 方 所 使 用 的 协议 必须 是 完全 一 致 的 。 

正如 上 面 所 举 集 装 箱 的 例子 ， 装 货 和 御 货 的 规则 是 成 套 的 ， 不 能 装 
货 时 用 的 是 对 付 易 碎 物 品 的 方式 ， 而 秃 货 时 又 把 它 当 成 坚硬 物品 。 

来 看 看 写 入 方 〈(ServiceManagerProxy) 都 “ 装 ” 了 些 什么 东西 
到 “集装箱 ”中 : 
status_t Parcel: :writeInterfaceToken(const String16& interface) 


writeInt32(IPCThreadState: :self()->getStrictModePolicy() |STR 
return writeString16(interface) ; 


这 里 就 不 深入 看 getStr ictModePol icy 0 的 源码 实现 了 ， 而 只 要 知 
道 这 个 函数 取得 了 一 个 int 数 值 即 可 。 因 而 上 面 的 语句 等 价 于 : 


writeInterfaceToken-writeInt32(policy value)+writeStringi6(interf 


其 中 interface 就 是 "android. os. 1ServiceManager "。 


再 来 分 别 看 看 writelnt32 和 writeString16 都 做 了 哪些 工作 : 
status_t Parcel: :writeInt32(int32_t val) 


return writeAligned(val); 


这 个 函数 的 实现 很 简单 一 一 只 包含 了 一 名 代码。 从 函数 名 来 判断 ， 
它 是 将 val 值 按照 对 齐 方式 写 入 Parcel1 的 存储 空间 中 。 换 名 话说， 就 是 
将 数据 写 入 mDataPos 起 始 的 mpData 中 〈 当 然 ， 内 部 还 需要 判断 当前 的 存 
储 能 力 是 否 满足 要 求 、 是 否 要 申请 新 的 内 存 等 ) : 


status_t Parcel::writeString1i6(const String16& str) 
{ 


return writeString16(str.string(), str.size()); 


status_t Parcel: :writeString16(const chari6_t* str, size_t len) 


{ 
if (str == NULL) return writeInt32 (-1); //str 不 为 空 


status_t err = writeInt32(len); // 先 写 入 数据 长 度 
if (err == NO_ERROR) { 
len *= sizeof(char16_t); // 长 度 * 单 位 大 小 = 占用 的 空间 
uint8_t* data = (uint8_t*)writeInplace(len+sizeof(char16_ 
if (data) { 
memcpy(data，str，1len);/* 将 数据 复制 到 data 所 指向 的 位 置 中 */ 
*reinterpret_cast<char16_t*>(data+len) = 0; 
return NO_ERROR; 





err = mError,; 


} 


return err; 


整个 writeString16 的 处 理 过 程 并 不 难 理解 : 首先 要 填写 数据 的 长 
度 ， 占 据 4 个 字 节 ; 然后 计算 出 数据 所 需 占据 的 空间 大 小 ; 最 后 才 将 数 
据 复制 到 相应 位 置 中 一 一 writelnplace 就 是 用 来 计算 复制 数据 的 目标 地 
址 的 《〈 下 面 分 段 阅读 ) : 


void* Parcel: :writeInplace(size _t len) 





const size_t padded = PAD_SIZE(len); 


PAD_S1ZE 用 于 计算 “ 当 以 4 对 齐 时 ， 容 纳 len 大 小 的 数据 需要 多 少 空 
间 ”《〔 注 意 1en 在 传 进来 时 进行 了 len *= sizeof (char16 t) ) ， 即 : 


#define PAD_SIZE(s) (((s)+3)&~3) 
比如 len=3，padded = 4 
len =4, padded=4 


len=5, padded =8 


if (mDataPostpadded < mDataPos) { 
return NULL; 
} 


如 果 洪 出 就 直接 返回 NULL。 


下 面 代 码 段 先 写 入 尾部 的 填充 数据 《〈 注 意 ， 数 据 内 容 本 身 不 在 
writelnplace 国 数 里 复制 ) ， 手 法 和 writeAligned 类 似 : 


if ((mDataPos+padded) <= mDataCapacity) {/* 数 据 大 小 没有 超过 容量 *， 
restart write: 
uint8_t* const data = mDatat+mDataPos; 
if (padded != len) {/* 需 要 填充 尾部 的 情况 */ 
#if BYTE_ORDER == BIG_ENDIAN /* 如 果 是 Big Endian 的 情况 */ 
static const uint32_t mask[4] = { 
Ox00000000, OxfffffFOO, Oxffff0000, oxff000000 

















#endif 
#if BYTE_ORDER == LITTLE_ENDIAN /*% Little Endian 的 情况 */ 
static const uint32_t mask[4] = { 
0x00000000, Oxooffffff, oxooooffff, Oxo00000f FT 
}; 


*reinterpret_cast<uint32_t*>(data+padded-4) &= mask[pad 





#endif 


J 


finishwrite(padded);/*Œ%īmDataPos*/ 
return data; 


} 
/* 如 果 程 序 执行 到 这 里 ， 说 明 数 据 大 小 已 经 超过 了 Parcel 的 存储 能 力 ， 需 要 扩大 容 
status_t err = growData(padded); 
if (err == NO_ERROR) goto restart_write;/* 重 新 开始 业务 */ 
return NULL; 
}/*writeInplace 结 束 */ 


上 面 代码 段 的 逻辑 是 : 如 果 空 间 足 够 ， 就 直接 进行 尾部 的 填充 操 
E; 否则 要 申请 更 多 的 存储 空间 (growData) ， 然 后 返回 
restart_wr ite 继 续 执 行 。 尾 部 需要 padding 多 少数 据 是 由 len 和 padded 
综合 决定 的 ， 如 当 len=5 时 ，padded=8， 这 时 就 有 3 个 字 节 是 填充 数据 
(最 多 不 超过 4) 。 填 充 数据 的 写法 采用 的 是 : 


*reinterpret_cast<uint32_t*>(datatpadded-4) &= mask[padded-len]; 


这 里 先 做 了 uint32_t 的 强制 转换 ， 所 以 后 续 操作 就 是 以 4 个 字 节 为 
单位 这 样 可 以 一 次 性 把 3 个 字 节 的 填充 数据 〈 即 mask[L3]= 
0xff000000 或 者 0x000000ff， 取 决 于 是 LITTLE_ENDIAN 还 是 
BIG_ENDIAN) 都 写 入 。 











最 后 调用 finishWr ite 来 调整 mpataPos 指 针 ， 并 返回 data 的 位 置 以 


供 调 用 者 与 入 真正 的 数据 内 容 。 


可 以 看 出 ，wr itelnplace 用 于 确认 即将 写 入 的 数据 的 起 始 和 结束 位 
置 ， 并 做 好 padding 工 作 。 我 们 再 回 到 之 前 的 writeString16 继 续 分 析 。 
因为 有 了 需要 写 入 的 地 址 〈 即 data 指 针 ) ， 所 以 可 以 直接 memcpy。 如 
T: 


memcpy(data, str, len); 
最 后 与 入 字符 串 结束 符 0: 
*reinterpret_cast<chari6_t*>(datatlen) = 


通过 上 面 的 分 析 ， 写 入 一 个 String(writeString16) 的 步骤 : 


e writelnt32(len) ; 


e memcpy; 

e padding (有 些 情况 下 不 需 padding。 而 且 源 码 实 现 中 这 一 步 是 在 
memcpy 之 前 ) o 
回 到 ServiceManagerProxy 中 的 getService 里 : 


data.writeInterfaceToken(IServiceManager .descriptor); 
data.writeString(name); 


我 们 把 上 面 两 个 语句 进行 分 解 ， 就 得 到 写 入 方 的 工作 了 : 


WriteInterfaceToken=writeInt32(policy value)+writeStringi6(interf 
writeString16(interface) = writeInt32(len)+ 写 入 数据 本 身 + 填 充 


根据 上 面 强 调 的 准则 ， 读 取 方 也 必须 遵循 同样 的 数据 操作 顺序 
接 下 来 我 们 做 下 验证 。 
读 取 方 是 Service_manager. c (DERNE) : 


/*frameworks/native/cmds/servicemanager/Service_manager.c*/ 
int svcmgr_handler(struct binder_state *bs, struct binder_txn *tx 
struct binder_io *msg, struct binder_io *reply) 


{oa 
uint32_t strict_policy; 


strict_policy = bio_get_uint32(msg); // 取 得 policy 值 
s = bio_get_string16(msg，&len); // 取 得 一 个 String16, BI EMS AH 
if ((len != (sizeof(svcmgr_id) / 2)) || 
memcmp(svemgr_id, s, sizeof(svcmgr_id))) {/*#rInterfac 
fprintf(stderr,"invalid id %s\n", str8(s)); 
return -1; 


} 
上 面 代 码 段 用 于 判断 收 到 的 interface 是 否 正 确 。 其 中 : 


ay hy ay Tr 


TI'S "e" r 


uint16_t svcmgr_id[] 
7 ; 
S 'i','c','e','M','a','n','a','g','e','r' 


}; 
可 见 ， 和 前 面 的 "android. os. 1ServiceManager "是 一 样 的 : 


Switch(txn->code) { 
case SVC_MGR_GET_SERVICE: 
case SVC_MGR_CHECK_SERVICE: 
s = bio_get_string16(msg，&len);// 获 取 要 查询 的 service name 
ptr = do_find_service(bs, s, len, txn->sender_euid); 
if (!ptr) 
break; 
bio_put_ref(reply, ptr); 
return 0; 


可 以 看 到 ，ServiceManager 对 数据 的 读 取 过 程 和 数据 的 写 入 过 程 确 
实 完全 一 致 。 这 样 我 们 以 String 为 例 ， 完 整地 分 析 了 Parce1 对 基本 数据 
类 型 的 读 写 流程 。 相 对 于 基础 数据 类 型 ，Binder (Active Object) 的 
跨 进 程 传递 要 复杂 很 多 ， 读 者 在 后 续 小 节 中 即 可 看 到 。 





6.3 Binder 驱 动 与 协议 


“万 丈 高 楼 平地 起 ”， 无 论 多 复杂 的 系统 都 是 从 最 基础 的 理论 一 点 
一 滴 构 建 起 来 的 。 比 如 本 书 前 面 章节 分 析 过 的 Android 编 译 系 统 ， 就 是 
从 最 简单 的 make 规 则 不 断 扩展 堆 双 而 成 的 。Binder 作 为 Android 中 男 一 
个 庞大 的 体系 ， 虽 然 代 码 量 多 、 跨 度 广 ， 但 也 同样 需要 自己 的 “地 
x” Binder IKZ). 


我 们 知道 ，Android 系 统 是 基于 Linux 内 核 的 ， 因 而 它 所 依赖 的 
Binder 驱 动 也 必须 是 一 个 标准 的 Linux 驱 动 。 具 体 而 言 ，Binder Driver 
会 将 自己 注册 成 一 个 mi sc device， 并 向 上 层 提供 一 个 /dev/binder 节 点 
一 一 值得 一 提 的 是 ，Binder 节 点 并 不 对 应 真实 的 硬件 设备 。Binder 驱 动 
ees 可 以 提供 open () ioct!(), mmap () 等 常用 的 文件 操 

本 小 节 将 主要 从 用 户 的 角度 来 解释 Binder 驱 动 所 提供 的 功能 以 及 它 
和 用 户 之 间 的 协议 ， 并 辅 以 一 定 的 源码 分 析 。 在 此 之 前 ， 我 们 强烈 建议 
读者 能 先 学 习 下 Linux 驱 动 编程 的 一 些 基 础 知识 。 


Binder 驱 动 源码 在 Kerne| 工 程 的 dr ivers/staging/android 目 录 





Android 系 统 为 什么 把 Binder 注 册 成 misc devi ce 类 型 的 驱动 呢 ? 


这 种 “杂项 ”驱动 的 主 设备 号 统一 为 10， 次 设备 号 则 是 每 种 设备 独 
有 的 。 驱 动 程序 也 可 以 通过 设置 MISC_DYNAMIC _MINOR 来 由 系统 动态 分 配 
次 设备 号 。 


Linux 中 的 字符 设备 通常 要 经 过 al loc_chrdev_region () ， 
cdev_init () 等 一 系列 操作 才能 在 内 核 中 注册 自己 。 而 mi sc 类 型 驱动 则 
相对 简单 ， 只 需要 调用 mi sc_regi ster () 就 可 轻松 解决 。 比 如 Binder 中 
与 驱动 注册 相关 的 代码 : 


/*drivers/staging/android/Binder ,cx*/ 

static struct miscdevice binder_miscdev = { 
.minor = MISC_DYNAMIC_MINOR, /* 动 态 分 配 次 设备 号 */ 
.name = "binder"，/* 驱 动 名 称 */ 
.fops = &binder_fops /*Binder 了 驱动 支持 的 文件 操作 */ 


}; 
static int _ init binder_init(void) 


{ 


ret = misc_register(&binder_miscdev); /* 驱 动 注册 */ 


Binder 驱 动 还 需要 填写 file _ operations 结 构 体 。 如 下 所 示 : 


/*drivers/staging/android/Binder.c*/ 
static const struct file_operations binder_fops = { 
,Owner = THIS_MODULE, 
.poll = binder_poll, 
.unlocked_ioctl = binder_ioctl, 
.mmap = binder_mmap, 
.open = binder_open, 
.flush = binder_flush, 
.release = binder_release, 


}; 


由 此 可 见 ，Binder 驱 动 总 共 为 上 层 应 用 提供 了 6 个 接口 一 一 其 中 使 
用 最 多 的 就 是 binder_ ioct1，binder_mmap 和 binder open。 而 一 般 文 件 
操作 需要 用 到 的 read (0) 和 write 0 则 没有 出 现 ， 这 是 因为 它们 的 功能 完 
全 可 以 用 ioct10 和 mmap () 来 代替; 而 且 后 两 者 还 更 加 灵活 ， 稍 后 会 做 
详细 讲解 。 

另外 ，Binder 所 使 用 的 设备 驱动 入 口 函 数 并 不 是 module_init ()， 
而 是 : 


device_initcall(binder_init); 


这 样 做 的 目的 可 能 是 Android 系 统 并 不 想 支 持 动 态 编译 的 驱动 模 
块 。 如 果 读 者 有 动态 编译 需求 的 话 ， 可 以 将 其 改 成 module_init 和 和 


module exit。 





6. 3.1 打开 Binder 驱 动 


上 层 进程 在 访问 Binder 驱动 时 ， 青 先 就 需要 打开 /dev/binder 节 
点 ， 这 个 操作 最 终 的 实现 是 在 binder_open 0 中 。 如 下 所 示 (DELK) 
读 ) : 


/* 如 果 没 有 特别 说 明 ， 以 下 的 函数 都 在 Binder .c 中 */ 


binder_open 


static int binder_open(struct inode *nodp, struct file *filp) 


{ 


struct binder_proc *proc; 


proc = kzalloc(sizeof(*proc)，GFP_KERNEL );/* 分 配 空间 */ 
if (proc == NULL) 
return -ENOMEM; 


Binder 驱 动 会 在 /proc 系 统 目 录 下 生成 各 种 管理 信息 〈 比 
U0/proc/binder/proc, /proc/binder/state, /proc/binder/stats 
=) 。 上 面 代码 段 中 的 binder_proc 就 是 管理 数据 的 记录 体 〈 每 个 进程 
都 有 独立 记录 ) 。 


接 下 来 对 这 个 新 生成 的 proc 对 象 进行 各 种 初始 化 操作 : 


get_task_struct(current); 

proc->tsk = current; 
INIT_LIST_HEAD(&proc->todo); //todo 链 表 
init_waitqueue_head(&proc->wait); //wait 链 表 
proc->default_priority = task_nice(current); 


完成 proc 的 初始 化 后 ， 接 下 来 应 该 做 什么 呢 ? 没 错 ， 将 它 加 入 
J 管理 中 。 以 下 代码 段 涉 及 了 资源 互 斥 ， 因 而 需要 使 用 保护 
J Lil] : 


binder_lock(__func__); /3k RA 

binder_stats_created(BINDER_STAT_PROC); /*binder_statsebinde 

hlist_add_head(&proc->proc_node, &binder_procs); /* 将 proc 加 入 

列 头 部 */ 

proc->pid = current->group_leader->pid;/* 进 程 pid*/ 

INIT_LIST_HEAD(&proc->delivered_death); 

filp->private_data = proc; /* 将 这 个 proc 与 filp 关 联 起 来 ， 这 样 下 次 通 
proc 了 */ 

binder_unlock( func ); // 解 除 锁 








return 0; 
}/*binder_open 结 束 */ 


到 目前 为 止 ，Binder 驱 动 已 经 为 用 户 创建 了 一 个 它 自 己 的 
binder_proc 实 体 ， 之 后 用 户 对 Binder 设 备 的 操作 将 以 这 个 对 象 为 基 
人 础 。 





6.3.2 binder mmap 


在 操作 系统 基础 章节 曾经 讲解 过 mmap () 这 个 系统 调用 的 使 用 方法 。 
对 于 Binder 驱 动 来 说 ， 上 层 用 户 调用 的 mmap 0 最 终 就 对 应 了 


binder mmap () 。 


先 来 思考 一 个 问题 ，Binder 中 采用 mmap 的 目的 是 什么 呢 ? 我 们 知 
道 ，mmap 0 可 以 把 设备 指定 的 内 存 块 直接 映射 到 应 用 程序 的 内 存 空 间 
中 。 但 Binder 本 身 并 不 是 一 个 硬件 设备 ， 而 只 是 基于 内 存 的 “ 伪 硬 
件 ”， 那 么 它 又 映射 了 什么 内 存 块 到 应 用 程序 中 呢 ? 


假设 有 两 个 进程 A 和 B， 其 中 进程 B 通 过 open () 和 mmap () 后 与 Binder 
驱动 建立 了 联系 ， 如 图 6-13 所 示 。 
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从 图 中 可 以 看 到 。 


对 于 应 用 程序 而 言 ， 它 通过 mmap0 返 回 值得 到 一 个 内 存 地 址 (当然 
这 是 虚拟 地 址 ) ， 这 个 地 址 通过 虚拟 内 存 转 换 (分 段 、 分 页 ) 后 最 
终 将 指向 物理 内 存 的 某 个 位 置 。 

对 于 Bindet 驱 动 而 言 ， 它 也 有 一 个 指针 (binder_proc->buffer, $F 
来 的 代码 中 会 介绍 ) 指向 某 个 虚拟 内 存 地 址 。 而 经 过 虚拟 内 存 转换 
后 ， 它 和 应 用 程序 中 指向 的 物理 内 存 处 于 同一 个 位 置 。 


这 时 Binder 和 应 用 程序 就 拥有 了 若干 共用 的 物理 内 存 块 。 换 句 话 
说 ， 它 们 对 各 自 内 存 地 址 的 操作 ， 实 际 上 是 在 同一 块 内 存 中 执行 的 。 那 
么 ， 这 么 做 有 什么 实际 意义 呢 ? 


别 着 急 ， 我 们 绸 把 进程 A 加 进来 ， 看 看 情况 又 有 了 哪些 变化 ， 如 图 6- 
14 所 示 。 
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全 图 6-14 进程 A 复制 数据 到 进程 B 中 


看 看 图 中 都 发 生 了 什么 。 左 半 部 分 没有 任何 变化 ， 即 进程 B 和 
Binder 共 用 若干 物理 内 存 。 右 半 部 分 Binder 了 驱动 通 过 
copy_from_user () ， 把 进程 A 中 的 某 段 数据 复制 到 其 binder_proc- 
>buffer 所 指向 的 内 存 空 间 中 。 这 时 候 我 们 惊喜 地 发 现 ， 因 为 
binder_proc->buffer 在 物理 内 存 中 的 位 置 和 进程 B 是 共享 的 ， 因 而 进程 
B 可 以 直接 访问 到 这 段 数据 。 也 就 是 说 ，Binder 驱 动 只 用 了 一 次 复制 ， 
就 实现 了 进程 A 和 B 间 的 数据 共享 。 
站 了 初步 的 认识 ， 我 们 再 来 分 析 源 码 就 容易 多 了 (HARK, OR 
| 兄 读 


static int binder_mmap(struct file *filp, struct vm_area_struct * 
o oy 
int ret; 
struct vm_struct *area; 
struct binder_proc *proc = filp->private_data;/* 取 出 这 一 进程 对 ) 
const char *failure_string; 
struct binder_buffer *buffer; 


先 来 解释 几 个 重要 的 变量 。 
e vm_atea_sttut *vma: 


描述 了 一 块 供应 用 程序 使 用 的 虚拟 内 存 ， 其 中 vma->vm_start 和 
vma->vm_end 分 别 是 这 块 连续 的 虚拟 内 存 的 起 止 点 。 


e vm struct *area: 


上 面 的 vma 是 应 用 程序 中 对 虚拟 内 存 的 描述 ， 相 应 的 area 变 量 就 是 
Binder 驱 动 中 对 虚拟 内 存 的 描述 。 


e binder_proc *proc: 
这 个 变量 在 上 一 小 节 binder_open 中 已 经 磁 到 过 。 它 是 Binder 驱 动 
为 应 用 进程 分 配 的 一 个 数据 结构 ， 用 于 存储 和 该 进程 有 关 的 所 有 信息 ， 
如 内 存 分 配 、 线 程 管理 等 。 


在 做 实际 的 工作 前 ，Binder 驱 动 会 判断 应 用 程序 申请 的 内 存 大 小 是 


否 合理 一 一 它 最 多 只 支持 4MB 空 间 的 mmap 操 作 。 如 下 : 


if ((vma->vm_end - vma->vm_start) >SZ_4M) 
vma->vm_end = vma->vm_start + SZ _4M; 


goes zR a a E E 才 4MB 时 ， 并 没有 直接 退 


if (vma->vm_flags & FORBIDDEN_MMAP_FLAGS) {/* 禁 止 MMAP 标 志 */ 
ret = -EPERM; 
failure_string = "bad vm_flags"; 
goto err_bad_arg; 


} 
vma->vm_flags = (vma->vm_flags | VM_DONTCOPY) & ~VM_MAYWRITE; 


判断 vma 中 的 标志 是 否 禁 止 了 mmap， 并 加 入 新 的 标志 : 


mutex_lock(&binder_ mmap_. lock); 

if (proc->buffer) {/* 是 否 已 经 做 过 映射 */ 
ret = -EBUSY; 
failure_string = "already mapped"; 
goto err_already_mapped; 


这 里 的 proc->buffer 用 于 存储 最 终 的 mmap 结 果 〈 属 于 Binder 的 那个 
虚拟 内 存 ) ， 因 而 如 果 不 为 空 ， 说 明之 前 已 经 执行 过 mmap 操 作 。 这 种 情 
H RBinderS 会 判定 为 错误 ， 并 直接 跳 转 到 错误 处 理 部 分 


area = get_vm_area(vma->vm_end - vma->vm_start, VM_IOREMAP); 
if (area == NULL) { 

ret = -ENOMEM; 

failure_string = "get_vm_area"; 

goto err_get_vm_area_failed; 





上 面 的 get_vm_area () 用 于 为 Binder 驱 动 获取 一 段 可 用 的 虚拟 内 存 
空间 。 也 就 是 说 ， 这 时 候 还 没有 分 配 实 际 的 物理 内 存 : 
proc->buffer = area->addr;/* 了 映射 后 的 地 址 */ 


proc->user_buffer_offset = vma->vm_start - (uintptr_t)proc->buffe 
mutex_unlock(&binder_mmap_lock); 


将 proc 中 的 buffer 指 针 指 向 这 块 虚 拟 内 存 起 始 地 址 ， 并 计算 出 它 和 


应 用 程序 中 相关 联 的 虚拟 内 存 地 址 〈( 即 vma->vm_start) 的 偏 移 量 : 


proc->pages = kzalloc(sizeof(proc->pages[0]) * ((vma->vm_end - vm 
if (proc->pages == NULL) { 

ret = -ENOMEM; 

failure_string = "alloc page array"; 

goto err_alloc_pages_failed; 


需要 注意 的 是 ， 上 面 的 kzal loc 只 是 分 配 了 pages 数 组 的 空间 。 这 个 
变量 的 声明 如 下 : 


struct page **pages; 


它 是 一 个 二 维 指针 ， 从 名 称 上 看 是 用 于 管理 物理 页 面 的 ， 也 就 是 用 
于 指示 Binder 申 请 的 物理 页 面 的 状态 : 
proc->buffer_size = vma->vm_end - vma->vm_start; 


vma->vm_ops = &binder_vm_ops; 
vma->vm_private_data = proc; 


计算 虚拟 块 大 小 等 : 


if (binder_update_page_range(proc, 1, proc->buffer, proc->buffer 
ret = -ENOMEM; 
failure_string = "alloc small buf"; 
goto err_alloc_small_buf_failed; 


上 面 的 binder_update_page_range 开 始 真 正 地 申请 物理 页 面 了 。 下 
面 解 释 下 这 个 函数 的 各 个 参数 : 
binder_update_page_range(struct binder_proc *proc, int allocate, 


void *start, void *end, 
struct vm_area_struct *vma); 


proc: 申请 内 存 的 进程 所 持 有 的 binder_proc 对 象 。 
allocate: 是 申请 还 是 释放 。1 表 示 申 请 ，0 表 示 释 放 。 


start: Binder 中 虚拟 内 存 起 点 “页 表 映 射 当 然 是 从 虚拟 内 存 到 物 
HAF) 。 


end: Binder 中 虚拟 内 存 的 终点 。 
ma: 应 用 程序 中 虚拟 内 存 段 的 描述 


对 照 上 面 的 函数 传 参 会 发 现 ， 在 mmap 中 Binder 驱 动 实 际 上 只 为 进程 
分 配 了 一 页 物理 内 存 。 哩 然 它 最 大 支持 4MB 空 间 的 mmap， 但 因为 这 时 候 
还 没有 数据 传输 ， 显然 没有 必要 一 下 子 分 配 这 么 大 的 空间 。 而 且 试 想 一 
下 ， 如 果 每 个 进程 都 要 一 次 性 分 配 4MB， 那 么 25 个 进程 就 需要 消耗 100MB 
以 上 的 内 存 ， 这 对 于 一 般 的 能 入 式 设 备 来 说 是 不 现实 的 。 


成 功 分 配 了 一 页 物理 内 存 后 ， 我 们 还 需要 将 这 一 页 内 存 与 应 用 程序 
的 虚拟 内 存 联系 起 来 ， 以 真正 实现 共享 。 有 兴趣 的 读者 可 以 再 分 析 下 
binder_update_page_range 的 实现 : 


buffer = proc->buffer; 
INIT_LIST_HEAD(&proc->buffers) ; 
list_add(&buffer->entry, &proc->buffers) ; 
buffer->free = 1; // 此 内 存 可 用 
binder_insert_free_buffer(proc, buffer); 
proc->free_async_space = proc->buffer_size / 2; 
barrier(); 

proc->files = get_files_struct(current); 
proc->vma = vma; 

return 0; 


err_alloc_small_buf_failed: 
kfree(proc->pages); 
proc->pages = NULL; 
err_alloc_pages_failed: 
vfree(proc->buf fer); 
proc->buffer = NULL; 
err_get_vm_area_failed: 
err_already_mapped: 
err_bad_arg: 
printk(KERN_ERR "binder_mmap: %d %1x-%lx %s failed %d\n", 
proc->pid, vma->vm_start, vma->vm_end, failure_string 
return ret; 
}/*binder_mmap Zi i */ 


上 面 的 代码 段 对 分 配 到 的 内 存 空 间 进行 管理 ， 主要 工作 是 将 其 加 入 
相应 的 链表 中 。 在 binder_proc 中 ， 管 理 着 3 条 链表 ， 分 别 是 


e list head buffers; 








所 有 内 存 块 都 需要 在 这 里 备案 。 
e rb_root free_buffers; 

所 有 可 用 的 空闲 内 存 。 
e rb_root allocated_buffers . 

所 有 已 经 被 分 配 了 的 内 存 。 


Binder 驱 动 中 最 复杂 的 部 分 就 是 对 内 存 的 管理 ， 大 家 在 后 面 还 会 不 
断 遇 到 类 似 场景 。 


6.3.3 binder_ioctl 
这 是 Binder 接 口 函 数 中 工作 量 最 大 的 一 个 ， 它 承担 了 Binder 驱 动 的 
大 部 分 业务 。 前 面 说 过 ，Binder 并 不 提供 read () 和 write (等 常规 文件 
操作 ， 因 为 binder_ioct1 就 可 以 完全 替代 它们 。 
先 来 看 看 binder_ioct1 提 供 了 哪些 命令 ， 如 表 6-1 所 示 。 
表 6-1 binder_ioct1 支 持 的 命令 


读 写 操作 ， 可 以 用 此 命令 回 


BINDER RITE READ 、 oe 
eee Binder 读 取 或 写 入 数据 


设置 文 持 的 最 大 线程 数 。 JAA 
ayn] E 

送 请 求 ， 如 果 Binder 驱 动 发 现 

当前 的 线程 数量 已 经 超过 设 定 

值 ， 就 会 告知 Binder Server 停 

止 启动 新 的 线程 


BINDER_SET_MAX_THREADS 





Service Manager 专 用 ， 将 自己 
BINDER_SET_ CONTEXT _ MGRI 设 置 为 "Binder 大 管家 ”。 系 统 
中 只 能 有 一 个 SM 存 在 


通知 Binder 线 程 退 出 。 每 个 线 

程 在 退出 时 都 应 该 告知 Binder 

BINDER THREAD FXIT ee er dese 
= = 了 驱动， 这 样 才 能 释放 相关 资 

源 ; 否则 可 能 会 造成 内 存 泄 露 


BINDER_VERSION 获取 Binder 版 本 号 


其 中 BINDER_WRITE_READ 这 个 命令 是 重点 ， 又 分 为 若干 子 命令 ， 如 
表 6- 2 所 未。 
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表 6-2 BINDER_WRITE_READ 中 支持 的 子 命令 





这 一 组 命令 用 于 操作 引用 计数 


和 上 面 的 命令 有 关系 ， 当 
BC_INCREFS#IBC_ACQUIRI 


BC_INCREFS_DONE 
BC_ACQUIRE_DONE 发 送 


BC_ATTEMPT_ACQUIRE 目前 版 本 中 还 没有 实现 ， 会 直 
BC_ACQUIRE_RESULT EINVAL 的 错误 码 





ices * 于 Binder 的 buffer 管 理 
BC_TRANSACTION 





这 是 BINDER_WRITE _ READ! 
的 两 个 命令 ，Binder 机 制 中 客 . 
器 的 交互 基本 上 是 靠 它 们 完成 
面 会 重点 介绍 其 源码 实现 


BC_REPLY 











用 于 设置 binder looper 的 状态 ， 
考 下 一 小 节 ServiceManager 例 |- 
述 。 当 前 版 本 中 looper 共 有 如 ” 
X. 


enum { 


BINDER_LOOPER_STATE_REGISTE 
0x01, 


BINDER_LOOPER_STATE_ENTERED 
0x02, 


BINDER_LOOPER_STATE_EXITED 
0x04, 


BC_REGISTER_LOOPER BINDER LOOPER STATE INVALID 
BC _ ENTER LOOPER 0x08, 
BC_EXIT_LOOPER 


BINDER_LOOPER_STATE_WAITING 
0x10, 


BINDER_LOOPER_STATE_NEED_RE 


}; 

左边 的 三 个 命令 分 别 对 应 上 面 
型 中 的 状态 1，2，3。 要 特别 ; 
统 意义 的 状态 不 同 ， 这 里 的 状 
以 县 加 的 。 比 如 对 于 


BC_ENTER_LOOPER 的 处 理 ， 
语句 是 : 

thread->looper |= 
BINDER_LOOPER_STATE E 













这 组 命令 将 通知 目标 对 象 执行 
BC_REQUEST_ DEATH NOTIFICATION| 操 作 ， 以 及 清除 DEATH 
BC_CLEAR_DEATH NOTIFICATION IINOTIFICATION。 显 然后 者 必 
者 成 功 的 基础 上 才 有 意义 


本 小 节 中 我 们 先 不 深入 分 析 源 码 ， 因 为 缺乏 具体 情景 的 分 析 会 让 大 
家 感觉 很 枯燥 ， 不 容易 “理解 吸收 ”。 后 续 解 析 Binder Client 如 何 获 
取 ServiceManager (Binder Server) 提供 的 服务 了 时， 再 结合 代码 进行 
详细 讨论 。 


最 后 来 做 一 下 小 结 : Binder 驱 动 并 没有 脱离 Li nux 的 典型 驱动 模 
型 ， 提 供 了 多 个 文件 操作 接口 。 其 中 binder_ioct1 实 现 了 应 用 进程 与 
Binder 驱 动 之 间 的 命令 交互 ， 可 以 说 承载 了 Binder 驱 动 中 的 大 部 分 业 
务 ， 因 而 是 学 习 的 重 中 之 重 。 在 本 小 节 的 讲解 中 ， 我 们 只 列 出 了 ioctl 
所 支持 的 命令 种 类 和 含义 ， 并 对 其 中 的 BINDER_WRITE_READ 进 行 了 初步 
人 inder Client 的 实现 原理 打下 一 定 
的 基础 。 









6.4 “DNS” RSRS ServiceManager (Binder Server) 


通过 上 一 小 节 的 学 习 ， 相 信 大 家 对 Binder 驱 动 已 经 有 了 一 定 的 认 


Ho 


ServiceManager (以 下 简称 SWM) 的 功能 可 以 类 比 为 互联 网 中 
的 “DNS” 服 务 器 ，“1P 地 址 ”为 0。 另 外 ， 和 DNS 本 身 也 是 服务 器 一 
样 ，SM 也 是 一 个 标准 的 Binder Server。Binder 驱 动 中 提供 了 专门 为 SM 
服务 的 相关 命令 ， 接 下 来 将 在 这 些 基础 上 进一步 分 析 SM 的 更 多 实现 细 
TJ o 


6.4.1 ServiceManager 的 启动 


既然 是 NS， 那么 在 用 户 可 以 浏览 网 页 前 就 必须 就 位 。SM 也 是 同样 
的 道理 ， 它 要 保证 在 有 人 使 用 Binder 机 制 前 就 处 于 正常 的 工作 状态 。 那 
么 ， 具 体 来 说 它 是 什么 时 候 运 行 起 来 的 呢 ? 


我 们 很 自然 地 会 想到 应 该 是 在 init 程 序 解析 init. rc 时 启动 的 。 事 
实 的 确 如 此 。 如 下 所 示 : 


/*init.rc*/ 
service servicemanager /system/bin/servicemanager 
class core 
user system 
group system 
critical 
onrestart restart zygote 
onrestart restart media 
onrestart restart surfaceflinger 
onrestart restart drm 


KF init. rc 的 用 法 ， 请 读者 参考 本 书 系统 启动 章节 。 从 上 面 代码 
段 的 描述 可 以 看 到 ， 一 旦 servicemanager 发 生 问 题 后 重启 ， 其 他 系统 服 
务 zygote，media，surfaceflinger 和 drm 也 会 被 重新 加 载 。 


这 个 servicemanager 是 用 C/C++ 编写 的 ， 源 码 路 径 在 工程 
的 /frameworks/native/cmds/ servicemanager 目 录 中 ， 可 以 先 来 看 看 
它 的 make 文 件 : 


LOCAL_PATH:= $(call my-dir) 


include $(CLEAR_VARS) 

LOCAL_SHARED_LIBRARIES := liblog 

LOCAL_SRC_FILES := service_manager.c binder.c 

LOCAL_MODULE := servicemanager V* 生 成 的 可 执行 文件 名 为 servicemanagerx*， 
include $(BUILD_EXECUTABLE)V* 编 译 可 执行 文件 */ 


要 特别 提醒 的 是 ，servicemanager 所 对 应 的 c 文 件 是 
service_manager. c 和 binder.c。 源 码 工 程 中 还 有 其 他 诸如 
ServiceManager. cpp 的 文件 存在 ， 但 并 不 属于 SM 程序 。 


SM 本 身 的 代码 并 不 多 ， 主 要 的 文件 只 有 上 面 makefi1e 中 描述 的 两 
个 。 但 是 它 完整 地 描述 了 上 层 应 用 通过 Binder 驱 动 来 构建 一 个 Binder 
Server 的 过 程 ， 这 也 是 我 们 下 一 小 节 所 要 分 析 的 重点 。 


6.4.2 ServiceManager 的 构建 


DNS 虽然 特殊 ， 本 质 上 却 也 是 一 个 网 络 服务 器 ; 与 此 类 似 ，SM 自 身 
也 同样 是 Binder Server (在 Android 系 统 中 ，Binder Server 的 另 一 个 
常见 称谓 是 “X X Service”， 如 Media Service) 。 


先 来 看 看 SM 局 动 后 都 做 了 哪些 工作 : 


/*frameworks/native/cmds/servicemanager/Service manager.c*/ 
int main(int argc, char **argv) 


{ 
struct binder_state *bs; 
void *svcmgr = BINDER_SERVICE_MANAGER; 
bs = binder_open(128*1024); 
if (binder_become_context_manager(bs)) { /* 将 自己 设置 为 Binder“ 大 
系统 只 人 允许 一 个 ServiceManager 存 在 ， 因 而 如 果 后 面 还 有 人 让 
ALOGE("canno t become context manager (%s)\n", strerror(e 
return -1; 
} 
svemgr_handle = svcmgr; 
binder_loop(bs, svcmgr_handler); // 进 入 循环 ， 等 待 客户 的 请 求 
return 0; 
} 


首先 给 变量 svcmgr 赋 初 值 ， 宏 的 定义 如 下 : 


#define BINDER_SERVICE_MANAGER((void*) 0) 


Bi 
ht 
al 
> 


接着 调用 binder_open 打 开 Binder 设 备 。 这 个 函数 里 面 i 
他 工作 ， 稍 后 再 专门 介绍 。 


所 以 ，main 国 数 里 主要 做 了 以 下 几 件 事 : 
e 打开 Bindet 设 备 ， 做 好 初始 化 ; 
。 将 自己 设置 为 Bindet 大 管家 ; 
oH AEE. 

那么 ， 具 体 来 说 需要 做 哪些 初始 化 呢 ? 


/*frameworks/native/cmds/servicemanager/Binder.c */ 
struct binder_state *binder_open(unsigned mapsize) 


struct binder_state *bs; /* 这 个 结构 体 记录 了 SM 中 有 关于 Binder 的 所 有 企 
如 fd、map 的 大 小 等 */ 
bs = malloc(sizeof(*bs)); 











bs->fd = open("/dev/binder", O_RDWR); // 打 开 Binder 了 驱动 节点 


bs->mapsize = mapsize; //mapsize 是 SM 自己 设 的， 为 1228*1024， 即 128K 
bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs-> 


return bs; 
fail_map: 

close(bs->fd); // 关 闭 file 
fail_open: 

free(bs); 

return 0; 


关于 mmap 的 用 法 ， 在 操作 系统 章节 以 及 前 面 的 Binder 驱 动 中 都 有 过 
详细 讲解 ， 如 果 读 者 还 不 是 很 清楚 ， 请 复习 查阅 。 根 据 上 面 代码 段 中 的 
参数 设置 可 知 : 


o 由 Binder 驱 动 决定 被 映射 到 进程 空间 中 的 内 存 起 始 地 址 ; 
。 了 上 映射 区 块 大 小 为 128KB ; 

。 映射 区 只 读 ; 

。 映射 区 的 改变 是 私有 的 ， 不 需要 保存 文件 ; 

。 从 文件 的 起 始 地 址 开始 映射 。 


下 面 来 看 看 main 函 数 中 的 第 二 步 操作 ， 即 将 servicemanager 注 册 成 
Binder 机 制 的 “大 管家 ” : 


int binder_become_context_manager(struct binder_state *bs) 


{ 
} 


return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0); 


如 我 们 在 驱动 小 节 所 讲解 的 ， 只 要 向 Binder Driver Aik 
BINDER SET CONTEXT _MGR 的 ioct1 命 令 即 可 。 因 为 servicemanager 局 动 
R 能 保证 它 是 系统 中 第 一 个 向 Binder 驱 动 注册 成 “管家 ”的 程 
Fo 


所 有 准备 工作 已 经 就 绪 ，SWM 可 以 开始 等 外 部 
分 工作 才 是 SM 的 重点 和 难点 。 我 们 先 从 binder_loop () 入 手 来 看 看 SM 是 
如 何 处 理 请 求 的 (分 段 阅读 ) : 


void binder_loop(struct binder_state *bs, binder_handler func) 


{ 





int res; 
struct binder_write_read bwr; /* 这 是 执行 BINDER_WRITE_READ 命 令 所 i 
unsigned readbuf[32];/* 一 次 读 取 容 量 */ 


在 Binder Server 进 入 循环 前 ， 它 要 先 告知 Binder 驱 动 这 一 状态 变 
化 。 下 面 这 段 代 码 就 是 为 了 完成 这 项 工作 : 


bwr .write_size = 0;// 这 里 只 是 先 初 始 化 为 90， 下 面 还 会 再 赋值 
bwr.write_consumed = 0; 

bwr.write_buffer = 0; 

readbuf [0] = BC_ENTER_LOOPER;/* 命 令 */ 

binder_write(bs, readbuf, sizeof(unsigned)); // 这 个 函数 很 简单 ， 让 


然后 SM 就 进入 了 循环 。 大 家 可 以 先 想 一 想 ， 循 环 体 中 需要 做 些 什 


S 


没 错 ， 和 典型 的 基于 事件 驱动 的 程序 循环 框 染 类 似 。 


从 消息 队列 中 读 取 消息 。 

。 如 果 消 息 是 “退出 命令 ”， 则 马上 结束 循环 ， 如果 消息 为 空 ， 则 继 
续 读 取 或 者 等 待 一 段 时 间 后 再 读 取 ; 如 果 消 息 不 为 空 且 不 是 退出 命 
令 ， 则 根据 具体 情况 进行 处 理 。 


。 如 此 循环 往复 直到 退出 。 


不 过 SM 中 没有 消息 队列 ， 它 的 “消息 ” (或 称 “ 命 令 ”) 是 从 
Binder 驱 动 那 里 获得 的 : 


for (;;) { 
bwr .read_size = sizeof(readbuf);/*readbuf 的 大 小 为 32 个 unsign 
bwr.read_consumed = 0; 
bwr.read_buffer = (unsigned) readbuf;/* 读 取 的 消息 存储 到 readk 
res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); // 读 取 “ 消 息 ” 


res = binder_parse(bs, 0, readbuf, bwr.read_consumed, fun 
if (res == 0) { 

ALOGE("binder_loop: unexpected reply?!\n"); 

break; 


} 
if (res < 0) { 


ALOGE("binder_loop: io error %d %s\n", res, strerror( 
break; 


} 
} 
}/*binder_loop 结 束 */ 


由 此 可 见 ，SM 遵 循 以 下 几 个 步 又 。 
© 从 Binder 驱 动 读 取 消息 





通过 发 送 BINDER_WRITE_READ 命 令 实现 一 一 这 个 命令 既 可 读 取 也 可 
写 入 ， 具 体 要 看 bwr. wr ite_size 和 bwr. read _ size。 因 为 这 里 
write_size 的 初始 化 值 为 0， 而 read_size 为 sizeof (readbuf)， 所 以 
Binder 驱 动 只 执行 读 取 操作 。 

° 处 理 消 Ase 

调用 binder_parse 来 解析 消息 。 

。 不断 循环 ， 而 且 永 远 不 会 主动 退出 (除非 出 现 致命 错误 ) 

再 来 看 看 binder_parse 的 处 理 〈 分 段 阅读 ) : 


int binder_parse(struct binder_state *bs, struct binder_io *bio, 
uint32_t *ptr, uint32_t size, binder_handler func) 





/*func 函 数 在 SM 中 对 应 svcmgr_handler()*/ 


int r = 1; 
uint32_t *end = ptr + (size / 4); // 一 个 uint32_t 占 用 4 个 字 节 


while (ptr < end) { 
uint32_t cmd = *ptr++;/* 一 个 cmd 占 用 一 个 uint32_t， 因 而 取得 cmdj 


函数 首先 计算 数据 的 终点 Cend) ， 然 后 进入 whi le 循环 〈 直 到 所 有 
数据 处 理 完 成 ) 。 数 据 的 头 部 是 cvd， 代 表 了 程序 接 下 来 要 处 理 的 具体 
命令 一 一 其 中 BR_NOOP，BR_TRANSACT1ON_COMPLETE 以 及 操作 引用 计数 的 
一 组 命令 〈BR_INCREFS 等 ) 并 不 需要 特别 处 理 。 如 下 所 示 : 


switch(cmd) { 

case BR_NOOP: 
break; 

case BR_TRANSACTION_COMPLETE: 
break; 

case BR_INCREFS: 

case BR_ACQUIRE: 

case BR_RELEASE: 

case BR_DECREFS: 





ptr += 2; 
break; 
case BR_TRANSACTION: {/* 下 面 会 详细 分 析 这 个 命令 */ 
struct binder_txn *txn = (void *) ptr;/*binder_txn 和 B: 
transaction_data 是 类 似 的 */ 


binder_dump_txn(txn); //dump 追 踪 
if (func) { // 这 个 函数 是 svcmgr_handler()*/ 
unsigned rdata[256/4]; 
struct binder_io msg; 
struct binder_io reply; 
int res; 
bio_init(&reply, rdata, sizeof(rdata), 4); 
bio_init_from_txn(&msg, txn); 
res = func(bs，txn，&msg，&reply);/* 具 体 处 理 消息 */ 
binder_send_reply(bs, &reply, txn->data, res);/*|F 









































ptr += sizeof(*txn) / sizeof(uint32_t);/* 处 理 完成 ， 跳 过 i 
break; 


} 
case BR_REPLY: { 
struct binder_txn *txn = (void*) ptr;/*REPLY 和 TRANSAC 


“tx” 经 常 被 用 来 表示 “ 收 ” 和 “发 ”两 种 双向 操作 */ 


binder_dump_txn(txn);// 追 踪 调 试 
if (bio) { 
bio_init_from_txn(bio, txn); 
bio = 0; 
} else { 
/* todo FREE BUFFER */ 





ptr += (sizeof(*txn) / sizeof(uint32_t)); //Bkit Six 
r= 0, 
break; 
} 
}/*binder_parse 结 束 */ 
和 在 Binder 驱 动 中 的 情况 一 样 ， 我 们 要 重点 关注 下 BR_TRANSACT1ON 
和 BR_REPLY 《特别 是 前 者 〉。 


1. BR_TRANSACTION 


对 BR_TRANSACTION 命 令 的 处 理 主 要 由 func 来 完成 ， 然 后 将 结果 返回 
给 Binder 驱动 。 


为 了 保持 连贯 性 ， 我 们 紧 接着 来 看 看 func 函 数 的 实现 ， 再 分 析 
BR_REPLY 的 处 理 。 因为 ServiceManager 是 为 了 元 成 “Binder Server 
Name” (域名 ) #1 “Server Handle” (1P 地 址 ) 间 对 应 关系 的 查询 而 
存在 的 ， 所 以 可 推测 出 它 提供 的 服务 应 该 至 少 包 括 以 下 几 种 。 

e 注册 


当 一 个 Binder Server 创 建 后 ， 它 们 要 将 自己 的 [名 称 ，Binder 和 名 
柄 ] 对 应 关系 告知 SM 进 行 备案 。 


。 查询 


即 应 用 程序 可 以 向 SM 发 起 查询 请 求 ， 以 获知 某 个 Binder Server Fr 
对 应 的 句柄 。 


° 其 他 信息 查询 





比如 SM 版 本 号 、 当 前 的 状态 等 。 当 然 ， 这 一 部 分 不 是 必需 的 ， 可 以 
不 实现 。 


函数 很 长 〈 分 段 阅 读 ) : 


int svcmgr_handler(struct binder_state *bs, struct binder_txn *tx 
struct binder_io *msg, struct binder_io *reply) 
{ 


struct svcinfo *si; 
uint1i6_t *s; 

unsigned len; 

void *ptr; 

uint32_t strict_policy; 
int allow_isolated; 


if (txn->target != svcmgr_handle) //SM 的 handle 为 0 
return -1; 


strict_policy = bio_get_uint32(msg); 

s = bio_get_stringi6(msg, &len); 

if ((len != (sizeof(svcmgr_id) / 2)) || 
memcmp(Svcmgr_id, s, sizeof(svcmgr_id))) { 
fprintf(stderr,"invalid id %s\n", str8(s)); 
return -1; 


f; 


bio XXÆAJIRA ARE SAA E T ER, CAM 
具体 的 命令 来 进行 处 理 。 


e SVC_MGR_GET_SERVICE. 
e SVC_MGR_CHECK_SERVICE: 


上 面 两 个 命令 是 一 样 的 ， 都 是 根据 Server 名 称 查 找到 它 的 handle 
值 。 





e SVC_MGR_ADD_SERVICE: 
用 于 注册 一 个 Binder Server. 
e SVC MGR _ LIST SERVICES : 


获取 列表 中 的 对 应 Server 。 


如 下 所 示 : 


switch(txn->code) { 
case SVC_MGR_GET_SERVICE: 
case SVC_MGR_CHECK_SERVICE: 
s = bio_get_stringi6(msg, &len); 
ptr = do_find_service(bs, s, len, txn->sender_euid);/* 这 个 E 
护 有 一 个 全 局 的 svclist 变 量 ， 用 于 保存 所 
整个 查找 过 程 没有 涉及 很 复杂 的 逻辑 ， 因 而 我 人 














if (!ptr) 

break; 
bio_put_ref(reply，ptr);/* 保 存 查 询 结 果 ， 以 返回 给 客户 端 */ 
return Q; 


查询 的 过 程 很 简单 ， 主 要 是 调用 do_find_service 来 所 历 内 部 列 
表 ， 并 返回 目标 Server 对 象 ， 最 后 将 结果 存 入 reply 中 : 


case SVC_MGR_ADD_SERVICE: 
s = bio_get_stringi6(msg, &len); 
ptr = bio_get_ref(msg); 
allow_isolated = bio_get_uint32(msg) ? 1: 0; 
if (do_add_service(bs, s, len, ptr, txn->sender_euid, allo 








return -1; 
break; 


注册 Binder Server 的 过 程 也 类 似 : 首先 要 在 SM 所 维护 的 数据 列表 
中 查找 是 否 已 经 有 对 应 的 节点 存在 ; 否则 需要 创建 一 个 新 的 节点 来 记录 
这 个 Server 。 然 后 将 这 个 Server 中 所 带 的 信息 写 入 列表 的 相应 节点 中 ， 
以 备 后 期 查询 : 


case SVC_MGR_LIST_SERVICES: { 

unsigned n = bio_get_uint32(msg); 

si = svclist;// 所 有 Server 信 息 都 保存 于 此 

while ((n-- > 0) && si) 
si = Si->next; 

if (si) { 
bio_put_string16(reply，si->name);// 保 存 结果 
return 0; 











return -1; 


} 

default: 
ALOGE("unknown code %d\n", txn->code); 
return -1; 


Service Manager 的 功能 架构 比较 简洁 一 一 其 内 部 维护 着 一 个 
svel ist 列 表 ， 用 于 存储 所 有 Server 相 关 信 息 〈 以 svcinfo 为 数据 结 
构 ) ， 查 询 和 注册 都 是 基于 这 个 表 展 开 的 。 


水 数 svcemgr_handler 处理 完 成 后 ，binder_parse 会 进一步 通过 
binder_send_reply 来 将 执行 结果 回复 给 底层 Binder 驱 动 ， 进 而 传递 给 
客户 端 。 然 后 binder_parse 会 进入 下 一 轮 的 whi le 循环 ， 直 到 ptr < end 
为 fas le 一 一 此 时 说 明 Service Manager 上 一 次 从 驱动 层 读 取 的 消息 都 已 
处 理 完成 ， 因 而 它 还 会 继续 向 Binder Driver @IXBINDER WRITE _READLL 
查询 有 没有 新 的 消息 。 如 果 有 的 话 就 处 理 ; 否则 会 进入 休眠 等 待 。 


2. BR_REPLY 


这 样 我 们 就 完成 了 对 BR_TRANSACTION 命 令 处 理 过 程 的 分 析 。 现 在 回 

到 binder_parse 国 数 ， 接 着 往 下 看 BR_REPLY 〈 还 记得 吗 ? 我 们 之 前 是 在 

binder_parse 中 一 直 往 下 追踪 的 ) 的 处 理 ， 其 实 都 大 同 小 异 ， 所 以 下 面 
只 截取 部 分 关键 代码 : 


case BR_REPLY: { 
struct binder_txn *txn = (void*) ptr; 


if (bio) { 
bio_init_from_txn(bio, txn); 
bio = 0; 

} else 


J 

ptr += (sizeof(*txn) / sizeof(uint32_t)); 
r= 0; 

break; 





{ 
/* todo FREE BUFFER */ 


} 


可 以 看 到 ，SM 对 BR_REPLY 并 没有 实质 性 的 动作 。 这 也 是 正常 的 ， 因 
为 SM 是 为 别人 服务 的 ， 并 没有 向 其 他 Binder Server 主 动 发 起 请 求 的 情 
况 。 总 的 来 说 ，SM 的 逻辑 比较 清晰 ， 功 能 也 单一 ， 没 有 太 多 难以 理解 的 
地 方 。 而 Java 层 的 应 用 程序 在 使 用 Binder 驱动 时 就 没有 这 么 直接 ， 大 家 
在 后 面 的 几 个 小 节 中 就 可 以 体会 到 了 。 


6.4.3 获取 ServiceManager 服 务 一 isit E 


经 过 前 两 个 小 节 的 努力 ，ServiceManager 已 经 成 功 地 运转 起 来 了 。 
那么 ， 我 们 该 如 何 获取 它 所 提供 的 服务 呢 ? 准确 地 说 ， 获 取 SM 服 务 是 
Binder Client“〈 即 后 一 个 小 节 的 分 析 范 畴 ) 需要 做 的 工作 之 一 。 不 过 
SM 是 Binder Server 中 的 典型 范例 ， 以 此 为 切入 点 相信 可 以 让 读者 更 好 
地 理解 Binder 庞 大 的 “上 层 建筑 ”， 因 而 我 们 选择 在 SM 小 节 中 对 Binder 
client 进行 初步 的 解析 。 


不 少 读者 会 有 疑问 ， 既 然 SM 是 基于 native 代 码 实现 的 ， 那 么 获取 SM 
服务 是 不 是 也 必须 用 nat ive 语 言 来 实现 呢 ? 答案 就 是 一 一 它们 之 间 并 没 
有 必然 的 联系 。 换 名 话说， 所 有 Binder Client 或 者 Binder Server 都 是 
围绕 Binder 驱 动 展 开 的 ， 因 而 只 要 能 正常 使 用 Binder 驱 动 ， 采 用 哪 种 编 
程 语言 都 是 可 以 的 。 


本 小 节 主 要 讲述 Java 层 的 应 用 程序 如 何 使 用 SM 服 务 。 


如 果 读 者 之 前 分 析 过 Java 层 Binder 机 制 的 源码 ， 相 信和 会 发 现 这 其 中 
涉及 一 大 堆 描 口 的 术语 ， 如 代理 (proxy) 、 本 地 (native) 、 接 口 
(interface) 等 ;以 及 一 系列 让 人 无 比 头疼 的 BpBinder 、BnBinder、 
literface、|lbinder、aslnterface、asBinder、transaction 等 类 和 方 
法 。 从 项 目 经 验 来 看 ， 正 是 这 些 源源 不 断 涌现 出 的 费解 的 实现 方式 阻碍 
了 很 多 人 理解 和 学 习 Binder 的 脚步 。 


一 些 参 考 资料 会 直接 列 出 这 些 类 之 间 的 继承 关系 ， 从 而 组 成 一 张 庞 
大 的 类 图 。 但 其 实 这 样 的 学 习 方 式 效 果 并 不 好 ， 很 多 初学 者 看 了 之 后 更 
加 迷糊 。 所 以 本 书 希 望 找到 一 种 更 好 的 方法 ， 以 帮助 大 家 真正 地 理解 


Binder。 


总 结 市 面 上 的 一 些 教材 ， 我 们 认为 可 能 犯 了 “本 末 倒 置 ”的 错误 
一 一 即 先 给 大 家 看 了 答案 ， 然 后 才 来 讲解 问题 本 身 。 好 比 是 先 看 到 了 答 
案 一 一 10， 然 后 再 来 推断 为 什么 是 10 〈 甚 至 可 以 说 是 赶 着 “思路 ” 往 10 
这 个 方向 “ 凑 ”) 。 但 这 无 疑 是 没有 结果 的 ， 因 为 5+5=10， 但 4+6 也 同 
样 等 于 10。 因 而 可 想 而 知 ， 这 种 方法 的 最 好 结果 顶 多 是 个 别 聪明 人 真 的 
反 推 出 了 10=5+5， 但 这 并 不 一 定 是 最 好 的 答案 。 


反观 Binder 的 学 习 也 是 一 样 ， 我 们 不 应 该 一 开始 就 看 到 proxy， 
native 这 些 东 西 ， 因 为 它们 是 解决 “如 何 提供 Binder Server 服 务 ” 这 


个 问题 答案 的 一 部 分 。 正 确 的 方法 ， 或 许 应 该 从 Binder 和 SM 设计 的 角度 
出 发 ， 去 思考 如 果 要 提供 SM 的 某 个 功能 ， 则 应 该 怎么 做 。 我 相信 Binder 
的 创始 人 也 是 经 历 了 这 样 的 一 段 反 复 思 索 论证 过 程 后 才 最 终 确 定 下 来 最 
适合 Binder 机 制 的 实现 方式 的 。 


接 下 来 我 们 就 根据 前 面 几 个 小 节 学 习 的 知识 来 充分 思考 下 : 如 果 要 
访问 SM(Binder Server) 的 服务 ， 流 程 应 该 是 怎么 样 的 呢 ? 


无 非 就 是 以 下 几 步 : 


打开 Binder 设 备 ; 

执行 mmap; 

通过 Binder 驱 动向 SM 发 送 请 求 《SM 的 handle 为 0) ; 
获得 结果 。 


ER One oer 
E; 比如 : 


© 向 SM 发 起 请 求 的 Binder Client 可 能 是 Android 的 APK 应 用 程序 ， 所 以 
SM 必须 要 提供 Java 层 接口 。 
o 如 果 每 个 Bindet Client 都 要 亲 力 亲 为 地 执行 以 上 几 个 步骤 来 获取 SM 
服务 ， 那 么 可 想 而 知 会 浪费 不 少时 间 。Android 系 统 当 然 也 想到 了 
这 一 点 ， 所 以 它 会 提供 更 好 的 封装 来 使 整个 SM 调用 过 程 更 精简 实 
用 。 
如 果 应 用 程序 代码 中 每 次 使 用 SM 服务 (或 者 其 他 Binder Server 服 
务 ) ， 都 需要 打开 一 次 Bindet 驱 动 、 执 行 mmap， 其 后 果 就 是 消耗 的 
系统 资源 会 越 来 越 多 ， 直 到 甬 溃 。 一 个 有 效 的 解决 办 法 是 每 个 进程 
只 允许 打开 一 次 Bindetr 设 备 ， 且 只 做 一 次 内 存 映 射 一 一 所 有 需要 使 
用 Bindet 驱 动 的 线程 共享 这 一 资源 。 


问题 转化 为 : 如 果 让 我 们 来 设计 一 个 符合 上 述 要 求 的 Binder 
Client， 应 该 怎么 做 ? 


1. ProcessState 和 mIPCThreadState 


首先 能 想到 的 是 要 创建 一 个 类 来 专门 管理 每 个 应 用 进程 中 的 Binder 


操作 一 一 更 为 重要 的 是 ， 执 行 Binder 驱 动 的 一 系列 命令 对 上 层 用户 必 须 
= “透明 的 ” 


这 个 类 就 是 ProcessState 。 


另外 在 Binder 驱动 小 节 中 ， 我 们 看 到 binder_proc 中 有 threads 红 黑 
树 用 于 管理 该 进程 中 所 有 线程 的 1PC 业 务 。 这 说 明 仅 有 ProcessState 是 
不 够 的 ， 进 程 中 的 每 一 个 线程 都 应 该 有 与 Binder 驱 动 自由 沟通 的 权利 
而 且 基于 Binder 的 1PC 是 阻塞 的 ， 这 样 能 保证 个 别 thread 在 做 进程 
间 通 信 时 不 会 卡 死 整个 应 用 程序 。 


与 Binder 驱 动 进 行 实 际 命令 通信 的 是 I1PCThreadState。 





2. Proxy 


有 了 上 面 两 个 类 ， 应 用 程序 现在 可 以 与 Binder 驱动 通 信 了 。 原 则 上 
我 们 还 是 可 以 通过 发 送 BINDER_WRITE_READ 等 Binder 支 持 的 命令 来 与 其 
交互 ， 从 而 一 步 步 得 到 SM 提供 的 服务 。 不 过 这 样 的 做 法 显然 过 于 呆板 和 
烦琐 ， 聪 明 的 读者 一 定 能 想到 还 需要 对 SM 提 供 的 服务 进行 封装 。 


把 这 个 SM 服 务 的 封装 取 名 为 ServiceManagerProxy “字面 意思 就 
是 “SM 的 代理 ”〉 如 何 ? 代理 这 个 词 在 Binder 中 使 用 得 较 多 ， 那 么 为 什 
么 称 为 代理 呢 ? 举 个 生活 中 的 例子 可 能 会 让 大 家 更 清楚 些 。 比 如 在 中 国 
大 陆 ， 留 学 生 办 理 “ 国 外 学 历 认 证 ”原则 上 是 要 到 北京 的 教育 部 留学 服 
SAL (cscse) 的 。 我 们 假设 留学 服务 中 心 提供 的 这 个 服务 是 
cscse. getCertification(materials)， 其 中 的 materials 代 表 办 理 该 业 
务 所 要 提供 的 所 有 有 效 证 件 材料 。 由 于 留学 生 很 可 能 居住 在 全 国 各 地 ， 
很 少 有 人 能 专门 前 往 北 京 办 理 。 为 了 解决 这 个 问题 ， 服 务 中 心 便 在 各 大 
城市 都 设立 了 自己 的 代理 点 ， 即 cscseproxy。 这 些 代理 点 为 留学 生 提 供 
的 是 本 地 的 服务 (Proxy 和 其 使 用 者 是 在 同一 个 进程 中 的 ) 。 而 在 业务 
办 理 上 ， 如 材料 的 要 求 方面 ， 服 务 中 心 和 所 有 办 理 点 的 标准 肯定 是 一 样 
的 ， 即 它们 已 经 设 定 了 统一 的 1cscse 接 口 。 


现在 代理 点 正常 营业 了 了， 那么 它 提供 的 接口 是 怎样 的 呢 ? 
没 错 ， 是 cscseproxy. getCertification(materials)， 而 且 


materials 和 cscse 的 要 求 也 一 定 是 完全 一 致 的 。 对 于 留学 生 而 言 ， 他 们 
通过 本 地 的 代理 就 成 功 实现 了 与 远 在 北京 的 留学 中 心 的 “ 跨 进 程 ” 交 


互 。 最 关键 的 是 ， 那 些 烦 琐 的 中 间 流 程 是 不 需要 他 们 关心 的 ， 因 为 代理 
提供 的 接口 和 服务 中 心 的 接口 并 没有 任何 区 别 。 


要 设计 ServiceManagerProxy， 首 先 要 明确 我 们 要 的 最 终 效 果 是 怎 
样 的 ， 即 设计 目标 的 设 定 。 既 然 是 封装 ， 当 然 是 希望 提高 这 个 模块 与 其 
他 模块 的 无 关 性 和 便利 性 。 比 如 下 面 的 伪 代 码 就 给 出 了 一 个 很 好 的 例 
子 ， 描 述 了 应 用 程序 如 何 通 过 ServiceManagerProxy 来 快速 获取 SM 服 务 
(这 个 例子 是 通过 SM 来 查询 WindowManagerService 的 Binder 句 柄 。 注 
意 : 下 面 的 代码 只 是 示范 代理 可 以 做 成 什么 样子 ， 和 Android 系 统 中 真 
正 的 ServiceManagerProxy 实 现 略 有 差异 ) : 


/* 应 用 程序 获取 SM 服务 示例 */ 
//Step1. 创建 ServiceManagerProxy 
ServiceManagerProxy sm = new ServiceManagerProxy(new BpBinder (HAN 





//Step2， 通 过 ServiceManagerProxy 获 取 SM 的 某 项 服务 
IBinder wms_binder = sm.getService("window"); 


,也 就 是 党 ， 应 用 程序 只 需要 两 步 束 可 以 得 到 ServiceManager 提 供 的 
服务 。 


上 面 的 代码 示例 的 确 可 以 给 调用 者 市 来 便利 ， 接 下 来 的 难点 就 是 如 
何 实现 这 个 目标 了 。 


(1) ServiceManagerProxy 的 接口 。ServiceManagerProxy 所 能 提 
供 的 服务 和 服务 端的 SM 必须 是 一 致 的 ， 如 getService，addService 等 。 
把 这 些 方 法 提取 出 来 ， 就 是 ServiceManagerProxy 的 接口 。 我 们 给 它 取 
名 为 1ServiceManager， 如 下 所 示 〈 大 家 先 忽 略 它 的 参数 ) : 


public interface IServiceManager 


{ 
public IBinder getService(String name) throws RemoteExceptio 
public IBinder checkService(String name) throws RemoteExcept 
public void addService(String name, IBinder service, boolean 
public String[] listServices() throws RemoteException; 

} 


很 显然 ，ServiceManagerProxy 需 要 继承 自 1ServiceManager ， 如 图 
6-15 所 示 。 










IServiceManager 


+getService() 


+listServices() 


/\ 
ServiceManagerProxy 






全 图 6-15 继承 自 IServiceManager 


(2) 接口 实现 。 以 getServi ce 为 例 ， 要 取得 ServiceManager 的 这 

个 服务 ， 至 少 有 两 部 分 工作 。 
e 与 Bindet 建 立 关系 

因为 进程 中 已 经 有 了 ProcessState 和 1PCThreadState 这 两 个 专门 与 
Binder 驱 动 通 信 的 类 ， 所 以 Java 层 代码 使 用 Binder 驱 动 实 际 上 是 基于 它 
们 来 完成 的 。 我 们 称 为 BpBinder。 

e 向 Binder 发 送 命令 ， 从 而 获得 SM 提供 的 服务 。 

这 样 以 Service Manager 为 例 ， 便 从 设计 层面 思考 了 Binder 机 制 
的 “上 层 建 筑 ” 实 现 。 和 希望 大 家 在 后 续 小 节 的 源码 分 析 中 ， 可 以 紧 紧 抓 
住 本 小 节 推 导出 的 设计 思想 ， 否 则 很 容易 迷失 方向 。 

总 结 如 下 : 

Binder 机 制 确 实 是 太 繁杂 了 ， 它 不 仅 涉及 Binder 驱 动 ， 而 且 还 需要 
同时 为 Java，C/C++ 等 各 个 系统 层 服务 ， 所 以 各 种 类 名 和 概念 层出不穷 
HHA REA “URHE” KÉR- ATAL. 

为 了 让 大 家 更 好 地 理解 Binder 原 理 ， 我 们 在 这 一 小 节 中 尽 可 能 采用 
引导 式 的 讲解 万 法 ， 通 过 问题 思考 解答 来 尽 可 能 还 原 Binder 设 计 者 的 意 
图 。 到 目前 为 止 ， 读 者 应 该 至 少 明 白 了 以 下 内 容 。 


e Binder 架 构 





它 的 主体 包括 驱动 、SM、Binder Client 和 Binder Server。 通 过 与 
经 典 的 TCP/1P 服 务 类 比 ， 我 们 不 难 理解 每 个 模块 的 功能 。 


e Binder3k a 


驱动 是 其 他 元 素 的 基础 。 这 一 部 分 内 容 虽 然 代 码 较 多 ， 但 并 不 算 复 
杂 ， 只 要 用 心 去 看 一 定 可 以 理解 透彻 。 


e Service Manager 


SM 既是 Binder 框 架 的 支撑 者 ， 同 时 也 是 一 个 标准 的 Server 。 因 而 我 
们 以 它 为 例 向 大 家 阐述 了 Binder Server 的 设计 理念 。 在 这 一 过 程 中 出 
现 了 很 多 对 象 〈 如 Proxy) ， 不 过 都 没有 给 出 具体 的 源码 “代码 一 多 ， 
大 脑 堆 栈 太 深 就 容易 浇 出 〉。 


可 以 用 一 张 图 来 概括 Binder 机 制 ， 如 图 6-16 所 示 。 


\ ] 
站 入 
Client ste | 







ServiceManagerProxy 


BpBinder 
[PCThreadState 


Linux Kernel | 
dev/binder 


全 图 6-16 获取 SM 服务 (主要 组 成 元 素 ) 


图 6-16 中 Client 表 示 Binder Client， 即 使 用 Binder 机 制 来 获取 服 
务 的 客户 端 。 它 的 内 部 结构 由 下 而 上 依次 为 
ProcessState/|IPCThreadState—BpBinder->Proxy User. FICE 
Client 或 者 Service Manager， 它 们 的 工作 都 是 基于 Binder Driver 完 成 
的 。 该 图 摘 绘 了 Binder 模 型 中 “上 层 建筑 ”的 各 个 组 成 元 素 ， 如 果 大 家 
eee as 请 回 到 这 里 再 次 理 顺 它们 所 扮演 的 角 


接 下 来 我 们 就 结合 源码 〈 以 Service Manager 的 getService 服 务 为 
重点 贯穿 整个 分 析 过 程 ) 分 别 介 绍 ServiceManagerProxy、Binder 封 装 
以 及 ProcessState/1PCThreadState 等 。 


6.4.4 ServiceManagerProxy 


前 一 小 节 思 考 “ 设 计 意 图 ”时 ， 我 们 曾 通 过 一 小 段 伪 代码 描述 了 
ServiceManagerProxy 的 一 种 实现 方案 Android 系 统 中 的 具体 实现 与 
此 基本 类 似 ， 只 不 过 它 在 ServiceManagerProxy 上 又 加 了 一 层 封 装 ， 即 


ServiceManager. java. 


这 样 应 用 程序 使 用 ServiceManager 就 更 加 方便 了 ， 连 
ServiceManagerProxy 对 象 都 不 用 创建 ， 如 下 所 示 : 


ServiceManager .getService(name) ; 


因为 ServiceManager 中 的 所 有 服务 接口 都 是 static 的 ， 因 而 用 户 不 
需要 额外 创建 任何 类 对 象 就 可 以 直接 使 用 SM 的 功能 。 我 们 来 看 看 
getService 的 内 部 实现 。 





/*frameworks/base/core/java/android/os/ServiceManager. java*/ 
public static IBinder getService(String name) { 


try { 
IBinder service = sCache.get(name) ;// 查 询 缓存 
if (service != null) { 
return service;// 从 缓存 中 找到 结果 ， 直 接 返 回 
} else { 


return getIServiceManager().getService(name) ;// 


Í 


} catch (RemoteException e) { 
Log.e(TAG, "error in getService", e); 
} 


return null; 


} 


这 个 函数 的 逻辑 很 简单 ， 其 中 sCache 用 于 记录 getService 的 历史 查 
询 结 果 一 一 所 以 程序 每 次 都 会 首先 到 这 里 翻阅 记录 ， 以 加 快 查询 速度 。 
如 果 不 存在 的 话 ， 才 会 调用 get1ServiceManager (). getService 发 起 一 
条 查询 请 求 : 


private static IServiceManager getIServiceManager() { 
if (sServiceManager != null) { 
return sServiceManager;// 返 回 一 个 IServiceManager 对 象 


// Find the service manager 
sServiceManager =ServiceManagerNative.asIinterface(BinderIn 
return sServiceManager; 


} 


程序 首先 判断 sServiceManager 是 否 为 定 ， 以 防止 多 次 重复 操作 。 
如 果 是 第 一 次 使 用 SM， 则 调用 
ServiceManagerNative.aslnterface (Binder Internal. getContextOb jec 
来 获取 一 个 1ServieManager 。 到 目前 为 止 ， 我 们 还 是 没有 看 到 
ServiceMangerProxy， 不 过 出 现 了 一 个 新 的 类 ServiceManagerNative: 


/*frameworks/base/core/java/android/os/ServiceManagerNative. 
static public IServiceManager asInterface(IBinder obj) 


if (obj == null) { 
return null; 


IServiceManager in = (IServiceManager )obj .queryLocalInter 
if (in != null) { 
return in; 


return new ServiceManagerProxy(obj); 


J 


从 这 个 函数 的 注释 可 以 发 现 ， 它 负责 将 一 个 Binder 对 象 转换 成 
IlServiceManager， 并 在 必要 的 时 候 创 建 ServiceManagerProxy。 


这 里 的 1Binder 对 象 “obj) 是 通过 


Binder Internal. getContextOb ject () 得 到 的 ， 我 们 先 不 深究 其 内 部 实 
现 ， 把 它 当 成 与 底层 Binder 沟 通 的 工具 即 可 。 也 数 的 处 理 逻 辑 分 为 以 下 
两 部 分 。 


e queryLocallnterface 
查询 本 地 是 否 已 经 有 1ServiceManager 存 在 。 
。 如 果 没 有 查询 到 ， 则 新 建 一 个 ServiceManagerProxy 


这 一 小 节 的 主角 终于 出 现 了 ， 作 为 SM 的 代理 ， 可 想 而 知 
ServiceManagerProxy 必 定 是 要 与 Binder 驱动 通信 的 ， 因 而 它 的 构造 涪 
数 中 传 入 了 1Binder 对 象 : 


public ServiceManagerProxy(IBinder remote) { 
mRemote = remote; 
} 


可 以 看 到 ， 它 只 是 简单 地 记录 了 这 个 1Binder 对 象 。 这 就 像 我 们 电 
话 订 餐 一 样 ，1Binder 是 餐馆 的 电话 号 码 ， 通 常 都 是 先 把 它 记 下 来 ， 等 
需要 的 时 候 再 通过 这 个 号 码 获取 餐馆 提供 的 服务 。 比 如 getService () 这 
个 接口 : 


public IBinder getService(String name) throws RemoteException 
Parcel data = Parcel.obtain(); 
Parcel reply = Parcel.obtain(); 
data.writeInterfaceToken(IServiceManager.descriptor ) ; 
data.writeString(name); 
mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0); 


IBinder binder = reply.readStrongBinder(); 
reply.recycle(); 

data.recycle(); 

return binder; 





t 
这 个 函数 实现 分 为 以 下 3 部 分 。 
。 准备 数据 


也 就 是 通过 Parce1 打 和 包 数 据 。 在 前 面 的 小 节 对 Parce1 有 专门 的 介 


绍 ， 不 清楚 的 读者 可 以 回头 看 看 。 
e [Binder.transact 


利用 1Binder 的 transact 将 请 求 发 送出 去 ， 而 不 用 理会 Binder 驱 动 
的 open，mmap 以 及 一 大 堆 具 体 的 Binder 协 议 中 的 命令 。 所 以 这 个 
1Binder 一 定 会 在 内 部 使 用 ProcessState 和 1PCThreadState 来 与 Binder 
驱动 进行 通信 。 


。 获取 结果 


上 面 transact 后 ， 我 们 就 可 以 直接 获取 到 结果 了 。 如 果 大 家 用 过 
socket， 就 知道 这 是 一 种 阻塞 式 的 函数 调用 。 因 为 涉及 进程 间 通 信 ， 结 
果 并 不 是 马上 就 能 获取 到 ， 所 以 Binder 驱 动 一 定 要 先 将 调用 者 线程 挂 
起 ， 直 到 有 了 结果 才能 把 它 唤 醒 。 这 样 做 的 好 处 就 是 调用 者 可 以 像 进程 
内 函数 调用 一 样 去 编写 程序 ， 而 不 必 考 虑 很 多 1PC 的 细节 。 后 面 我 们 还 
会 做 详细 分 析 。 


是 不 是 很 简单 ? 实际 工作 只 有 下 面 这 句 : 


mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0); 


很 多 内 部 细节 都 已 经 隐藏 起 来 了 。 这 里 需要 注意 一 下 ， 就 是 客户 端 
和 服务 器 端 所 使 用 的 业务 代码 要 一 致 ， 如 上 面 的 
GET SERVICE TRANSACTION. EAI ME: 
int GET_SERVICE_TRANSACTION = IBinder.FIRST_CALL_TRANSACTION; 
按照 |Binder 的 定义 : 


int FIRST_CALL_TRANSACTION = 0x00000001; 


所 以 这 个 业务 码 是 1。 
Fak AService manager.c 中 的 业务 码 说 明 : 
enum { 


SVC_MGR_GET_SERVICE = 1，// 对 应 的 就 是 上 面 的 那个 业务 
SVC_MGR_CHECK_SERVICE, 
SVC_MGR_ADD_ SERVICE, 
SVC_MGR_LIST_SERVICES, 
}; 


这 样 客户 端 与 服务 器 端的 业务 代码 就 保持 一 致 了 。 值 得 一 提 的 是 ， 
ServiceManger 这 个 Binder Server 比 较 特 殊 一 一 它 主 动 提供 了 上 面 这 个 
enum 结 构 来 定义 业务 码 。 通 常情 况 下 ， 使 用 AlDL 产 生 的 Binder Server 
会 自动 生成 这 些 业 务 码 ， 而 不 需要 手工 编写 。 


6.4.5 |Binder 和 BpBinder 


我 们 的 目标 是 为 应 用 程序 使 用 ServiceManager 服 务 提 供 便利 的 实现 
一 一 其 中 的 核心 是 ServiceManagerProxy， 其 外 围 又 包装 了 
ServiceManager. java 和 ServiceManagerNative， 这 些 都 在 上 一 小 节 介 
绍 过 。 


在 创建 ServiceManagerProxy 时 ， 传 入 了 一 个 1Binder 对 象 ， 然 后 借 
助 于 它 的 transact 方 法 ， 可 以 方便 地 与 Binder 驱 动 进行 通信 。 那 么 ， 
lIBinder 内 部 是 如 何 实现 的 ? 这 就 是 本 小 节 的 讲解 重点 。 


和 ServiceManagerProxy 一 样 ， 用 户 希 望 能 通过 尽 可 能 精简 的 步骤 
来 使 用 Bi nder 的 功能 。Binder 提 供 的 功能 可 以 统一 在 1Binder 中 表示 ， 
至 少 要 有 如 下 接口 方法 : 


/*frameworks/base/core/java/android/os/IBinder .java*/ 
public interface IBinder { 
public IInterface queryLocalInterface(String descriptor); 
public boolean transact(int code, Parcel data, Parcel reply, 
throws Remote Exception; 


此 外 ， 还 应 该 有 获取 1Binder 对 象 的 一 个 类 ， 即 Binder Internal. 
提供 的 相应 方法 是 : 


/*frameworks/base/core/java/com/android/internel/os/BinderInterna 
public class BinderInternal { 
public static final native IBinder getContextObject(); 


大 家 一 定 注意 到 了 ， 这 个 方法 是 native 的 。 因 为 和 Binder 驱 动 打 交 
道 ， 最 终 都 得 通过 JN1 调 用 本 地 代码 来 实现 。 这 样 我 们 还 得 写 JN1 层 的 
Binderlnternal， 如 下 所 示 : 


/*frameworks/base/core/jni/android_util_Binder.cpp*/ 
static jobject android_os_BinderInternal_getContextObject (JNIEnv* 


{ 
sp<IBinder> b = ProcessState: :self()->getContextObject(NULL); 


return javaObjectForIBinder(env, b); 


有 的 读者 可 能 会 奇怪 为 什么 取 名 为 Context0bject 呢 ? Context 
即 “ 背 景 、 上 下 文 ”， 这 里 可 以 理解 为 运行 时 态 的 上 下 文 。 换 句 话说 ， 
ee ee 更 进一步 ， 基 
本 上 每 个 Process 都 需要 1PC 通 信 。 既 然 如 此 ，1PC 就 可 以 作为 进程 的 基 
础 配置 存在 。 作 为 1PC 中 的 基础 元 素 之 一 ，Binder 就 是 这 个 Context 中 的 
重要 一 环 ， 因 而 称 为 Context0b ject. 


_ 我 们 再 回 到 getContext0bject 这 个 万 法 中 来 。 和 预想 的 一 ig 它 确 
实 是 通过 ProcessState 来 实现 的 ， 后 一 个 小 节 会 做 具体 分 析 。 然 后 把 


ProcessState 中 创建 的 对 象 转化 成 Java 层 的 1Binder 对 象 。 


IBinder 只 是 一 个 接口 类 ， 显 然 还 会 有 具体 的 实现 类 继承 于 它 。 在 
Native 层 ， 这 就 是 BpBinder (BpBinder. cpp): 而 在 Java 层 ， 则 是 
Binder. java 中 的 BinderProxy。 事 实 上 ,ProcessState::self() - 
>getContext0bject (NULL) 返回 的 就 是 一 个 BpBinder 对 象 。 图 6-17 描 述 
了 它们 的 关系 。 





[Binder(native) 


A 6-17 BinderProxy 和 BpBinder 的 关系 简 图 


BinderProxy 和 BpBinder 分 别 继承 自 Java 和 Nat ive 层 的 1Binder 接 
口 。 其 中 BpBinder 是 由 ProcessState 创 建 的 ， 而 BinderProxy 是 由 
java0b jectFor1Binder () 国 数 通 过 JN1 的 New0b ject () 创建 的 。 


下 面 看 看 调用 mRemote->transact 时 的 实现 : 
/*frameworks/base/core/java/android/os/Binder.java*/ 
final class BinderProxy implements IBinder { 


public native boolean transact(int code, Parcel data, Parcel 
int flags) throws RemoteException; 


BinderProxy 中 的 transact 就 是 一 个 native 接 口 ， 真 正 的 实现 还 是 
在 android_util_Binder. cpp 中 〈 这 个 文件 容纳 了 很 多 类 的 实现 ， 因 而 
显得 很 杂 ) 


static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobj 
jint code, jobject dataObj, jobject replyObj, jint flags) 
{ 
Parcel* data = parcelForJavaObject(env, dataObj); 
Parcel* reply = parcelForJavaObject(env, replyObj); 
IBinder* target = (IBinder*)env->GetIntField(obj, gBinderProx 
status_t err = target->transact(code, *data, reply, flags); 
SignalExceptionForError(env, obj, err, true /*canThrowRemoteE 


return JNI_FALSE; 
}/*android_os_BinderProxy_transact 44 R */ 





传 参 中 的 data0bj 和 reply0bj 分 别 对 应 BinderProxy. transact PAY 
第 >?、3 个 参数 〈 即 Parcel data 和 Parcel reply) ， 需 要 先 把 它们 转 成 
native 中 的 Parce| 实 现 。 


可 以 猜想 到 的 是 ， 前 面 通过 java0bjectFor1Binder 将 一 个 BpBinder 
转化 成 BinderProxy， 这 里 一 定 会 做 反 向 转化 。 全 局 变量 
gBinderProxy0ffsets. m0bject 记 录 的 是 BinderProxy 中 m0bject 的 
jfieldlID， 后 面 就 可 以 通过 JN1 的 Get1ntFie1d 来 获得 这 个 int 值 了 ， 即 
BpBinder 对 象 的 内 存 地 址 (可 以 参考 本 书 JNI 章 节 的 介绍 ) 。 


最 后 就 是 通过 BpBinder. transact 来 处 理 用 户 的 Binder 请 求 : 


/*frameworks/native/libs/binder/BpBinder .cpp*/ 
status_t BpBinder::transact(uint32_t code, const Parcel& data, Pa 


// Once a binder has died, it will never come back to life. 
if (mAlive) { 
status_t status=IPCThreadState: :self()->transact(mHandle, 
if (status == DEAD_OBJECT) mAlive = 0; 
return status; 


} 
return DEAD_OBJECT; 


此 时 发 现 绕 了 个 大 大 的 圈子 ， 最 终 还 是 通过 1PCThreadState 及 
ProcessState 来 实现 的 ， 这 也 验证 了 我 们 之 前 的 设想 。 因 为 Android 既 
有 Java 应 用 程序 ， 又 有 Native 层 实现 ， 所 以 导致 整个 结构 看 起 来 非常 复 
杂 。 我 们 在 下 一 小 节 会 详细 讲解 这 两 个 类 的 实现 。 


6.4.6 ProcessState 和 1PCThreadState 
本 小 节 将 重点 分 析 ProcessState 和 1PCThreadState。 
其 中 实现 ProcessState 的 关键 点 在 于 。 


。 保证 同一 个 进程 中 只 有 一 个 ProcessState 实 例 存 在 ; 而 且 只 有 在 
ProcessState 对 象 创建 时 才 打 开 Binder 设 备 以 及 做 内 存 映 射 。 

。 向 上 层 提供 IPC 服 务 。 

e 与 IPCThreadState 分 工 合 作 ， 各 司 其 职 。 


以 下 是 ProcessState 的 源码 路 


径 : /frameworks/native/| ibs/binder. 


第 一 个 问题 很 好 解决 ， 源 代码 如 下 所 示 : 


/*/frameworks/native/libs/binder/ProcessState.cpp*/ 
sp<ProcessState> ProcessState::self() 
{ 
Mutex: :Autolock _1(gProcessMutex); 
if (gProcess != NULL) { 
return gProcess; 
} 


gProcess = new ProcessState;// 创 建 对 象 
return gProcess; 





从 上 面 的 代码 段 可 以 知道 ， 访 问 ProcessState 需 要 使 用 
ProcessState: :Self () 。 如 果 当 前 已 经 有 实例 〈gProcess 不 为 空 ) F 
在 ， 就 直接 返回 这 个 对 象 ; 否则 ， 新 建 一 个 ProcessState。 它 的 构造 函 
数 如 下 : 


ProcessState: :ProcessState() 
: mDriverFD(open_driver()) // 要 注意 这 里 “ 别 有 洞 天 7 
, mVMStart(MAP_FAILED), mManagesContexts(false) 
, mBinderContextCheckFunc(NULL), mBinderContextUserData(NULL ) 
, mThreadPoolStarted(false), mThreadPoolSeq(1) 








{ 
if (mDriverFD >= 0) { // 成 功 打开 /dev/binder 
#if !defined(HAVE_WIN32_IPC) 
mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE 
mDriverFD, 0); /* 开 始 执行 nmap， 内存 块 大 小 为 : 
BINDER_VM_SIZE=((1*1024*1024) - (4096 
#else 
mDriverFD = -1; 
#endif 
} 


ProcessState 的 构造 浮 数 中 初始 化 了 很 多 变量 一 一 最 重要 的 是 ， 它 
调用 open_driver (0) 打开 了 /dev/binder 节 点 。 我 们 再 复习 一 下 使 用 
Binder 驱 动 所 需要 做 的 准备 工作 : 首先 是 打开 binder 节 点 ， 然 后 执行 
mmap () 一 一 具体 而 言 ， 映 射 的 内 存 块 大 小 为 BINDER_VM_S1ZE。 


前 面 小 节 中 我 们 在 获取 1Binder 时 使 用 了 Binderlnternal 中 的 
getContext0b ject () ， 这 个 方法 最 终 的 实现 就 是 在 ProcessState 中 。 如 
下 所 示 : 


sp<IBinder> ProcessState: :getContextObject(const sp<IBinder>& cal 


{ 
} 


return getStrongProxyForHandle(0); //4#A0, {t#Service Manager 


接着 看 下 面 的 函数 实现 : 


sp<IBinder> ProcessState: :getStrongProxyForHandle(int32_t handle) 
{ 





sp<IBinder> result; // 需 要 返回 的 ILBinder 
AutoMutex _1(mLock); 


handle_entry* e = lookupHandleLocked(handle) ;/* 查 找 一 个 Vector 表 mHan 





这 里 保存 了 这 个 进程 己 经 建立 的 E 
if (e != NULL) { /如 果 上 面 的 表 中 没有 找到 相应 节点 ， 会 自动 添加 一 个 。 
所 以 这 里 的 变量 e 正 常情 况 下 都 不 会 为 空 * 
IBinder* b = e->binder; 
if (b == NULL || le->refs->at tempt Incweak(this) ) { 
b = new BpBinder(handle); //BpBinder HE Y 
e->binder = b; 
if (b) e->refs = b->getWeakRefs(); 
result = b; 
} else { 
result.force_set(b); 
e->refs->decWeak(this); 
} 
} 


return result; 

















通过 上 面 的 代码 ， 我 们 知道 ProcessState 中 有 一 个 全 局 列表 来 记录 
所 有 与 Binder 对 象 相 关 的 信息 ， 而 每 个 表 项 是 一 个 handle_entry， 包 含 
了 如 下 数据 : 


struct handle entry { 
IBinder* binder; 
RefBase: :weakref_type* refs; 


}; 
其 中 的 binder 属 性 实际 上 是 一 个 BpBinder， 而 且 程序 只 有 在 以 下 两 
种 情况 下 才 会 生成 一 个 BpBinder 。 


。 在 列表 中 没有 找到 对 应 的 BpBinder。 
。 虽然 从 列表 中 查找 到 了 对 应 的 节点 ， 但 是 没有 办 法 顺利 对 这 
BpBinder 增 加 weak reference。 





BpBinder 在 之 前 的 Binder 封 装 中 已 经 介绍 过 ， 它 是 Native 层 的 
Binder 代 理 ， 最 后 会 由 java0bjectFor1Binder 转 化 为 Java 层 的 
BinderProxy。 我 们 来 看 看 它 的 构造 水 数 : 


/*BpBinder .cpp*/ 
BpBinder: :BpBinder(int32_t handle) 
: mHandle(handle) // 如 果 是 SM，handle 为 0 
, mAlive(1), mObitsSent(0), mObituaries(NULL) 


extendObjectLifetime(OBJECT_LIFETIME_WEAK); 


IPCThreadState: :self()->incWeakHandle(handle); 
} 


我 们 在 这 个 构造 函数 中 看 到 了 一 个 熟悉 的 智能 指针 的 设置 方法 ， 即 
extend0b jectLifetime (OBJECT LIFETIME _WEAK) ， 说 明 这 个 BpBinder 
一 定 会 继承 于 提供 引用 计数 的 基 类 。 具 体 而 言 ，BpBinder 的 父 类 是 
lbinder。 而 后 者 : 


class IBinder : public virtual RefBase 


可 见 BpBinder 所 使 用 的 引用 计数 基 类 是 RefBase， 它 同时 支持 强 弱 
两 种 引用 计数 。 在 这 里 设置 了 OBJECT_LIFETIME_WEAK， 表 示 目 标 对 象 的 
生命 周期 受 弱 指针 控制 。 这 样 ProcessState:: getContext0bject 就 得 
到 了 一 个 BpBinder， 并 且 其 中 的 mHandle 代 表 了 这 个 Proxy 的 主人 “比如 
SM 就 是 0) ， 之 后 传递 给 C1ient 时 才 转 换 成 lBinder。 


IPCThreadState 又 是 什么 时 候 出 场 的 呢 ? 可 以 这 么 说 ， 有 需要 的 时 
候 才 会 创建 。 为 了 和 ProcessState 一 样 保 持 “ 单 实例 ”， 我 们 也 需要 通 
过 1PCThreadState: :self (来 访问 它 一 一 只 不 过 前 者 是 “进程 中 的 单 实 
例 ”， 而 后 者 是 “线程 中 的 单 实 例 ”。 


我 们 知道 ， 同 一 个 进程 中 的 全 局 变量 是 可 以 在 多 个 线程 中 访问 到 
的 。 这 种 做 法 一 方面 给 程序 带 来 了 便利 ， 另 一 方面 也 有 其 劣势 。 比 如 访 
问 这 些 变 量 需 要 同步 机 制 的 配合 ， 在 一 定 程度 上 降低 了 执行 效率 。 另 
外 ， 有 的 变量 则 希望 只 在 本 线程 内 是 全 局 的 ， 其 他 线程 是 无 法 访问 到 的 
显然 纯粹 的 全 局 变量 无 法 满足 这 个 要 求 。 

TLS (Thread Local Storage) 机 制 就 是 为 了 解决 上 述 这 个 问题 而 
提出 来 的 。 它 能 保证 某 个 变量 仅 在 自己 线程 内 访问 有 效 ， 而 其 他 线程 中 
得 到 的 是 这 个 变量 的 独立 复 本 ， 互 不 干扰 : 


/*frameworks/native/libs/binder/IPCThreadState.cpp*/ 
IPCThreadState* IPCThreadState::self() 





if (gHaveTLs) { // 这 个 变量 的 初始 值 为 false 
restart: // 当 启用 TLS 后 ， 重 新 回 到 这 
const pthread_key_t k = gTLS; 
IPCThreadState* st = (IPCThreadState* )pthread_getspecific( 
if (st) return st; 
return new IPCThreadState; 


if (gShutdown) return NULL; 


pthread_mutex_lock(&gTLSMutex ) ; 
if (!gHaveTLS) { 
if (pthread_key_create(&gTLS, threadDestructor) != 0) { 
pthread_mutex_unlock(&gTLSMutex) ; 
return NULL; 


} 
gHaveTLS = true; // 以 后 都 是 TLS 了 


pthread_mutex pe ire se 
goto restart;// 返 回 restart 接 着 执行 


我 们 来 仔细 分 析 上 面 这 个 函数 的 逻辑 。 


当 第 一 次 被 调用 时 ，gHaveTLS 为 false， 因 而 不 会 进入 第 一 个 if 判 
断 中 ， 也 不 会 创建 1PCThreadState。 但 是 随后 它 就 会 进入 第 二 个 if 判断 
并 启动 TLS$， 然 后 返回 restart 处 新 建 一 个 1PCThreadState。 当 以 后 再 被 
调用 时 ，gHaveTLS 为 true: 如 果 本 线程 已 经 创建 过 |PCThreadState， 那 
Zpthread_getspecifich DAT; 否则 返回 一 个 新 建 的 
IPCThreadState. 


这 样 我 们 就 有 效 地 保证 了 “线程 单 实例 ”的 目的 。 

下 面 来 看 看 I1PCThreadState 的 构造 函数 以 及 几 个 重要 变量 : 
IPCThreadState::IPCThreadState() 

: mProcess(ProcessState::self())，//ProcessState 整 个 进程 只 有 一 个 


mMyThreadId(androidGetTid())，// 当 前 的 线程 id 
mStrictModePolicy(0), mLastTransactionBinderFlags(0) 





pthread_setspecific(gTLS, this); 
CclearCaller(); 
mIn.setDataCapacity(256); /*mIn 是 一 个 Parcel， 从 名 称 可 以 看 出 来 ， 
Binder 发 过 来 的 数据 的 ， i © 
mOut.setDataCapacity(256); /*m0ut 也 是 一 个 Parcel， 它 是 用 于 存储 要 发 i 
的 命令 数据 的 ， 最 大 容量 为 256*/ 








前 面 BpBinder 构 造 函 数 的 最 后 调用 了 1PCThreadState 的 
incWeakHandle 用 于 增加 Binder Service 的 弱 引 用 计数 值 〈 这 里 指 
Service Manager) ， 它 实际 上 是 向 Binder 驱 动 发 送 了 一 个 BC_1NCREFS 


命令 。 如 下 所 示 : 
void IPCThreadState: :incWeakHandle(int32_t handle) 


LOG_REMOTEREFS("IPCThreadState: :incWeakHandle(%d)\n", handle) 
mOut .writeInt32(BC_INCREFS); 
mOut .writeInt32(handle); 


除 此 之 外 ， 还 有 decWeakHandle，incStrongHandle， 
decStrongHandle 来 与 Binder 协 议 中 的 其 他 命令 相对 应 。 


IPCThreadState 负 责 与 Binder 驱 动 进行 具体 的 命令 交互 
(ProcessState 只 是 负责 打开 了 Binder 节 点 并 做 mmap) ， 因 而 它 的 
transact 范 数 非常 重要 。 下 面 我 们 就 看 看 其 内 部 的 实现 〈 分 段 阅 读 ) : 


status_t IPCThreadState: :transact(int32 t handle, uint32_t code, 
Parcel* reply, uint32_t flags) 
{ 


大 家 还 记得 吗 ? 我 们 一 直 是 以 ServiceManager 提 供 的 getService () 
方法 为 线索 来 追踪 代码 的 。 到 目前 为 止 调用 流程 是 这 样 的 : 

getService@ServiceManagerProxytransact@BinderProxy™trans 
ThreadState. 


€txXtgetService, transact HKA REKSANE: 


e handle 是 0; 
e code} GET_SERVICE_TRANSACTION; 


e data. 


getService@ServiceManagerProxy 国 数 中 对 data 的 操作 代码 摘录 如 
下 : 


data.writeInterfaceToken (IServiceManager .descriptor); 
data.writeSstring(name);/* 这 里 的 name 是 指 要 查询 的 服务 名 ， 如 “window” 表 示 
WindowManagerService*/。 





。flags 为 0 


函数 一 开始 会 对 data 进 行 检查 : 


status_t err = data.errorCheck(); // 检 查 data 是 否 有 效 
flags |= TF_ACCEPT_FDS; 


Transaction 共 有 4 种 flag， 如 下 所 示 。 


TF_ONE WAY: 这 个 名 字 取 得 有 点 怪 ， 它 表示 当前 业务 是 异步 的 ， 不 
He 4 
需要 等 待 。 


TF_ROOT OBJECT: 所 包含 的 内 容 是 根 对 象 。 
TF_STATUS CODE: 所 包含 的 内 容 是 32-bit 的 状态 值 。 
TF_ACCEPT_FDS = 0x10: 允许 回复 中 包含 文件 描述 符 。 


因为 开始 的 flags 为 0， 所 以 经 过 这 一 步 后 flags 的 值 是 
TF_ACCEPT_FDS。 


接 下 来 transact 就 要 整理 数据 ， 把 它 打包 成 Binder 驱动 协 议 规定 的 
格式 了 。 这 个 过 程 由 writeTransactionData 来 完成 GES: 这 个 国 数 只 
是 整理 数据 ， 并 把 结果 存 入 m0ut 中 。 而 在 talkWithDriver () 方法 中 才 会 
将 命令 真正 发 送 给 Binder 驱 动 ) : 


if (err == NO_ERROR) { 
LOG_ONEWAY(">>>> SEND from pid %d uid %d %s", getpid(), ge 
(flags & TF_ONE_WAY) == 0 ? "READ REPLY" : "ONE WAY"); 
err = writeTransactionData(BC_TRANSACTION, flags, handle,c 
} 


出 错 处 理 : 


if (err != NO_ERROR) { 
if (reply) reply->setError(err); 
return (mLastError = err); 


} 
到 目前 为 止 ， 命 令 还 在 m0ut 中 。 那 么 ， 什 么 时 候 才 会 发 出 去 呢 ? 
if ((flags & TF_ONE_WAY) == 0) { // 不 是 异步 ， 根 据 上 面 的 flags 可 知 赴 


if (reply) {//reply 对 象 不 为 空 
err = waitForResponse(reply); // 看 起 来 应 该 是 在 这 里 面 发 





} else { 
Parcel fakeReply;// 做 一 个 假 的 reply 对 象 
err = waitForResponse(&fakeReply) ; 


} 


} else { // 异 步 的 情况 
err = waitForResponse(NULL, NULL); 
} 


return err; 
}/*transact 结 束 */ 








到 目前 为 止 ，transact 只 是 把 transaction 数 据 按 照 Binder 协 议 的 
要 求 填写 好 了 。 它 至 少 还 有 几 件 事 要 做 : 


。BC_TRANSACTION 属 于 BINDER_WRITE_READ 的 子 命令 ， 因 而 
数据 外 面 还 要 再 包 一 层 描述 信息 。 

。 数据 还 没有 真正 发 送出 去 。 

。 之 前 我 们 已 经 说 过 基于 Bindet 的 IPC 多 半 都 是 阻塞 型 的 ， 但 是 还 没 
到 具体 是 如 何 实现 的 。 
我 们 先 来 看 看 waitForResponse 做 了 些 什么 工作 : 


status_t IPCThreadState: :waitForResponse(Parcel *reply, status_t 








mits 





int32_t cmd; 

int32_t err; 

while (1) { // 循 环 等 待 结 
if ((err=talkwithDriver()) < NO_ERROR) break; /* 处 理 与 Binde 
err = mIn.errorCheck(); 
if (err < NO_ERROR) break; // 出 错 退 出 
if (mIn.dataAvail() == ©) continue; //mIn 中 没有 数据 ， 继 续 循环 
cmd = mIn.readInt32(); // 读 取 回 复数 据 

// 接 下 来 是 对 回复 数据 的 处 理 ， 我 们 暂时 略 过 ， 后 面 再 回 过 头 来 分 析 



































}/*waitForResponse 结 束 */ 

上 面 代码 段 中 的 reply 不 为 空 ，acqui reResult 为 空 。 

实际 上 顶 数 waitForResponse 解 决 了 前 面 提 出 的 3 个 问题 。 其 中 
talkWithDriver 《这 个 函数 后 面 有 详细 分 析 ) 会 将 已 有 数据 进行 必要 的 


包装 ， 然 后 发 送 给 Binder 驱 动 。 接 下 来 根据 用 户 的 配置 会 决定 是 否 要 等 
待 结 果 : 当 程 序 走 到 mln. errorCheck () 时， 说 明 已 收 到 Binder 驱 动 的 回 


复 。 这 通常 意味 着 Binder Server 已 经 执行 了 相关 请 求 〈 比 如 
getService) ， 并 返回 了 结果 。 


为 了 让 大 家 能 将 整个 过 程 连贯 起 来 ， 我 们 先 不 看 waitForResponse 
对 回复 的 处 理 ， 而 是 接着 分 析 talkWithDriver 这 个 函数 。 
1PCThreadState 中 与 Binder 了 驱动 真正 进行 通信 的 地 方 就 在 
talkWithDriver 里 ， 如 下 所 示 “〈 分 段 阅读 ) 。 
status_t IPCThreadState::talkWithDriver(bool doReceive) 


if (mProcess->mDriverFD <= 0) {//Binder 了 驱动 设备 还 没 打 开 
return -EBADF; 





} 

binder_write_read bwr; /* 读 写 都 使 用 这 个 数据 结构 */ 

const bool needRead = mIn.dataPosition() >= mIn.dataSize(); 
const size_t outAvail = (!doReceive || needRead) ? mOut.dataS 


当 mln 需 要 去 读 取 (needRead) ， 同 时 调用 者 又 希望 读 取 时 〈 即 
doReceive 为 true) ， 我 们 就 不 能 写 m0ut 。 


Parcel (mIn) 的 数据 处 理 如 图 6-18 所 示 。 


mDataCapacity 


mDataSize 


mDataPos 
Parcel min): —— 





mData 


全 图 6-18 Parcel (mIm 的 数据 处 理 图 示 


在 前 面 小 节 中 ， 我 们 介绍 过 Parce1 中 有 几 个 重要 的 内 部 变 
mData，mDataSize，mDataCapacity，mDataPos 等 。 ee ete 
个 内 存 地 址 的 ， 表示 Parce1 所 包含 的 内 部 数据 在 内 存 中 的 起 始 地 址 。 而 
其 他 变量 则 是 相对 于 mData 来 计算 的 ， 如 mDataSize 是 指 当 前 Parcel 中 已 
经 有 的 数据 量 ; mDataPos 是 当前 已 经 处 理 过 的 数据 量 。 


顺便 分 析 下 m0ut， 大 家 可 以 进行 比较 ， 如 图 6-19 所 示 。 


mDataCapacity 


mDataSize 


mDataPos 





Parcel(mOut) 


mData 


全 图 6-19 Parcel tmOub 的 数据 处 理 图 示 


因为 mDataPos 表 示 “ 当 前 已 经 处 理 过 的 数据 量 ”， 对 于 mln 来 说 ， 
读 取 数 据 就 是 “处 理 ”; 而 对 于 m0ut 来 说 ， 写 入 才 是 “处 理 ”， 所 以 两 
者 会 有 一 定 的 差异 。 可 想 而 知 ， 当 m0ut 要 变 成 nln 时 〈A 给 B 传 parce1， 
对 于 A 来 说 是 写 入 ， 对 于 B 则 是 读 取 ) 这 些 内 部 变量 需要 进行 相应 的 调 
整 ， 后 面 将 看 到 : 


bwr.write_size = outAvail; 
bwr.write_buffer = (long unsigned int)mOut.data(); 


在 bwr 中 填写 需要 write 的 内 容 和 大 小 : 


if (doReceive && needRead) { 
bwr.read_size = mIn.dataCapacity(); 
bwr.read_buffer = (long unsigned int)mIn.data(); 
} else { 
bwr.read_size = 0; 
bwr.read_buffer = 0; 


然后 在 bwr 中 填写 需要 read 的 数据 请 求 : 


if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ 


如 果 请 求 中 既 没有 要 读 的 数据 ， 也 没有 要 写 的 数据 ， 那 么 就 直接 返 


bwr.write_consumed = 0; 
bwr.read_consumed = 0; 
status_t err; 
do { 
#if defined(HAVE_ANDROID_0S)// 如 果 是 Android 系 统 
if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) 
err = NO_ERROR; 


else 
err = -errno; 
#else 
err = INVALID_OPERATION; 
#endif 
} while (err == -EINTR); 


个 循环 的 条 件 是 err 为 -=EINTR， 因 而 一 般 情 况 下 不 会 发 生 。 真 正 
与 Binder 驱 动 进行 通 信 的 代码 只 有 一 句 ， 即 : 


i1octl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr); 


稍 后 我 们 进入 Binder 驱 动 进 行 详细 的 情景 分 析 : 


if (err >= NO_ERROR) { 
if (bwr.write consumed > 0) { 
if (bwr.write_consumed < (ssize_t)mOut.dataSize()) 
mOut.remove(0, bwr.write_consumed) ; 
else 


mOut.setDataSize(0); 


if (bwr.read_consumed > 0) { 
mIn.setDataSize(bwr.read_consumed) ; 
mIn.setDataPosition(0); 


Fax 
return NO_ERROR; 
} 


return err; 


执行 完 ioct1 后 ， 通 过 bwr. write_consumed 和 bwr. read_consumed Al 
以 知道 Binder 驱动 对 我 们 请 求 的 BINDER_WRITE_READ 命 令 的 处 理 情况 ， 
然后 对 mln 和 m0ut 做 善后 清理 。 


e wtrite consumed>0 


说 明 Binder 驱 动 消耗 了 m0ut 中 的 数据 ， 因 而 就 要 把 这 部 分 已 经 处 理 
过 的 数据 移 除 掉 。 这 分 为 两 种 情况 : 如 果 消 耗 的 数据 量 小 于 m0ut 中 的 总 
数据 量 ， 就 单独 去 掉 这 部 分 数据 ; 否则 ， 就 直接 设置 当前 总 数据 量 为 
0。 


e read consumed>0 


和 上 面 的 判断 类 似 ， 此 时 说 明 Binder 驱 动 已 经 成 功 帮 有 我 们 读 取 到 了 
数据 ， 并 写 入 了 mln. data () 所 指向 的 内 存 地 址 〈 即 前 面 图 6-19 中 所 示 的 
mData 指 针 ) 中 。 所 以 ， 设 置 mDataSize 和 mDataPos 为 合适 的 值 。 


前 面 Binder 驱 动 小 节 中 曾经 讨论 过 binder_ioct1 这 个 函数 的 实现 ， 
但 因为 当时 还 缺乏 具体 的 应 用 场景 而 没有 做 细致 分 析 。 现 在 我 们 就 可 以 
带 着 getService() 这 个 请 求 再 次 进入 函数 的 源码 中 。 


接 下 来 重点 看 看 BINDER_WRITE_READ 命 令 的 执行 过 程 〈 分 段 阅 
读 ) ， 


/* (ALF) drivers/staging/android/Binder .c*/ 
static long binder_ioctl(struct file *filp, unsigned int cmd, uns 
{ 
int ret; 
struct binder_proc *proc = filp->private_data; /* 从 filp 中 取出 | 
binder_open 中 动态 创建 的 实例 */ 





struct binder_thread *thread; 


unsigned int size 
void __user *ubuf 


_IOC_SIZE(cmd); // 命 令 的 大 小 
(void __user *)arg; 


我 们 知道 ，Binder 的 执行 过 程 多 数 是 阻塞 型 的 (或 者 说 是 同步 操 
作 ) 。 换 名 话说， 通过 Binder 去 调用 服务 进程 提供 的 接口 函数 ， 那 么 此 
本 数 执行 结束 时 结果 就 已 经 产生 ， Bh 比如 用 户 使 用 
查 浮 数 的 返回 值 就 是 查询 
的 结果 ， ts te IER. 


Binder 是 如 何 做 到 这 一 a eee 
的 一 种 就 是 让 调用 者 进程 暂时 挂 起 ， 直 到 目标 进程 返回 结果 后 ，Binder 
再 唤醒 等 待 的 进程 。 如 下 所 示 : 


ret = wait_event_interruptible(binder_user_error_wait, binder_sto 
if (ret) 
goto err_unlocked; 








这 个 wait_event_interruptible 定 义 如 下 : 


#define wait_event_interruptible(wq, condition) \ 
({ \ 
int _ ret = 0; x 
if (! (condition) ) \ 
__wait_event_interruptible(wq, condition, _ ret); \ 
_ ret; \ 
}) 


也 就 是 说 ， 如 果 condition 满 足 的 话 就 直接 返回 0; A, # 
wait event_interruptible 进 入 可 中 断 的 挂 起 状态 : 


#define wait_event_interruptible(wq, condition, ret) 
do { 





DEFINE_WAIT(__wait); \ 
\ 
for (;;) { \ 
prepare_to_wait(&wq, & wait, TASK_INTERRUPTIBLE); 
if (condition) \ 
break; \ 
if (!signal_pending(current)) { \ 
schedule(); 
continue; \ 
} \ 
ret = -ERESTARTSYS; \ 


break; \ 


finish_wait(&wq, & wait); \ 
} while (0) 


宏 定 义 _wait event_interruptible 里 有 个 for 死 循环 ， 跳 出 循环 
的 条 件 是 condition 已 经 满足 要 求 。 首 先 它 将 自己 置 为 
TASK_1INTERRUPTIBLE， 也 就 是 可 中 断 挂 起 状态 ， 然 后 进行 schedule 调 
度 。 可 想 而 知 ， 因 为 已 经 不 是 处 于 可 运行 状态 ， 所 以 将 不 再 分 配 到 CPU 
时 间 ， 直 到 有 人 把 它 唤醒 。 本 来 后 还 是 得 先 检 查 condition 是 否 已 经 满 
足 ， 否 则 将 再 次 处 于 可 中 断 挂 起 状态 。 


这 里 因为 bjnder_stop_on_user_error 是 小 于 2 的 ， 所 以 不 会 被 挂 
起 : 


binder_lock(__func__); 


此 时 ioct1 已 经 取出 之 前 为 用 户 创建 的 proc 结 构 体 ， 并 计算 出 命令 
的 大 小 。 接 下 来 的 操作 将 在 保护 区 中 进行 : 


thread = binder_get_thread(proc); 
if (thread == NULL) { 

ret = -ENOMEM; 

goto err; 


上 面 的 代码 中 ，binder_get_thread 将 首先 向 proc 中 的 threads 链 表 
查询 是 否 已 经 添加 了 当前 线程 的 节点 ， 如 果 没 有 则 插入 一 个 表示 当前 线 
程 的 新 节点 。 需 特别 注意 的 是 ，threads 链 表 是 按 pid 大 小 排序 的 ， 这 样 
可 以 加 快 查询 速度 。 


到 目前 为 止 准备 工作 结束 ， 可 以 处 理 具体 的 命令 了 : 


switch (cmd) { 
case BINDER_WRITE_READ: { 
struct binder_write_read bwr; 


if (size != sizeof(struct binder_write_read)) { 
ret = -EINVAL; 
goto err, 


首先 判断 buffer 大 小 是 否 符合 要 求 ， 然 后 开始 从 用 户 空 间 复 制 数 
据 : 


if (copy_from_user(&bwr, ubuf, sizeof(bwr))) {// 从 用 户 空 
ret = -EFAULT; 
goto err; 


还 记得 我 们 在 ioct1_mmap 中 的 讲解 吗 ? 如 果 还 不 太 清 楚 上 面 代 码 是 
做 什么 的 ， 请 返回 Binder 驱 动 小 节 进 行 复 习 。 


成 功 从 用 户 空 间 取 得 数据 后 ， 接 下 来 就 开始 执行 wr ite/read 操 作 。 


在 talkWithDriver 中 ， 我 们 根据 实际 情况 分 别 填写 了 write 和 read 
请 求 ， 因 而 这 里 也 会 区 分 对 待 : 


if (bwr.write_size > 0) { // 有 数据 需要 写 

ret = binder_thread_write(proc, thread, (void __user 
bwr.write_size, &bwr.write_consumed); /* 这 个 函数 我 

if (ret < 0) { // 成 功 执行 返回 9， 负 数 表 示 有 错误 发 生 
bwr.read_consumed = 0; // 告 诉 调用 者 已 读 取 的 数据 大 小 大 
if (copy_to_user(ubuf, &bwr, sizeof(bwr)))/* 复 制 关 

ret = -EFAULT; 

goto err; 











} 
} 


上 面 这 段 代码 首先 判断 用 户 是 否 请 求 写 入 数据 ， 然 后 调用 


binder_thread_ write: 





if (bwr.read_size > 0) { // 需 要 读数 据 
ret = binder_thread_read(proc, thread, (void __user 
bwr.read_size, &bwr.read_consumed, filp->f_flags . 
这 个 函数 来 读 
if (!list_empty(&proc->todo) ) 
wake_up_interruptible(&proc->wait); 
if (ret < 0) { 
if (copy_to_user(ubuf, &bwr, sizeof(bwr) )) 
ret = -EFAULT; 
goto err; 


j 


if (copy_to_user(ubuf, &bwr, sizeof(bwr))) { 
goto err; 


break; 
} //case 人 
.…// 其 他 命令 处 理 过 程 省 略 
}//binder_ ioctlaiK 





然后 通过 read_size 判 断 用 户 是 否 请 求 读 取 数 据 。 不 管 是 读 取 还 是 
写 入 ，Binder 驱 动 只 是 发 挥 中 间 人 的 作用 ， 真 正 处 理 请 求 的 还 是 Binder 
Client 和 Binder Server 通 信 双 方 。 


过 上 面 的 代码 我 们 只 能 大 概 了 解 到 读 写 操作 的 流程 ， 接 下 来 将 以 
bi Saree ite) 为 例 来 具体 分 析 内 部 的 实现 细节 。 这 个 函数 很 
长 ， 我 们 仍然 截取 关键 部 分 逐步 讲解 : 


int binder_thread_write(struct binder_proc *proc, struct binder_t 
void __user *buffer, int size, signed long *consum 
{ 


在 getService () 这 一 场景 下 ， 各 主要 参数 的 值 如 下 。 
e proc 
调用 者 进程 。 
e thread 
调用 者 线程 。 
e buffer: 
即 bwr.， write_buffer 。 在 talkWithDriver 中 ， 它 被 设置 为 : 
bwr.write_buffer = (long unsigned int)mOut.data(); 


因而 就 是 writeTransactionData 中 对 m0ut 写 入 的 数据 ， 主 要 有 两 部 
分 : 


mOut ,writeInt32(cmd ) ; 
mOut.write(&tr, sizeof(tr)); 


其 中 cmd 是 BC_TRANSACT1I0N，tr 是 一 个 binder_transaction_data 数 
据 结 构 的 变量 。 


e size 
即 bwr. write size. 
e consumed 


即 bwr. write consumed: 


uint32_t cmd; 
void __user *ptr 
void __user *end 





buffer + *consumed; // 忽 略 已 经 处 理 过 的 部 分 
buffer + size; //buffer 尾 部 


这 里 的 ptr 和 end 分 别 指向 buffer 需 要 处 理 的 数据 起 点 和 终点 。 


应 该 知道 的 是 ，buffer 中 可 以 包含 不 止 一 个 命令 和 其 对 应 的 数据 ， 
因而 接 下 来 的 代码 将 采用 循环 的 形式 来 处 理 所 有 命令 : 


while (ptr < end && thread->return_error == BR_OK) { 

if (get_user(cmd, (uint32_t __user *)ptr)) // 获 取 一 个 cmd 
return -EFAULT; 

ptr += sizeof(uint32_t); /* 跳 过 cmd 所 占 的 空间 大 小 ， 

这 样子 指针 就 指向 下 面 需要 处 理 的 妆 

if (_IOC_NR(cmd) < ARRAY_SIZE(binder_stats.bc)) {/* 统 计 关 
binder_stats.bc[_IOC_NR(cmd) ]++; 
proc->stats.bc[_IOC_NR(cmd) ]++; 
thread->stats.bc[_IOC_NR(cmd) ]++; 

















} 
这 里 取出 的 cmd 为 BC_TRANSACTION， 我 们 略 过 其 他 无 关 代码 : 
Switch (cmd) { 


case BC_TRANSACTION: 

case BC_REPLY: { 
struct binder_transaction_data tr;/* 这 组 命令 的 格式 为 

cmd| binder_tra 
if (copy_from_user(&tr, ptr, sizeof(tr))) //MHF4 
return -EFAULT; 

ptr += sizeof(tr); // 跳 过 tr 所 占 空间 
binder_transaction(proc, thread, &tr, cmd == BC_RE 
break; 


} 
.…// 其 他 命令 的 处 理 省 略 
}// binder_thread_write 结 束 

















获取 了 用 户 空间 的 binder_transaction data 结构 体 变 量 后 ， 紧 接 
着 程序 进入 binder_ transaction 进 行 处 理 〈 这 个 国 数 可 以 说 是 Binder 中 
最 长 的 ， 不 过 也 是 最 关键 的 ) 。 值 得 一 提 的 是 ， 此 项 数 被 同时 用 于 处 理 
BC_TRANSACTI0N 和 BC_REPLY 两 种 命令 一 一 理论 上 来 讲 这 种 杂 烁 的 方式 并 
不 是 太 好 ， 这 么 做 可 能 是 两 者 间 确 实 有 关联 ， 部 分 代码 也 是 共用 的 ， 不 
过 易 读 性 就 比较 差 了 : 
static void binder_transaction(struct binder_proc *proc, 


struct binder_thread *thread, 
struct binder_transaction_data *tr, int repl 





这 个 函数 的 入 参 和 上 面 binder_thread_wr ite 基 本 类 似 ， 此 处 不 再 


ie 


struct binder_transaction *t; 

struct binder_work *tcomplete; 

size_t *offp, *off_end; 

struct binder_proc *target_proc; 

struct binder_thread *target_thread = NULL; 
struct binder_node *target_node = NULL; 
struct list_head *target_list; 
wait_queue_head_t *target_wait; 

struct binder_transaction *in_reply_to = NULL; 
struct binder_transaction_log_entry *e; 
uint32_t return_error; 


先 讲解 一 下 函数 中 涉及 的 几 个 重要 变量 。 
e target_proc 


从 名 称 可 以 看 出 ， 是 目标 对 象 所 在 的 进程 。 在 我 们 这 个 场景 
就 是 ServiceManager。 oe Fibinder. transaction] & 
POS 


e target_thread 
同上 。 
et 


表示 一 个 transaction 探 作 。 


e tcomplete 


表示 一 个 未 完成 的 操作 。 因 为 一 个 transcation 通 常 涉及 两 个 进程 A 
和 B， 当 A 向 B 发 送 了 请 求 后 ，B 需 要 一 段 时 间 来 执行 ; 此 时 对 于 A 来 说 就 
一 个 “未 完成 的 操作 ”一 一 直到 B 返 回 结 果 后 ， Binder 驱 动 才 会 再 次 

启动 A 来 继续 执行 


e = binder_transaction_log_add(&binder_transaction_log); 
e->call_type = reply ? 2 : !!(tr->flags & TF_ONE_WAY); 
e->from_proc = proc->pid; 

e->from_thread = thread->pid; 


e->target_handle = tr->target.handle; 
e->data_size = tr->data_size; 
e->offsets_size = tr->offsets_size; 


上 面 这 段 代 码 用 于 添加 log 信 息 ， 我 们 可 以 跳 过 。 


因为 这 个 函数 要 处 理 BC_TRANSACTION 和 BC_REPLY 两 种 情况 ， 所 以 必 
须 将 它们 先 区 分 开 来 。 显 然 这 里 是 BC_TRANSACTION， 即 reply 为 false: 


if (reply) { 
.…//BC_REPLY 的 情况 ， 省 略 代码 
} else {// 这 个 分 支 就 是 BC_TRANSACTION 的 情况 
if (tr->target.handle) {/*handle 不 为 0 的 情况 */ 
struct binder_ref *ref; 
ref = binder_get_ref(proc, tr->target.handle); 














target_node = ref->node; 
} else {/*handle 为 0， 即 目标 为 Service Manager*/ 
target_node = binder_context_mgr_node; 
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对 BC_TRANSACTION 的 处 理 分 为 几 个 步骤 。 上 面 这 段 代码 就 是 第 一 
步 ， 即 取得 目标 对 象 所 对 应 的 target_node。 如 果 target. handle 为 0， 
代表 target 是 Service Manager， 因 而 可 以 直接 使 用 
binder_context _mgr_node 这 个 全 局 变量 ， 否则 ， 就 调用 
binder get ref 来 查找 是 否 存在 一 个 符合 hand1le 要 求 的 node: 


e->to_node = target_node->debug_id; 
target_proc = target_node->proc;// 目 标 进程 


if (!(tr->flags & TF_ONE_WAY) && thread->transaction_st 
struct binder_transaction *tmp; 
tmp = thread->transaction_stack; 


while (tmp) { 
if (tmp->from && tmp->from->proc == target_pr 
target_thread = tmp->from; 
tmp = tmp->from_parent; 


} 


第 二 步 ， 找 出 目标 对 象 的 target_proc 和 和 target thread: 


if (target_thread) { 
e->to_thread = target_thread->pid; 
target_list &target_thread->todo; 
target_wait &target_thread->wait; 
} else { 
target_list 
target_wait 


&target_proc->todo; 
&target_proc->wait; 


} 


e->to_proc = target_proc->pid; 


第 三 步 ， 根 据 第 二 步 的 结果 得 到 target_1ist 和 target_wait， 分 别 
用 于 表示 “todo” 和 “wait” 列 表 : 


t = kzalloc(sizeof(*t), GFP_KERNEL); 


第 四 步 ， 生 成 一 个 binder_transaction 变 量 ( 即 上 面 代码 中 的 +t ) 
用 于 描述 本 次 要 进行 的 transaction 一 一 最 后 将 其 加 入 target_thread- 
Ae 这 样 当 目标 对 象 被 唤醒 时 ， 它 就 可 以 从 这 个 队列 中 取出 需要 
故 的 工作 : 


tcomplete = kzalloc(sizeof(*tcomplete), GFP_KERNEL); 


第 五 步 ， 生 成 一 个 binder_work 变 量 〈 即 上 面 代码 中 的 tcomplete) 
用 于 说 明 当 前 调用 者 线程 有 一 宗 未 完成 的 transaction 一 一 它 最 后 会 被 
添加 到 本 线程 的 todo 队 列 中 : 


if (!reply && !(tr->flags & TF_ONE_WAY) ) 
t->from = thread; 
else 
t->from = NULL; 
t->sender_euid = proc->tsk->cred->euid; 
t->to_proc = target_proc; 
t->to_thread = target_thread; 
t->code = tr->code; 
t->flags = tr->flags; 
t->priority = task_nice(current); 
t->buffer = binder_alloc_buf(target_proc, tr->data_size, 
tr->offsets_size, !reply && (t->flags & TF_ONE_WAY)); 
if (t->buffer == NULL) { 
return_error = BR_FAILED_REPLY; 
goto err_binder_alloc_buf_failed; 


t->buffer->allow_user_free = 0; 
t->buffer->debug_id = t->debug_id; 
t->buffer->transaction = t; 
t->buffer->target_node = target_node; 
if (target_node) 

binder_inc_node(target_node, 1, ©, NULL); 


第 六 步 ， 填 写 binder_transaction 数 据 。 一 个 binder_transaction 


包含 的 信息 比较 多 ， 我 们 结合 当前 场景 描述 其 中 的 重点 部 分 。 
。 调用 者 信息 
如 t 一 from， 表 示 这 个 transaction 是 由 谁 发 起 的 。 


。 目标 对 象 信息 


bnt 一 to_proc 和 t 一 to_thread， 分 别 表示 目标 所 在 的 进程 和 线程 。 


这 里 对 应 的 是 Service Manager。 


e ttansaction 相 关 信 息 


bnt 一 code 是 面向 Binder Server 的 请 求 码 ，getService (服务 对 应 


的 是 GET_ SERVICE TRANS ACTION. 


t 一 buffer 是 为 了 完成 本 条 transaction 所 申请 的 内 存 ， 也 就 是 
Binder 驱 动 小 节 中 mmap 所 管理 的 内 存 区 域 : 


offp = (size_t *)(t ,buffer ,data + ALIGN(tr—data_size, sizeof 


if (copy_from_user(t—buffersdata, trsdata.ptr.buffer, tr->da 
binder_user_error("binder: %d:%d got transaction with 1 


"data ptr\n", procspid, thread—pid); 
return_error = BR_FAILED_REPLY; 
goto err_copy_data_failed; 





if (copy_from_user(offp, tr->data.ptr.offsets, tr->offsets_s 
binder_user_error("binder: %d:%d got transaction with i 


"offsets ptr\n", proc->pid, thread->pid); 
return_error = BR_FAILED_REPLY; 
goto err_copy_data_failed; 





if (!IS_ALIGNED(tr->offsets_size, sizeof(size_t))) { 


binder_user_error("binder: %d:%d got transaction with " 
"invalid offsets size, %zd\n", 
proc->pid, thread->pid, tr->offsets_size); 
return_error = BR_FAILED_REPLY; 
goto err_bad_offset; 


第 七 步 ， 申 请 到 t 一 buffer 内 存 后 ， 我 们 可 以 从 用 户 空 间 把 数据 复 
制 过 来 。 因 为 t 一 buffer 所 指向 的 内 存 空 间 和 目标 对 象 是 共享 的 ， 所 以 
只 需要 一 》 ld ARAG Client 复 制 到 Binder Server 中 了 。 

具体 过 程 在 前 面 小 节 中 已 经 前 述 过 ， 读 者 如 果 不 清楚 可 以 回头 看 看 。 


接 下 来 是 一 个 很 长 的 for 循 环 ， 它 用 来 处 理 数据 中 的 binder_ob ject 
对 象 。 因 为 getService () 是 向 Service Manager 查 询 一 个 对 象 ， 因 而 这 
一 部 分 代码 暂时 可 以 略 过 ， 等 到 Service Manager 根 据 用 户 请 求 写 入 一 
个 ob ject 时 ， 我 们 再 来 分 析 : 

off_end = (void *)offp + tr->offsets_size; 


for (; offp < off_end; offp++) { 
.// 对 binder_object 对 象 的 处 理 ， 和 暂时 略 过 














} 
if (reply) { 
BUG_ON(t->buffer->async_transaction != 0); 
binder_pop_transaction(target_thread, in_reply_to); 
} else if (!(t->flags & TF_ONE_WAY)) { // 在 这 个 场景 下 执行 此 分 支 
BUG_ON(t->buffer->async_transaction != 0); 
t->need_reply = 
t->from_parent = thread->transaction_stack; 
thread->transaction_stack = t; 
} else { 
BUG_ON(target_node == NULL); 
BUG_ON(t->buffer->async_transaction != 1); 
if (target_node->has_async_transaction) { 
target_list = &target_node->async_todo; 
target_wait = NULL; 
} else 
target_node->has_async_transaction = 1; 
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如 果 用 户 没有 指定 TF_ONE_WAY 标 志 ， 则 将 这 个 transact ion 的 
need_reply 置 为 1， 并 记录 本 次 transaction 以 备 后 期 查询 : 


t->work.type = BINDER_WORK_TRANSACTION; 
1ist_ add_tail(&t->work.entry，target_1ist);// 加 入 目标 的 处 理 队 列 





tcomplete->type = BINDER_WORK_TRANSACTION_COMPLETE; 

list_add_tail(&tcomplete->entry, &thread->todo) ;// 当 前 线程 有 一 

if (target_wait) 
wake_up_interruptible(target_wait ) ;// 唤 醒目 标 

return; 


关键 的 一 步 来 了 ， 如 我 们 之 前 所 述 一 一 t 最 终 会 被 加 入 对 方 的 todo 
队列 中 ，tcomplete 被 加 入 调用 者 自己 的 todo 队 列 中 ， 然 后 开始 唤醒 目 
标 对 象 《如果 需要 的 话 ) ， 即 Service Manager: 


err_get_unused_fd_failed: 
err_fget_failed: 
err_fd_not_allowed: 
err_binder_get_ref_for_node_failed: 
err_binder_get_ref_failed: 
err_binder_new_node_failed: 
err_bad_object_type: 
err_bad_offset: 
err_copy_data_failed: 
.…// 错 误 处 理 ， 代 码 省 略 
}//binder_transaction 结 束 


Service Manager 被 唤醒 后 ， 系 统 就 要 分 两 条 路 进行 。 


1. Service Managet 被 唤醒 后 ，Bindet Client 端 的 处 理 
































一 方面 ， 调 用 者 Binder Client 在 执行 完 binder_ transaction 后 ， 
首先 返回 binder_thread_write， 因 为 这 个 函数 已 经 没有 什么 可 以 做 的 
了 ， 就 直接 返回 到 binder_ioct1。 此 时 binder_ ioctl 已 经 执行 完 用 户 的 
write 请 求 ， 紧 接着 就 要 判断 用 户 是 否 还 有 read 请 求 。 为 了 方便 阅读 ， 
我 们 把 这 段 代 码 单独 列 出 。 如 下 所 示 : 


if (bwr.read_size > 0) { 
ret = binder_thread_read(proc, thread, (void __user 
bwr.read_size, &bwr.read_consumed, filp->f_flags & 
if (!list_empty(&proc->todo) ) 
wake_up_interruptible(&proc->wait); 
if (ret < 0) { 
if (copy_to_user(ubuf, &bwr, sizeof(bwr) ) ) 
ret = -EFAULT; 
goto err; 


} 


} 
if (copy_to_user(ubuf, &bwr, sizeof(bwr))) { 


ret = -EFAULT; 
goto err; 
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和 wr ite 请 求 类 似 ， 用 户 通过 设置 read_si ze 来 表示 他 希望 读 取 的 数 
据 以 及 数据 量 大 小 。 接 着 程序 调用 bi nder_thread_read 来 执行 具体 的 读 
取 过 程 。 对 于 这 个 函数 的 分 析 和 binder_thread_wr ite 大 致 相 同 ， 因 而 
我 们 只 挑选 部 分 重点 来 讲解 。 如 下 所 示 : 


static int binder_thread_read(struct binder_proc *proc, 
struct binder_thread *thread, 
void __user *buffer, int size, 
signed long *consumed, int non_block) 


首先 来 看 看 函数 的 几 个 入 参 。 其 中 proc 和 thread 分 别 是 调用 者 的 进 
程 和 线程 。 人 参数 buffer 很 明显 是 调用 者 提供 的 写 入 空间 ， 也 就 是 
IPCThreadState 中 的 mln 数 据 存储 空 间 。 其 后 的 size 是 要 读 取 的 最 大 数 
据 量 ， 也 就 是 mln 的 容量 。 而 consumed 对 应 mln. read_consumed=0: 


void __user *ptr 
void _ user *end 


= buffer + *consumed; 
= buffer + size; 
int ret = 0; 
int wait_for_proc_work; 
if (*consumed == 0) { 
if (put_user(BR_NOOP, (uint32_t __user *)ptr)) 
return -EFAULT; 
ptr += sizeof(uint32_t); 





} 


和 binder_thread_write 类 似 ，ptr 和 end 分 别 指向 数据 的 起 始 和 终 
点 。 如 果 read _consumed=0， 则 写 入 一 个 BR_NOOP: 


while (1) { 
uint32_t cmd; 
struct binder_transaction_data tr; 
struct binder_work *w; 
struct binder_transaction *t = NULL; 


if (!list_empty(&thread->todo) )//todo 列 表 是 否 为 空 
w = list_first_entry(&thread->todo, struct binder 
else if (!list_empty(&proc->todo) && wait_for_proc_work 


w = list_first_entry(&proc->todo, struct binder_wo 


else { 
if (ptr - buffer == 4 && !(thread->looper &BINDER_ 
goto retry; 
break; 
} 


在 前 面 的 bjnder_thread_ write 中， 我 们 把 一 个 binder_work 添 加 到 
thread 一 todo 队 列 中 ， 因 而 这 里 的 w 不 会 为 空 ， 类 型 为 
BINDER WORK TRANSACTION COMPLETE: 


if (end - ptr < sizeof(tr) + 4) 
break; 


switch (w->type) {... 
case BINDER_WORK_TRANSACTION_COMPLETE: { 
cmd = BR_TRANSACTION_COMPLETE; 
if (put_user(cmd, (uint32_t __user *)ptr))//5A Ex 
return -EFAULT; 
ptr += sizeof(uint32_t); 


binder_stat_br(proc, thread, cmd) ;// 统 计 信 息 
list_del(&w->entry); 
kfree(w); 
binder_stats_deleted(BINDER_STAT_TRANSACTION_COMPL 
} break; 
..// 省 略 其 他 无 关 case 
}//while 循 环 结束 





return 0; 
}//binder_thread_readZi R 





可 见 在 对 BINDER_WORK_TRANSACTION_COMPLETE 的 处 理 中 ， 程 序 又 写 
入 了 一 个 BR_TRANSACTION_COMPLETE， 后 面 可 以 重点 看 看 
IPCThreadState 是 如 何 处 理 的 。 


总 的 来 说 ，binder_thread_read 读 取 了 两 个 命令 ， 即 BR_NOOP 和 
BR_TRANSACTION_COMPLETE。 完 成 以 后 仍旧 回 到 binder_ioct1， 继 而 返 
回 IPCThreadState 中 的 talkWithDriver。 前 面 已 经 分 析 过 ， 如 果 
wr ite_consumed 和 read_consumed 都 大 于 0， 那 么 mo0ut 和 mln 会 做 出 相应 
的 调整 ， 最 后 回 到 waitForResponse 的 主 循环 中 : 


while (1) { 
if ((err=talkwithDriver()) < NO_ERROR) break;// 前 面 做 了 那么 条 


err = mIn.errorCheck();/* 错 误 检查 */ 
if (err < NO_ERROR) break;/* 数 据 有 错误 */ 
if (mIn.dataAvail() == 0) continue;/* 如 果 没有 可 用 数据 ， 进 入 下 一 


我 们 在 源码 中 已 经 绕 了 一 个 大 圈 ， 但 实际 上 都 只 是 围绕 
talkWithDriver 展 开 的 。 当 函数 返回 时 ， 说 明 mln 已 有 数据 ， 我 们 就 接 
着 之 前 的 代码 看 下 具体 是 如 何 处 理 的 : 


cmd = mIn.readInt32();// 读 取 cmd 

switch (cmd) { 

case BR_TRANSACTION_ COMPLETE: 
if (!reply && !acquireResult) goto finish; 
break; 


default: 
err = executeCommand(cmd); 
if (err != NO_ERROR) goto finish; 
break; 


} 


这 个 switch 分 支 并 没有 专门 针对 BR_N00P 的 case， 因 而 它 会 进入 
default 中 ， 继 而 执行 executeCommand。 不 过 实际 上 什么 也 不 做 : 


status_t IPCThreadState: :executeCommand(int32_t cmd) 


{ 了 

switch (cmd) { 

case BR_NOOP: 
break; 

} 


执行 完 BR_N00P 后 ， 因 为 没有 跳出 whi le 主 循环 ， 还 会 再 进入 一 次 
talkWithDriver。 不 过 因为 此 时 mln 中 还 有 其 他 数据 没 读 完 ， 
mln. dataPosition( < min. dataSize() ， 所 以 read_ size 和 write size 
都 为 0， 也 就 不 会 调用 ioct1 了 。 


接着 程序 处 理 BR_TRANSACT1ION_COMPLETE， 分 为 两 种 情况 。 假 如 是 
同步 就 需要 继续 执行 主 循环 ， 即 前 面 whi le (1) 中 的 内 容 ; 否则 ， 就 直接 
跳 转 到 fi ni sh 结束 整个 操作 。 这 里 是 第 一 种 情况 ， 即 程序 还 会 再 次 调用 
talkWithDriver 与 Binder 驱 动 进行 交互 。 


第 二 次 进入 talkWithDr iver ， 稍 微 有 点 变化 的 是 
bwr. write_size=0， 而 bwr. read_size 还 是 大 于 0。 所 以 在 binder_ioctl 


中 ， 就 不 需要 执行 binder_thread_ write 了 ， 可 直接 进入 
binder_thread_read 中 。 因 为 这 个 函数 之 前 已 经 分 析 过 ， 下 面 只 重点 列 
出 有 区 别 的 地 方 : 


static int binder_thread_read(struct binder_proc *proc, struct bi 
void __user *buffer, int size, signed long *c 
{ 


void __user *ptr 
void _ user *end 


= buffer + *consumed; 
= buffer + size; 

int ret = 0; 

int wait_for_proc_work; 





if (*consumed == 0) { 
if (put_user(BR_NOOP, (uint32_t __user *)ptr)) 
return -EFAULT; 
ptr += sizeof(uint32_t); 


t 


retry: 
wait_for_proc_work = thread->transaction_stack == NULL &&lis 





首先 还 是 放 入 一 个 BR_N00P， 然 后 判断 是 否 要 
wait for_proc work。 由 于 thread->transaction_stack 到 目前 为 止 还 
不 为 空 ， 而 且 前 一 次 操作 已 经 处 理 了 todo 队 列 ， 所 以 调用 者 唯一 能 做 的 
eee Manager 的 结果 。 因 而 ， 它 最 终 将 通过 如 下 语句 进入 
睡眠 等 待 : 


if (wait_for_proc_work) {//wait_for_proc_workAfalse 








} else { 
if (non_block) { //non_blockAfalse 
if (!binder_has_thread_work(thread) ) 
ret = -EAGAIN; 
} else 
ret = wait_event_freezable(thread->wait, binder_ha 
/* 进 入 等 待 ， 直 到 Service Manager 来 唤醒 *V 
} 


这 样 我 们 融 分 析 完 调用 者 这 边 在 唤醒 Service Manager 后 的 工作 了 
一 一 它 将 最 终 进 入 等 待 。 


2. Service Manager 被 唤醒 后 的 操作 





要 回答 这 个 问题 ， 首 先 得 知道 SM 在 睡眠 前 执行 到 了 哪里 。 根 据 前 几 
个 小 节 对 SM 的 讲解 ， 它 在 启动 后 首先 进行 了 一 系列 的 初始 化 操作 ， 然 后 
通知 Binder 驱 动 它 即 将 进入 循环 状态 ， 最 后 通过 一 个 for 语 句 不 断 解 析 
客户 端的 请 求 。 如 下 所 示 : 

for (;;) { 

bwr.read_size = sizeof(readbuf ); 


bwr.read_consumed = 0; 
bwr.read_buffer = (unsigned) readbuf; 


res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);//[JBinder3kz 
res = binder_parse(bs, 0, readbuf, bwr.read_consumed, fun 


} 


由 以 上 代码 段 可 知 ， 除 非 发 生意 外 错误 ， 否 则 SM 将 一 直 在 这 个 for 
循环 中 响应 Binder Client 的 请 求 。 这 个 主 循环 一 开始 设置 了 
bwr. read size = sizeof (readbuf), 即 read size>0, 而 
write _ size=0。 因 而 进入 binder_ioct1 后 ， 只 会 执行 
binder_ thread _read， 此 时 又 会 发 生 什 么 情况 呢 ? 


static int binder_thread_read(struct binder_proc *proc, struct bi 








void __user *buffer, int size, signed long * 
../V 无 关 部 分 一 律 省 略 
retry: 
wait_for_proc_work = thread->transaction_stack == NULL &&lis 


和 前 面 调 用 者 进程 遇 到 的 情况 一 样 ， 后 面 这 两 个 条 件 都 成 立 ， 
wait for_proc work 就 为 true。 所 以 : 


if (wait_for_proc_work) { 





if (non_block) { 
if (!binder_has_proc_work(proc, thread) ) 
ret = -EAGAIN; 





} else 
ret = wait_event_freezable_exclusive (proc->wait, 
binder_has_proc_work 
} else { 


J 


也 就 是 说 ，SM 将 通过 wait_event_freezable_exclusive 进 入 睡眠 等 
待 ， 直 到 有 人 唤醒 它 。 


这 样 我 们 就 知道 SM 需 要 从 哪 一 步 开 始 执行 了 。 它 醒 来 后 首先 会 检查 
自己 的 todo 队 列 是 否 有 需要 处 理 的 事项 一 一 根据 前 面 的 分 析 ， 此 时 这 个 
队列 放 的 是 Binder Client 提 交 的 getService( 的 请 求 。 如 下 所 示 : 





while (1) { 
struct binder_work *w; 


switch (w->type) { 
case BINDER_WORK_TRANSACTION: {// 需 要 处 理 这 个 业务 

t = container_of(w, struct binder_transaction, wor 
} break; 








业务 的 类 型 为 BINDER_WORK_TRANSACT10N。 处 理 过 程 并 不 复杂 ， 主 
要 是 把 用 户 的 请 求 复 制 到 Service Manager 中 并 对 各 种 队列 进行 调整 。 
有 兴趣 的 读者 可 以 自己 分 析 。 


通过 binder_ioct1 读 取 到 getService () 请求 后 ，SM 将 调用 
binder_parse 进 行 解 析 ， 最 后 再 次 调用 ioct 1 与 驱动 交互 ， 如 下 所 示 : 


/*frameworks/native/cmds/servicemanager/Binder .c*/ 
res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);/*SMMEK ia occ h 
然后 返回 到 这 里 */ 
res = binder_parse(bs, 0, readbuf, bwr.read consumed, func); 
getSe 


ServiceManager HAYbinder_parseXMAIMUaTAwW, REPAS 
getService () 这 个 场景 再 分 析 一 次 : 


/*frameworks/native/cmds/servicemanager/Binder .c*/ 
int binder_parse(struct binder_state *bs, struct binder_io *bio, 
{ . 

int r = 1; 

uint32_t *end = ptr + (size / 4);/* 数 据 终点 */ 


while (ptr < end) { 
uint32_t cmd = *ptr++;// 取 出 cmd 
switch(cmd) { 


.V// 忽 略 其 他 无 关 case 
case BR_TRANSACTION: { 

struct binder_txn *txn = (void *) ptr; 

binder_dump_txn(txn) ;//dumpidix 

if (func) { 
unsigned rdata[256/4]; 
struct binder_io msg; 
struct binder_io reply; // 注 意 reply 变 量 的 数据 类 型 
int res; 





bio_init(&reply, rdata, sizeof(rdata), 4); // 为 rel 
bio_init_from_txn(&msg, txn); 

res = func(bs, txn, &msg, &reply); //Hsvcmgr_hanc 
binder_send_reply(bs, &reply, txn->data, res); // 








} 
ptr += sizeof(*txn) / sizeof(uint32_t); 
break; 
} 
return r; 


这 段 代 码 分 为 以 下 步骤 来 处 理 BR_TRANSACTI1ON : 


e 初始 化 reply; 
ee A Se nel 
o 将 处 理 结 果 通 过 Binder 驱 动 返 回 给 发 送 请 求 的 客户 端 。 








特别 说 明 一 下 ，reply 是 一 个 binder_ io 变量 ， 这 是 Service 


Manager 内 部 的 一 种 数据 类 型 。 其 主要 的 内 部 成 员 释 义 如 下 : 


struct binder_io 








{ 
char *data; /* 数据 区 当前 地 址 */ 
uint32_t *offs; /* offset 区 当前 地 址 */ 
uint32_t data avail; /* 数据 区 剩余 空间 */ 
uint32_t offs_avail; /* offset 区 剩余 空间 */ 
char *data0; /* 数据 区 起 始 地 址 */ 
uint32_t *offs0; /* offset 区 起 始 地 址 */ 
uint32_t flags; 
uint32_t unused; 

}; 


这 几 个 成 员 变 量 的 取 名 确实 不 太 合理 ， 严 重 影响 了 大 脑 运转 。 


住 ， 它 其 实 是 划分 了 两 个 区 域 ， 即 data 区 和 offs 区 ; 而 每 个 区 又 分 别 有 
J 所 以 ， 一 共有 data、data0、offs 和 offs0 共 4 
个 地 址 指针 。 


先 来 看 看 如 何 初始 化 reply: 


void bio_init(struct binder_io *bio, void *data,uint32_t maxdata, 


{ 
uint32_t n = maxoffs * sizeof(uint32_t); // 最 大 可 偏 移 4 个 ， 共 16 字 


if (n > maxdata) { //maxdata 为 256 
bio->flags = BIO_F OVERFLOW, 
bio->data_avail 
bio->offs_avail 
return; 


ool 


J 


bio->data = bio->data0 = (char *) data + n; 
bio->offs = bio->offsO = data; 

bio->data_avail = maxdata - n; 

bio->offs_avail = maxoffs; // 注 意 它 的 起 始 值 是 4， 不 是 16 
bio->flags = 0; 


和 Parce1 相 比较 ， 我 们 可 以 得 出 初步 的 结论 : binder_iowService 
Manager 内 部 用 于 存储 binder ob ject 的 一 种 数据 结构 。 


接着 程序 调用 res = func(bs，txn，&msg，&reply) 来 处 理 ， 而 
func 已 经 被 注册 为 svcmgr_handler。 这 些 知 识 在 前 面 几 个 小 节 都 已 经 分 


Switch(txn->code) { 
case SVC_MGR_GET_SERVICE: 
case SVC_MGR_CHECK_SERVICE: 
s = bio_get_stringi6(msg, &len); 
ptr = do_find_service(bs, s, len, txn->sender_euid) ;/* #4 
if (!ptr) 
break; 
bio_put_ ref(reply, ptr); / aR Areply#*/ 





在 svcmgr_handler 中 ， 针 对 getServi ce 请求 
(SVC_MGR_GET_SERVICE) ， 首 先 调用 do_find_service 进 行 查找 : 如 果 
顺利 的 话 就 会 返回 一 个 void* 类 型 的 ptr， 这 就 是 最 后 要 转化 成 IlBinder 


的 那个 指针 。 然 后 把 这 个 指针 写 入 reply 中 ， 即 上 面 的 binder_io 变 量 。 


读者 可 能 会 有 这 样 的 疑问 : ptr 是 个 什么 值 呢 ? 要 回答 这 个 问题 ， 
就 要 看 addServi ce 时 在 Servi ce Manger 中 存 入 了 什么 。 在 SM 中 添加 一 个 
Service 的 过 程 和 getService 非 常 类 似 ， 重 复 的 部 分 不 再 歼 述 ， 直 接 来 
看 看 Service Manager 对 SVC MGR ADD _SERV1CE 的 处 理 : 


case SVC_MGR_ADD_SERVICE: 
s = bio_get_stringi6(msg, &len); 
ptr = bio_get_ref(msg); 
allow_isolated = bio_get_uint32(msg) ? 1: 0; 
if (do_add_service(bs, s, len, ptr, txn->sender_euid, allo 
return -1; 
break; 


可 见 ，ptr 这 个 值 是 在 bio_get_ref 中 获得 的 : 


void *bio get_ref(struct binder_io *bio) 


{ 
struct binder_object *obj; 
obj = _bio_get_obj(bio); 
if (obj->type == BINDER_TYPE_HANDLE) 
return obj->pointer; 
return 0; 
} 


Bein Rix Ph eye se: 它 根 据 用 户 传 进来 的 binder_object 的 
类 型 ， 即 obj 一 type 来 为 前 面 的 ptr 赋 值 。Binder 中 共有 以 下 几 种 ob ject 
类 型 ， 在 Binder. h 中 定义 : 


enum { 

BINDER_TYPE_BINDER = B_PACK_CHARS('s', 'b', '*', B_TYPE_LARGE), 
BINDER_TYPE_WEAK_BINDER = B_PACK_CHARS('w', 'b', '*', B_TYPE_LAR 
BINDER_TYPE_HANDLE = B_PACK_CHARS('s', 'h', '*', B_TYPE_LARGE), 
BINDER_TYPE_WEAK_HANDLE = B_PACK_CHARS('w', ‘h', '*', B_TYPE_LAR 
BINDER_TYPE_FD = B_PACK_CHARS('f', 'd', '*', B_TYPE_LARGE), 

}; 








其 中 前 两 种 只 能 是 针对 Binder Client 和 Binder Server 在 同一 个 进 
程 中 的 情况 ， 而 后 两 种 因为 传递 的 是 Binder 句 柄 也 就 没有 任何 限制 了 。 
比如 ，A 知 道 一 家 著名 餐馆 的 电话 号 码 ， 之 后 把 它 给 了 B， 那 么 B 就 可 以 


在 任何 时 候 和 凭借 这 个 电话 号 码 与 餐馆 建立 联系 了 。 


— Binder Client 调 用 ServiceManager. addService 将 自己 添加 到 
Service Manager 时 ， 实 际 上 一 开始 这 个 object 的 类 型 是 
BINDER _TYPE_BINDER， 不 过 到 了 Binder 驱 动 中 ， 这 个 值 就 变 成 了 
BINDER_TYPE_HANDLE。 或 者 也 可 以 这 样 理解 : BINDER_TYPE_BINDER 代 表 
的 是 内 存 地 址 ， 所 以 直接 发 送 给 另 一 个 进程 并 没有 实际 的 意义 ; 而 
BINDER_TYPE_HANDLE 是 这 个 ob ject 在 Binder 驱 动 中 的 id 号 一 一 通过 这 个 
号 码 最 终 可 以 找到 对 应 的 目标 C1ient/Server。Binder 驱 动 负责 对 它们 
进行 转换 ， 代 码 如 下 所 示 。 


static void binder_transaction(struct binder_proc *proc,struct bi 
struct binder_transaction_data *tr, int rep 
{ 


switch (fp->type) { 
case BINDER_TYPE_BINDER: 
case BINDER_TYPE_WEAK_BINDER: { 





if (fp->type == BINDER_TYPE_BINDER) 
fp->type = BINDER_TYPE_HANDLE;// 类 型 变 了 
else 
fp->type = BINDER_TYPE_WEAK_HANDLE; 
fp->handle = ref->desc;// 值 也 相应 的 产生 了 变化 





因而 bio_get_ref 产 生 的 对 象 最 终 的 类 型 是 BINDER_TYPE_HANDLE， 
ptr 就 是 Binder 的 句柄 值 。 
得 到 这 个 句柄 值 后 ， 我 们 需要 把 它 写 入 回复 中 : 


bio_put_ref(reply, ptr); 


由 之 前 对 reply 的 初始 化 操作 可 知 ，reply 中 的 offset 区 域 得 到 16 字 
节 的 空间 ， 其 余 为 data 区 域 。 回 到 bio_put_ref 中 看 看 对 reply 做 了 什么 
操作 : 
void bio_put_ref(struct binder_io *bio, void *ptr)// 这 个 函数 的 bio 参 
{ 


struct binder_object *obj; 


if (ptr) 


obj = bio_alloc_obj(bio); //ptr 是 之 前 SM 查 表 得 到 的 服务 对 应 的 句 术 
else 
obj = bio_alloc(bio, sizeof(*obj)); 


obj->flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS; 
obj->type = BINDER_TYPE_HANDLE; // 注 意 这 个 类 型 ， 后 面 还 会 遇 到 
obj->pointer = ptr; // 将 ptr 保 存 到 obj 中 

obj->cookie = 0; 





这 个 函数 ; 入 有 返回 信 ， 因而 可 以 猜想 到 新 创建 的 obj 一 定 会 与 reply 
有 直接 的 关系 。 答 案 可 以 从 下 面 这 个 函数 中 找到 : 


static struct binder_object *bio_alloc_obj(struct binder_io *bio) 
{ 
struct binder_object *obj; 
obj = bio alloc(bio，sizeof(*0obj));// 确 定 obj 的 具体 地 址 
if (obj && bio->offs avail) { 
bio->offs_avail--; // 个 数 减 一 
*bio->offs++ = ((char*) obj) - ((char*) bio->data0);/* 原 来 
data 区 域 的 写 入 大 小 的 ， 这 是 “可 变 长 度数 据 ” 的 一 种 存 

















return obj; 


} 


bio->flags |= BIO_F_OVERFLOW; 
return 0; 


上 面 代码 段 中 的 bio_al loc 和 上 面 分 析 过 的 writelnplace 作 用 类 
似 ， 即 确定 将 要 写 入 数据 的 起 始 和 结束 位 置 ， 同 样 以 4 对 齐 ， 所 以 obj 就 
写 入 的 数据 区 起 始 位 置 (这 个 位 置 是 在 reply 的 data 区 域 中 
的 ) 。 这 意味 着 对 obj 写 入 数据 ， 实 际 上 就 是 写 入 reply 的 data 区 域 中 。 


到 这 里 基本 上 就 清楚 了 ，reply 存 入 了 一 个 binder_object 数 据 结 
构 ， 类 型 为 BINDER _TYPE_HANDLE。 而 binder_objcet. pointer 中 是 SM 查 
找到 的 Service 的 指针 “将 最 终 被 转换 成 lbinder) 。 


一 切 准备 就 绪 后 ， SM 便 要 将 结果 发 送 给 Binder 驱 动 。 可 想 而 知 ， 数 
据 格式 必须 遵守 Binder 协 议 的 规定 ， 因 而 填充 过 程 很 重要 : 


void binder_send_reply(struct binder_state *bs,struct binder_io * 


struct { 
uint32_t cmd_free; 


{ 


} 


data. 
data. 
data. 
data. 
data. 
data. 


if ( 
/1 
} el 


} 
bind 


void *buffer; 
uint32_t cmd_reply; 
struct binder_txn txn;// 对 应 Bijnder 驱 动 中 的 binder_transactio 


__attribute__((packed)) data; 


cmd_free = BC_FREE_BUFFER; 
buffer = buffer_to_free; 


cmd_reply = BC_REPLY; /7 注意 这 里 的 命令 类 型 
txn.target = 0; 
txn.cookie = 0; 


txn.code = 0; 

status) { 

省 略 ，status 用 于 指示 之 前 操作 有 没有 error 

se {// 没 有 error 的 情况 

data.txn.flags = 0; 

data.txn.data_size = reply->data - reply->data0; 
data.txn.offs_size = ((char*) reply->offs) - ((char*) r 
data.txn.data = reply->data0; //reply 中 数据 区 起 始 地 址 
data.txn.offs = reply->offs0; //offset 区 起 始 地 址 

















er_write(bs, &data, sizeof(data));//% ABinder Jka 


这 个 函数 里 又 定义 了 一 个 数据 结构 data， 其 中 最 重要 的 变量 是 
txn。 可 以 看 到 ，txn 中 保存 了 reply 中 的 数据 和 offset 区 的 起 始 地 址 : 


int binder_write(struct binder_state *bs, void *data, unsigned le 


stru 
int 
bwr 
bwr 
bwr 
bwr. 
bwr. 
bwr. 
res 


retu 


ct binder_write_read bwr; 
res; 


.write_size = len; 
.write_consumed = 0; 
.write_buffer = (unsigned) data; // 将 data 传 入 到 bwr 中 


read_size = 0;// 不 读 取 数据 ， 只 写 入 

read_consumed = 0; 

read_buffer = 0; 

= jioctl(bs->fd, BINDER_WRITE_READ, &bwr); // 与 Binder 驱 动 交 


rn res; 


这 个 函数 中 有 两 个 重要 步 又。 


。 将 相关 数据 填 入 binder_wtite_read。 不 管 之 前 SM 定义 了 多 少 内 部 数 
据 结 构 ， 它 与 Binder 驱 动 交 互 就 得 遵守 后 者 的 数据 规范 ， 包 括 


binder_write_read 和 和 binder_txn 等 。 
e 调用 ioctl 将 命令 发 送 给 Binder Driver. 


然后 就 进入 
er ioctl binder thread write>binder transaction 进 行 处 
这 和 我 们 之 前 分 析 的 情况 基本 大 同 小 异 ， 因 而 下 面 只 列 出 不 同 的 部 


ZX 


首先 会 进入 binder_thread write， 命令 类 型 为 BC_REPLY。 由 以 前 
的 分 析 可 知 ， 它 和 BC_TRANSACTION 一 样 都 是 在 binder_ transaction 中 处 
理 的 : 


static void binder_transaction(struct binder_proc *proc, struct b 
struct binder_transaction_data *tr, int rep 


wl / ZEREM MDEE SA, ANE 
if (reply) {//BC_REPLY 的 情况 
in_reply_to = thread->transaction_stack; //4& 2 #“reply”# 














thread->transaction_stack = in_reply_to->to_parent; 
target_thread = in_reply_to->from;// 目 标 对 象 所 在 线程 


target_ proc = target_thread->proc;// 目 标 对 象 所 在 进程 
} else ELE TRANSACTION 的 情况 





和 BC_TRANSACTION 同 理 ，BC_REPLY 显 然 也 要 先 找 到 目标 进程 / 线 
程 ， 即 谁 发 起 了 这 个 transaction。 根 据 之 前 的 分 析 ，Service Manager 


会 在 thread->transaction_stack 中 保存 这 一 信息 ， 因 而 就 有 根 可 寻 
Ja 如 下 : 


in_reply_to = thread->transaction_stack; 


有 了 这 个 基础 ， 其 他 的 就 都 好 办 了 


target_thread = in_reply_to->from; 
target_proc = target_thread->proc; 
if (target_thread) { 
e->to_thread = target_thread->pid; 
target_list &target_thread->todo; 
target_wait &target_thread->wait; 
} else { 


target_list 
target_wait 


&target_proc->todo; 
&target_proc->wait; 


t 


紧 接 着 找 出 目标 的 target_1ist 和 target_wait， 这 在 后 面 都 要 用 
FI): 


/* TODO: reuse incoming transaction for reply */ 
t = kzalloc(sizeof(*t), GFP_KERNEL); 


tcomplete = kzalloc(sizeof(*tcomplete), GFP_KERNEL); 


还 是 和 BC_TRANSACTION 类 似 ，BC_REPLY 也 生成 了 t 和 tcomplete。 其 
中 t 是 给 目标 对 象 的 ， 而 tcomp lete 是 给 命令 发 起 者 自己 的 。 只 不 过 这 里 
的 目标 和 命令 发 起 者 与 之 前 相反 目标 对 象 是 Binder Client， 
BC_REPLY 的 发 起 者 是 Service Manager : 





if (!reply && !(tr->flags & TF_ONE_WAY) ) 
t->from = thread; 
else 
t->from = NULL; 
..// 给 变量 t 赋 值 过 程 省 略 (和 BC_TRANSACTION 完 全 一 样 ) 
if (copy_from_user(t->buffer->data, tr->data.ptr.buffer, tr- 
/* 从 ServiceManager 进 程 空间 复制 数据 */ 





if (copy_from_user(offp, tr->data.ptr.offsets, tr->offsets_s 
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上 面 这 段 代 码 主要 给 t 赋 值 ， 和 BC_TRANSACTION 完 全 一 样 ， 读 者 可 
以 看 看 。 不 过 因为 Service Manager 这 次 带 了 一 个 binder_ob ject， 所 以 
接 下 来 要 对 这 个 ob ject 进 行 必要 的 处 理 〈 即 之 前 讲解 过 的 
BINDER_TYPE_HANDLE 和 BINDER_ TYPE_BINDER 之 间 的 转换 ) 。 如 下 所 示 : 





off_end = (void *)offp + tr->offsets_size;/*offset 区 域 的 结束 地 
for (; offp < off_end; offp++) {/*object 可 能 不 只 一 个 */ 
struct flat_binder_object *fp; 


fp = (struct flat_binder_object *)(t->buffer->data + *o 
switch (fp->type) { 


case BINDER_TYPE_HANDLE: 
case BINDER_TYPE_WEAK_HANDLE: {// 如 果 这 个 object 的 类 型 是 HAN 
struct binder_ref *ref = binder_get_ref(proc, fp-> 





if (ref->node->proc == target_proc) {// 目 标 进程 和 obj 

if (fp->type == BINDER TYPE_HANDLE) 

fp->type = BINDER_TYPE_BINDER;// 直 接 可 以 使 
else 

fp->type = BINDER_TYPE_WEAK_BINDER; 
fp->binder = ref->node->ptr; 
fp->cookie = ref->node->cookie; 
binder_inc_node(ref->node, fp->type == BINDER 

©, NULL); 





} else {/*object 不 在 目标 进程 的 范围 */ 
struct binder_ref *new_ref; 
new_ref = binder_get_ref_for_node(target_proc 





fp->handle = new_ref->desc; 
binder_inc_ref(new_ref, fp->type == BINDER_TY 
} 
} break; 


default: 
.…// 出 错 处 理 
} 














} 


上 面 代 码 段 只 保留 BINDER_TYPE_HANDLE 的 处 理 ， 因 为 这 是 Service 
Manager 传 过 来 的 Binder 0b ject 的 类 型 ( 见 Service Manager PAY 
bio_put_ref) 。 可 以 看 到 ， 这 里 主要 对 最 终 会 传递 给 调用 者 的 Binder 
Object 进行 了 一 次 转换 。 


e binder_get_ref 


通过 handle 值 查找 与 此 binder ob ject 相 关联 的 binder_ref， 这 个 
是 调用 addServi ce 服务 时 创建 的 。 


e 调用 getService 服 务 的 进程 和 Binder Object 所 属 进 程 是 不 是 同一 个 ? 
正如 我 们 一 直 强 调 的 ， 不 同 进 程 间 的 内 存 空 间 是 没有 办 法 直接 相互 


访问 的 ; 反之 ， 如 果 它 们 属于 同一 个 进程 空间 ， 那 么 就 可 以 直接 将 
Binder 0bject 的 内 存 地 址 传 给 调用 者 ; 否则 ， 调 用 者 就 只 能 通过 


handle 值 来 与 对 方 通信 了 。 


因为 一 般 情 况 下 ref->node->proc 不 会 等 于 target_proc， 所 以 程序 
走 的 是 上 述 代码 段 的 el se 分 支 。 大 家 可 以 根据 上 面 的 分 析 进 行 理解 : 


if (reply) { 
BUG_ON(t->buffer->async_transaction != 0); 
binder_pop_transaction(target_thread, in_reply_to); 
} else if (!(t->flags & TF_ONE_WAY)) { 


} else { 


t->work.type = BINDER_WORK_TRANSACTION; //\b 4284! 

list_add_tail(&t->work.entry，target_1list);// 添 加 到 目标 进程 的 tc 

tcomplete->type = BINDER_WORK_TRANSACTION_COMPLETE; 

list_add_tail(&tcomplete->entry，,，&thread->todo);// 添 加 一 个 “未 5 

if (target_wait) 
wake_up_interruptible(target_wait ) ;// 唤 醒目 标 进程 

return; 





ERMA, PERMA Ss. Mics? 当时 
getService 的 调用 者 Binder Client 在 经 过 一 系列 的 函数 调用 后 ， 即 : 
waitForResponse (1PCThreadState) 一 talkWithDr iver 
(1PCThreadState) 
4binder_ioct! (Binder. c) 一 binder_ thread_read(Binder. c) ， 就 进入 
睡眠 等 待 了 一 一 此 时 它 发 起 的 服务 请 求 已 经 有 回复 了 ， 所 以 就 需要 重新 
唤醒 起 它 来 接收 结果 。 


而 Service Manager 的 队列 中 也 加 入 了 一 个 类 型 为 
BINDER_WORK_TRANSACTION_COMPLETE 的 tcomplete， 因 而 它 首 先 会 通过 
binder_thread_read 读 取 并 处 理 这 个 事项 ， 然 后 在 第 二 次 的 
binder_thread_read 中 再 次 进入 睡眠 等 待 ， 直 到 有 Binder Client 向 它 
发 起 新 的 服务 请 求 。 


下 面 看 看 当 调用 者 被 唤醒 后 的 操作 。 前 面 已 经 分 析 过 ， 这 时 Binder 
Client 是 在 binder_ thread _read 中 睡眠 的 。 具 体 是 : 


ret = wait_event_freezable (thread->wait, binder_has_thread_work( 


我 们 接着 这 条 语句 往 下 走 : 


while (1) { 
uint32_t cmd; 
struct binder_transaction_data tr; 
struct binder_work *w; 
struct binder_transaction *t = NULL; 




















if (!list_empty(&thread->todo))//todo 1ist 中 有 可 处 理事 项 
w = list first entry(&thread->todo, struct binder_ 
else if (!list_empty(&proc->todo) && wait_for_proc_work 
w = list_first_entry(&proc->todo, struct binder_wo 
else 4.. 


} 


前 面 Service Manager 在 thread->todo 队 列 中 插入 了 一 个 工作 事 
项 ， 这 里 就 通过 w 把 它 取 出 来 : 


if (end - ptr < sizeof(tr) + 4) 
break; 
Switch (w->type) { 
case BINDER_WORK_TRANSACTION: { 
t = container_of(w, struct binder_transaction, wor 
} break; 


} 


这 个 binder_work 的 类 型 是 BINDER_WORK_TRANSACTION， 通 过 w 在 
binder_ transaction 中 的 位 置 取 得 t: 


if (t->buffer->target_node) { 
struct binder_node *target_node = t->buffer->targe 
tr.target.ptr = target_node->ptr; 
tr.cookie = target_node->cookie; 


cmd = BR_TRANSACTION; // 注 意 业 务 类 型 
} else { 


} 

tr.code = t->code; 

tr.flags = t->flags; 
tr.sender_euid = t->sender_euid; 


if (t->from) { 
struct task_struct *sender = t->from->proc->tsk; 


tr.sender_pid = task_tgid_nr_ns(sender, current->ns 
} else { 
tr.sender_pid = 0; 


tr.data_size = t->buffer->data_size;// 数 据 区 域 大 小 
tr.offsets_size = t->buffer->offsets_size;//offset 区 域 大 
tr.data.ptr.buffer = (void *)t->buffer->data +proc->use 


tr.data.ptr.offsets = tr.data.ptr.buffer +ALIGN(t->buff 
sizeof(void * 


上 面 这 段 代 码 用 于 准备 将 要 发 送 给 调用 者 进程 的 数据 ， 其 中 的 逻辑 
比较 简单 且 大 多 已 经 讲解 过 ， 读 者 可 以 自行 分 析 各 个 变量 的 含义 : 


if (put_user(cmd, (uint32_t _ user *)ptr)) 
return -EFAULT; 

ptr += sizeof(uint32_t); 

if (copy_to_user(ptr，&tr，sizeof(tr)))V/ 将 数据 复制 到 用 户 
return -EFAULT; 

ptr += sizeof(tr); 


将 准备 好 的 数据 复制 到 调用 者 空间 中 : 





list_del(&t->work.entry);// 删 除 t 

t->buffer->allow_user_free = 1; 

if (cmd == BR_TRANSACTION && !(t->flags & TF_ONE_WAY) ) 
t->to_parent = thread->transaction_stack; 
t->to_thread = thread; 
thread->transaction_stack = t; 

} else { 

} 


break; 


t 


对 t 的 处 理 已 经 结束 ， 因 而 可 以 把 它 删除 ; 而 且 如 果 不 是 
BR_TRANSACTION 的 话 ， 就 不 用 再 保存 transaction_stack。 这 样 调用 者 
就 执行 完 binder_thread_read 了 ， 之 后 它 先 返回 binder_ioct1， 然 后 回 
到 用 户 进 程 空间 中 的 talkWithDr iver 。 因 为 读 取 到 了 数据 ， 程 序 还 需要 
对 mln 进 行 调整 ， 之 前 已 经 多 次 讲解 过 ， 这 里 不 骨节 述 。 


最 后 回 到 waitForResponse@1PCThreadState， 来 看 看 它 对 BR_REPLY 


的 处 理 : 


case BR_REPLY: 
{ 
binder_transaction_data tr; 
err = mIn.read(&tr, sizeof(tr));//i HAE 


if (err != NO_ERROR) goto finish; 
if (reply) { 
if ((tr.flags & TF_STATUS_CODE) == 0) { 
reply->ipcSetDataReference(reinterpret_ca 
(tr.data. ptr.buffer),tr.data_size, reinterpret_cast<const size 
tr.offsets_size/sizeof(size_t), 
} else {..// 错 误 处 理 














} 
} else {..// 当 reply 为 NULL 的 情况 
} 





} 
goto finish;// 跳 出 while 循 环 ， 从 而 结束 waitForResponse 


程序 首先 从 mln 中 读 取 到 transaction 的 标准 格式 数据 ， 即 tr 。 我 们 
知道 reply 是 不 为 空 的 ， 且 tr. flags 中 也 不 含有 TF_STATUS_C0DE 标 志 ， 
所 以 上 面 代码 段 中 最 重要 的 一 句 就 是 调用 ipcSetData Reference 对 数据 
进行 处 理 ， 它 是 Parcel. cpp 中 的 一 个 函数 : 


void Parcel::ipcSetDataReference(const uint8_t* data, size_t data 
const size_t* objects, size_t objectsCount, r 
void* relCookie) 


freeDataNoInit(); 

mError = NO_ERROR; 

mData = const_cast<uint8_t*>(data); 

mDataSize = mDataCapacity = dataSize; 

mDataPos = 0; 

ALOGV("sSetDataReference Setting data pos of %p to %d\n", this 
mObjects = const_cast<size_t*>(objects); 
mObjectsSize = mObjectsCapacity = objectsCount; 
mNextObjectHint = 0; 

mOwner = relFunc; 

mOwnerCookie = relCookie; 

scanForFds(); 


TRAE AAILTEAS: 


e data; 
e dataSize; 
e objects; 


e objectsCount. 


前 面 两 个 参数 分 别 表示 数据 区 及 它 的 大 小 ， 后 面 两 个 就 是 Binder 
Object 区 (offset 区 ) 和 它 的 大 小 。 在 我 们 的 场景 中 ，0bject 的 个 数 是 
1。 


在 这 个 例子 中 ， 调 用 者 向 Service Manager 发 起 了 
getService (name) 请 求 ， 因 而 对 它 而 言 最 重要 的 数据 就 是 name 所 对 应 的 
Binder Object 可 以 猜想 到 ipcSetDataReference 这 个 国 数 必定 与 此 
有 关联 。 它 把 从 Binder Driver 中 读 取 的 Servi ce Manager 的 回复 〈 存 储 
在 mln 中 ) 填 入 reply 这 个 Parce1 中 ， 以 供 后 续 程 序 读 取 时 使 用 。 这 样 整 
个 函数 的 逻辑 就 很 简单 ， 主 要 是 做 了 些 赋值 操作 ， 大 家 可 以 自行 阅读 。 


当 waitForResponse 处 理 完 BR_REPLY 后 ， 就 直接 跳 转 (goto) 到 
finish 来 结束 整个 whi le 主 循环 了 。 之 后 通过 层 层 返回 ， 最 终 来 到 我 们 
getService 场 景 的 发 源 地 ， 即 ServiceManagerProxy 中 的 getService () 
中 《注意 ， 此 时 已 经 到 了 Java 层 ) : 


mRemote. transact (GET_SERVICE_TRANSACTION, data, reply, 0);/*x 
代码 都 是 基于 这 个 
IBinder binder = reply.readStrongBinder(); 
// 执 行 到 这 里 ， 说 明 已 经 收 到 Service Manager 的 回复 了 
reply.recycle(); 
data.recycle(); 
return binder; 


执行 完 transact 后 ，reply 中 就 有 我 们 想 要 的 查询 结果 了 。 不 过 流 
程 并 未 结束 ， 还 需要 将 这 一 结果 读 取出 来 ， 并 转换 成 lbinder， 即 
readStrongBinder 。 我 们 跳 过 此 函数 的 中 间 过 程 ， 直 接 来 分 析 其 native 
层 的 实现 : 


sp<IBinder> Parcel::readStrongBinder() const 


{ 





sp<IBinder> val; 
unflatten_binder(ProcessState::self(), *this, &val); 
return val; 


通常 情况 下 ，unfaltten_binder 和 flatten_binder 是 需要 配套 使 用 
的 ， 不 过 在 此 场景 中 Service Manager 并 没有 直接 使 用 Parce1， 而 是 使 
用 了 与 flatten binder 等 价 的 其 他 实现 : 


status_t unflatten binder(const sp<ProcessState>& proc,const Parc 
{ 
const flat_binder_object* flat = in.readObject(false); /* 读 取 - 
if (flat) { 
switch (flat->type) { 
case BINDER_TYPE_BINDER: // 同 进程 的 话 是 这 种 类 型 
*out = static_cast<IBinder*>(flat->cookie); 
return finish_unflatten_binder(NULL, *flat, in); 
case BINDER_TYPE_HANDLE: // 不 同 进程 的 话 是 这 种 类 型 
*out = proc->getStrongProxyForHandle(flat->handle 
return finish_unflatten_binder(static_cast<BpBind 
} 
} 


return BAD_TYPE,; 


看 到 flat_binder_object 大 家 应 该 很 熟悉 吧 ， 所 有 的 努力 都 是 冲 这 
个 来 的 。 首 先 从 reply 这 个 Parce1 中 读 取 出 flat_binder _ object， 然 后 
根据 类 型 来 区 分 处 理 。 关 于 binder 次 讲解 ， 这 里 显然 
是 属于 BINDER_TYPE_HANDLE 这 种 情况 ， 因 而 就 调用 
i rr ey i E A 这 
个 函数 之 前 也 已 经 磁 到 过 (hand1e 为 0 的 情况 ， 即 Service Manager) 

这 里 再 来 看 看 对 于 普通 Binder Server 会 有 什么 不 同 : 


sp<IBinder> ProcessState: :getStrongProxyForHandle(int32_t handle) 
{ 

sp<IBinder> result; 

AutoMutex _1(mLock); 


handle_entry* e = lookupHandleLocked (handle) ;//%¢ #4 4 Hid ae 


if (e != NULL) {//e 通 常情 况 不 会 是 NULL 

IBinder* b = e->binder; 

if (b == NULL || !e->refs->attemptIncWeak(this)) { 
b = new BpBinder (handle); // 无 法 增加 引用 或 者 b 为 NULL 
e->binder = b; 
if (b) e->refs = b->getWeakRefs(); 
result = b; 

} else { 
result.force_set(b); 














e->refs->decWeak(this); 


} 


return result; 


} 


可 以 看 到 ， 主 体 流程 没有 任何 差异 。 首 先 查 找 本 地 是 否 已 经 有 这 个 
1Binder 记 录 ， 以 避免 重复 操作 ; 否则 就 通过 new BpBinder 创 建 一 个 新 
的 Proxy 即便 有 记录 ， 但 增加 引用 时 失败 也 同样 要 重新 创建 ) ， 最 重 
要 的 就 是 为 这 个 新 BpBinder 添 加 hand1e 值 属性 。 最 终 返 回 给 调用 者 的 是 
一 个 sp 指针 ， 内 部 指向 这 个 BpBinder (强制 类 型 转换 成 了 lbinder) 。 


成 功 通过 readStrongBinder 获 取 到 1Binder 对 象 后 ， 
getService@ServiceManagerProxy 的 任务 就 结束 了 ， 最 终 
ServiceManager. getService 的 调用 者 得 到 的 就 是 这 个 对 象 。 这 样 我 们 
以 ServiceManager 提 供 的 getService 服 务 为 例 ， 完 整地 训 析 了 Binder 
Client 获 取 Binder Server 的 全 过 程 。 


虽然 本 小 节目 标 很 简单 〈 获 取 getService 服 务 ) ， 但 因为 同时 涉及 
了 JNI1、Binder 驱 动 、Binder 上 层 建 筑 等 一 系列 处 理 流程 ， 使 得 整个 分 
析 过 程 可 谓 “ 山 路 十 八 弯 ”， 困 难 重重 。 其 中 的 一 些 重点 元 素 罗 列 如 
aR: 


e ServiceManagerProxy 


当 某 个 Binder Server 在 启动 时 ， 会 把 自己 的 名 称 name 与 对 应 的 
Binder 句 柄 值 保 存在 ServiceManager 中 。 调 用 者 通常 只 知道 Binder 
Server 的 名 称 ， 所 以 必须 先 向 Service Manager 发 起 查询 请 求 ， 就 是 


getService (name) 。 


而 Service Manager 自 身 也 是 一 个 Server， 就 好 像 互 联网 上 的 DNS 服 
务 器 本 身 也 需要 提供 1P 地 址 才能 被 访问 一 样 。 只 不 过 这 个 IP 地 址 是 预先 
就 设 定好 了 的 《句柄 值 为 0) ， 因 而 任何 Binder Client 都 可 以 直接 通过 
0 这 个 Binder 句 柄 创建 一 个 BpBinder， 再 通过 Binder 驱 动 去 获取 Service 
Manager 的 服务 。 具 体 而 言 ， 就 是 调用 
Binder Internal. getContext0bject () 来 获得 Service Manager AY 
BpBinder。 


Android 系 统 同 时 支持 Java 与 6/C++ 层 的 Binder 机 制 ， 因 而 很 多 对 象 


都 必须 有 “双重 身份 ”， 如 BpBinder 在 Java 层 以 1Binder 来 表示 。 对 于 
Service Manager 而 言 ，I1Binder 的 真正 持 有 者 与 使 用 者 是 
ServiceManagerProxy 一 一 它 是 Servi ce Manager 在 本 地 的 代表 ， 我 们 在 
设计 小 节 曾 以 “留学 服务 中 心 ”为 例 做 过 类 比 。 


e ProcessState#2#1PCThreadState 


大 多 数 程序 都 有 1PC 的 需要 ， 而 进程 间 通 信 本 身 又 是 非常 烦琐 的 ， 
因而 Android 系 统 特别 为 程序 进程 使 用 Binder 机 制 封装 了 两 个 实现 类 ， 
即 ProcessState 和 1PCThreadState。 从 名 称 上 可 以 看 出 ， 前 者 是 进程 相 
关 的 ， 而 后 者 是 线程 相关 的 。 ProcessState 负 责 打 开 Binder 驱 动 设 备 ， 
进行 mmap () 等 准备 工作 ; 而 如 何 与 Binder 驱动 进 行 具体 的 命令 通信 则 由 
1IPCThreadState 来 完成 。 


在 getService () 这 个 场景 中 ， 调 用 者 是 从 Java 层 的 
IBinder. transact () 开始 ， 层 层 往 下 调用 到 
IPCThreadState. transact () ， 然 后 通过 waitForResponse 进 入 主 循环 
一 一 直至 收 到 Servi ce Manager 的 回复 后 才 跳 出 循环 ， 并 将 结果 再 次 层 
ace 本 小 节 的 大 部 分 源码 内 容 就 是 在 waitForResponse 里 
展开 的 。 


真正 与 Binder 驱动 打 交道 的 地 方 是 talkWithDriver 中 的 ioct10， 
整个 流程 中 多 次 调用 了 这 个 函数 。 


e Bindet 驱 动 


在 这 个 场景 中 ， 主 要 涉及 了 Binder 驱 动 提 供 的 binder_ioct1， 
binder_thread write, binder thread read 和 binder _transaction 等 
几 个 重要 的 函数 实现 。Binder 驱 动 通过 巧妙 的 机 制 来 使 数据 的 传递 更 加 
高 效 ， 即 只 需要 一 次 复制 就 可 以 把 数据 从 一 个 进程 复制 到 另 一 个 进程 。 
Binder 中 还 保存 着 大 量 的 全 局 以 及 进程 相关 的 变量 ， 用 于 管理 每 个 进 
程 /线程 的 状态 、 内 存 申请 和 待 办 事项 装 一 系列 复杂 的 数据 信息 。 正 是 
这 些 变量 的 有 效 协 作 ， 才 使 得 整个 Binder 通 信和 真正 “ 动 ” 了 起 来 。 


e Service Managet 的 实现 


ServiceManager 在 Android 系 统 启 动 之 后 就 运行 起 来 了 ， 并 通过 
BINDER_SET_CONTEXT_MGR 把 自己 注册 成 Binder “大 管家 ”。 它 在 做 完 一 


系列 初始 化 后 ， 在 最 后 一 次 ioct1 的 read 操 作 中 会 进入 睡眠 等 待 ， 直 到 
有 Binder Client 发 起 服务 请 求 而 被 Binder 驱 动 唤醒 。 


Service Manager 唤 本 后 ， 程 序 分 为 两 条 主线 索 : 其 一 ，Service 
Manager 端 将 接着 执行 read 操 作 ， 把 调用 者 的 具体 请 求 读 取 出 来 ， 然 后 
利用 binder_parse 解 析 ， 再 根据 实际 情况 填写 transaction 人 信息， 最 后 
把 结果 通过 BR_REPLY 命 令 〈 也 是 ioct1) 返回 Binder 驱 动 。 


其 二 ， 发 起 getService 请 求 的 Binder Client 在 等 待 Service 
Manager 回 复 的 过 程 中 会 进入 休眠 ， 直 到 被 Binder 驱 动 再 次 唤醒 一 一 它 
和 Service Manager 一 样 也 是 在 read 中 睡眠 的 ， 因 而 醒 来 后 继续 执行 读 
取 操 作 。 这 一 次 得 到 的 就 是 Service Manager 对 请 求 的 执行 结果 。 程 序 
先 把 结果 填充 到 reply 这 个 Parce1 中 ， 然 后 通过 层 层 返回 到 
ServiceManagerProxy， 有 再 利用 Parcel. readStrongBinder 生 成 一 个 
BpBinder， 最 终 经 过 类 型 转换 为 1Binder 对 象 后 传 给 调用 者 。 


这 样 整个 ServiceManager. getServ ice () 的 流程 就 都 分 析 完 了 。 不 
过 对 于 调用 者 来 说 ， 万 里 长 征 才 刚刚 开始 。 得 到 的 1Binder 对 象 要 先 经 
过 aslnterface 做 一 次 包装 ， 如 ServiceManager 的 BpBinder 就 被 包装 成 
了 lserviceManager (实际 上 就 是 一 个 ServiceManagerProxy) 。 这 么 做 
的 目的 在 于 可 以 让 应 用 程序 更 加 方便 地 使 用 Service Manager 提 供 的 服 
务 〈 其 他 Binder Server 也 类 似 ) 。 这 些 知 识 点 在 本 小 节 的 分 析 过 程 中 
都 已 经 讲解 过 ， 大 家 如 果 还 有 疑问 ， 可 以 回头 复习 下 。 


总 结 整 个 getService 的 调用 流程 ， 如 图 6-20 所 示 。 
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全 图 6-20 ”getService 调 用 流程 图 


图 6-20 分 为 两 部 分 ， 上 半 部 分 是 获取 lBinder (BpBinder, 
BinderProxy) 的 过 程 〈 实 际 上 其 中 还 涉及 ServiceManager. java 和 
ServiceManagerNative. java。 为 了 避免 发 生 混乱 ， 我 们 是 从 
ServiceManagerProxy 开 始 讲解 的 ， 因 而 和 代码 中 的 实现 有 略微 差别 ， 
不 过 不 影响 整体 ) ， 下 半 部 分 是 getServi ce 的 执行 过 程 。 


本 小 节 结 合 Service Manager 给 大 家 详细 讲解 了 Binder Client 和 它 
获取 Binder Server 服 务 的 全 过 程 。Service Manager 作 为 Binder 
Server 有 其 “特殊 性 ” 而 正 是 借助 于 这 种 特殊 性 我 们 才能 更 简洁 明 
了 地 勾勒 出 “Binder 框 架 ”， 从 而 也 为 下 一 小 节 分 析 更 具 典 型 意义 的 
Binder Client 打 下 坚实 的 基础 。 








6.5 Binder 3 Pih 


大 家 对 “Binder” 这 个 词 可 能 会 比较 陌生 ， 不 过 提起 诸如 
bindService 这 样 的 接口 方法 ， 相 信 大 家 就 会 有 共鸣 了 一 一 顾名思义 ， 
这 个 函数 是 希望 “ 绑 定 某 项 服务 ”。 而 之 所 以 称 为 “ 绑 定 ”， 是 因为 发 
起 请 求 的 应 用 程序 和 目标 服务 程序 原本 并 没有 任何 直接 联系 ， 它 们 都 是 
独立 运行 的 个 体 。 换 句 话 说 ， 它 们 之 间 的 连接 属于 进程 间 的 通信 ， 因 而 
需要 一 种 可 以 把 两 者 “ 绑 定 ”在 一 起 的 机 制 一 一 Binder。 


本 小 节 将 从 应 用 开发 者 的 角度 来 理解 Binder 机 制 ， 特 别 是 Binder 
Client. 


大 家 先 来 做 个 发 散 练 习 ， 把 头脑 中 与 Binder 和 应 用 开发 有 关 的 记忆 
充分 挖掘 出 来 ， 然 后 把 它们 “ 串 ” 起 来 。 
1. Bindet 是 什么 

它 是 众多 进程 间 通 信 的 一 种 。 进 程 间 通 信和 是 每 个 操作 系统 都 需要 提 
供 的 ， 我 们 在 操作 系统 基础 章节 学 习 到 了 多 种 1PC; 并 且 通 过 本 章 前 面 


几 小 节 的 讲解 ， 相 信 大 家 对 Binder 的 实现 原理 也 有 了 更 深 的 认识 ， 如 图 
6-21 所 示 。 


Binder Client 


2. 应 用 程序 与 Bindet 


Binder 的 最 大 “消费 者 ”是 Java 层 的 应 用 程序 。 图 6-21 虽 然 简 单 ， 

却 概 括 了 Binder 的 实质 ， 即 它 是 进程 间 的 通信 桥梁 。 接 下 来 我 们 还 需要 
沿 着 这 条 线索 继续 挖掘 。 图 中 所 示 的 进程 1 是 一 种 泛 指 ， 那 么 一 个 进程 
需要 满足 什么 条 件 ， 或 者 说 要 做 哪些 准备 工作 才 有 资格 使 用 Binder 呢 ? 
从 应 用 开发 人 员 的 角度 来 看 ， 这 似乎 并 不 在 他 们 的 考虑 范围 ， 因 为 一 般 
情况 下 他 们 可 以 在 程序 代码 的 任何 位 置 通过 bindService， 

startActivity 以 及 sendBroadcast 等 一 系列 接口 方法 来 实现 与 其 他 进程 
的 交互 ， 如 图 6-22 所 示 。 





全 图 6-21 Bindet 是 什么 


bindServices 


startActivity, 
SendBroadcast... 


进程 ] 


全 图 6-22 从 应 用 开发 人 员 的 使 用 角度 看 Binder 





有 了 Binder Driver, Service Manager 的 努力 ， 以 及 Android 系 统 
专门 面 疝 应 用 开发 提供 的 Binder 强 有 力 的 封装 ， 才 能 使 应 用 程序 之 间 顺 
利 地 进行 无 颖 通信 。 我 们 从 四 大 组 件 中 就 可 以 看 出 一 些 端倪 。 

e Activity 
通过 startActivity 可 以 启动 目标 进程 。 


e Service 


任何 应 用 程序 都 可 以 通过 startService 或 bindService 来 启动 特定 
的 服务 ， 而 不 论 后 者 是 不 是 跨 进 程 的 。 


顺便 提 一 下 ， 这 两 种 启动 方式 的 区 别 主要 体现 在 它们 的 生命 周期 
上 ， 如 图 6-23 所 示 。 


e Broadcast 


任何 应 用 程序 都 可 以 通过 sendBroadcast 来 发 送 一 个 广播 ， 且 无 论 
广播 处 理 者 是 不 是 在 同一 个 进程 中 。 


e intent 


四 大 组 件 的 上 述 操 作 中 ， 多 数 情况 下 并 不 会 特别 指明 需要 由 哪个 目 
标 应 用 程序 来 响应 请 求 一 一 它们 会 先 通 过 一 个 被 称 为 “intent” 的 对 象 
表达 出 “意愿 ”， 然 后 由 系统 找 出 最 匹配 的 应 用 进程 来 完成 相关 工作 。 
这 样 的 设计 极 大 地 增强 了 系统 的 灵活 性 。 举 个 例子 ， 当 用 户 点 击 
了 “Browser ”按键 后 ， 他 的 “用 意 ” (intent) 是 “浏览 网 页 ”， 而 
ETERU RHEE KINS 个 “意愿 ”， WE 要 根据 系统 的 具 
体 情况 来 示 “ 候 选 者 ” 〈 比 如 用 户 同时 安装 
了 多 款 浏览 器 ) ， 那么 用 户 有 权利 来 做 最 终 的 选择 。 关于 1ntent 以 及 它 
的 最 佳 匹 配 过 程 ， 在 本 书 应 用 篇 中 有 详细 讲解 。 
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全 图 6-23 两 种 Service 的 生命 周期 


一 方面 ，Android 系 统 在 底层 Binder 机 制 的 基础 上 做 了 进一步 的 封 
效 来 满足 应 用 程序 的 研发 需求 ， 从 而 使 开发 者 不 需要 关心 太 多 Binder 的 
内 部 细节 就 可 以 实现 各 种 跨 进程 的 交互 功能 ;而 另 一 方面 ， 也 是 开发 人 
员 对 Binder 原 理 感到 陌生 的 一 大 主因 一 一 Android 做 得 如 此 完美 ， 以 至 
于 我 们 并 没有 感觉 到 进程 间 通 信和 的 “痕迹 ”。 


下 面 将 会 选取 bindService 为 例 ， 向 大 家 充分 揭示 隐藏 在 这 些 接 口 
背后 的 Binder 内 部 原理 。 


从 上 面 的 分 析 可 知 ， 应 用 程序 “进程 1” 只 需要 调用 Android 已 经 提 
供 的 一 系列 接口 方法 就 可 以 与 “进程 2” 实 现 跨 进程 交互 。 那 么 ， 在 这 
一 过 程 中 “进程 2” 的 具体 工作 是 什么 呢 ? 我 们 会 很 自然 地 想到 ， 在 
TCP/ZIP 通 信 中 ， 当 客户 端 发 起 连接 请 求 时 ， 服 务 器 端 必 定 是 处 于 监听 状 
态 。 这 种 C6/S 模 型 的 交互 方式 在 前 几 节 分 析 Binder Client 和 Binder 
Server 时 已 经 被 证 实 ， 如 Service Manager 就 是 在 一 个 不 断 读 取 消息 的 
循环 中 处 理 客户 端的 请 求 的 。 


值得 一 提 的 是 ， 从 Android 应 用 程序 的 角度 来 看 ，Service 组 件 并 不 
等 同 于 Binder Server。 换 句 话说 ， 它 并 不 是 一 定 要 处 于 运行 状态 才能 
接收 请 求 。Servi ce 组 件 的 生命 周期 起 始 于 startService 或 者 
bindService。 而 不 管 是 哪 一 种 启动 方式 ， 都 是 在 客户 端 发 出 连接 请 求 
后 才 执 行 的 ， 可 见 Service 组 件 本 身 不 存在 “持续 监听 ”的 状态 。 


前 一 个 小 节 给 出 了 Binder 的 主体 框架 图 ， 这 里 再 从 应 用 程序 的 角度 
对 它 进 行 完善 ， 如 图 6-24 所 示 。 


由 图 可 知 ， 整 个 框架 被 一 分 为 二 ， 分 别 代表 了 Binder 机 制 中 对 应 用 
程序 可 见 和 隐藏 的 两 部 分 。 


。 可 见 部 分 


Android 系 统 提供 给 应 用 程序 的 接口 ， 组 成 了 可 见 部 分 ， 包 括 
bindService、startActivity 等 。 
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全 图 6-24 从 应 用 开发 角度 看 Binder 主 体 框架 
© 隐藏 部 分 


应 用 程序 只 需要 通过 上 述 可 见 接口 便 可 以 方便 地 完成 1 PC 通信 ， 但 
可 以 肯定 的 是 隐藏 在 其 后 庞大 的 Binder 通 信 原 理 还 是 没有 变 。 


为 了 让 大 家 可 以 更 清楚 地 看 到 整个 “隐藏 部 分 ”的 内 部 实现 ， 接 下 


来 选取 一 个 范例 进行 剖析 。 如 图 6-25 所 示 ，Application1 中 的 某 个 
Activity 通 过 bindService (intent) 来 试图 启动 符合 intent 描 述 的 
Service 服 务 一 一 最 终 App1ication2 中 的 Service 将 被 运行 。 


bindService | Application? 
(Service) 


Application! 





A 6-25  bindService fj 8 


应 用 程序 如 何 能 依托 bindService 来 启动 系统 中 其 他 进程 提供 的 
Service 呢 ? 别 急 ， 读 者 可 以 先 来 “应 丁 解 牛 ”一 一 必定 需要 以 下 几 个 
步骤 才能 完成 这 一 操作 目标 。 


e Step1. 应 用 程序 填写 Intent， 调 用 bindService 发 出 请 求 。 

。 Step2. 收 到 请 求 的 bindService (此 时 还 在 应 用 程序 的 运行 空间 中 ) 将 
与 Activity ManagerService(AMS) 取 得 联系 。 根 据 前 面 几 个 小 节 的 分 
析 ， 为 了 获得 AMS 的 Binder 句 柄 值 ， 我 们 还 要 事先 调用 
ServiceManager.getService， 这 里 就 已 经 涉及 进程 间 通 信 了 。 在 得 到 
AMS 的 句柄 值 后 ， 程 序 才能 真正 地 向 它 发 起 请 求 ( 关 于 
ActivityManagerService 服 务 的 详细 讲解 ， 可 以 参见 本 书后 续 章节 ) o 
Step3. AMS 基 于 特定 的 “最 优 匹配 策略 ”， 从 其 内 部 存储 的 系统 所 
有 服务 组 件 的 资料 中 找到 与 Intent 最 匹配 的 一 个 ， 然 后 向 它 发 送 
Service 绑 定 请 求 〈 这 一 步 也 是 进程 间 通 信 ) JER, WARE Ht 
程 还 不 存在 的 话 ，AMS 还 要 负责 把 它 启 动 起 来 。 这 部 分 知识 在 前 面 
章节 “应 用 程序 的 典型 启动 流程 ”中 已 分 析 过 。 
Step4. “被 绑 定 ”的 服务 进程 需要 响应 绑 定 ， 执 行 具 体操 作 ， 并 在 
成 功 完 成 后 通知 AMS; 然后 由 后 者 再 回调 发 起 请 求 的 应 用 程序 (E 


调 接口 是 ServiceConnection) o 























由 此 可 见 ， 一 个 看 似 简 单 的 bindService 原 来 内 部 “大 有 乾坤 ”。 
但 是 为 什么 Application1 在 Activity 中 只 需要 调用 bindService 即 可 ， 
而 丝毫 不 见 上 述 的 烦琐 过 程 呢 ? 


我 们 知道 ， 基 于 Activity 应 用 程序 的 继承 关系 如 图 6-26 所 示 。 


Context 


Context Wrapper 
Context heme Wrapper 


全 图 6-26 Activity 的 继承 关系 简 图 


由 此 可 知 ，Activity 继 承 关 系 的 “ 根 ” 是 Context。 从 字面 意思 来 
理解 ，Context 是 “上 下 文 环境 ”。 运 用 到 应 用 程序 的 场景 中 ， 就 是 指 
和 一 个 Applicat ion 环 境 相 关 的 全 局 性 信息 。 比 如 startActivity、 
startService、sendBroadcast 、getResources 等 ， 都 是 每 一 个 应 用 程 
序 与 生 俱 来 的 能 好 比 每 一 个 人 生来 就 会 呼吸 、 一 个 鼻子 两 个 眼睛 
一 样 ， 是 它 的 固有 属性 和 功能 。 关 于 Context 此 处 不 再 做 过 多 泻 染 ， 有 
兴趣 的 读者 看 下 代码 就 很 清楚 了 ， 这 里 把 它 理解 为 应 用 程序 的 “全 局 而 
天 生 的 能 力 ” 就 行 了 。 


所 以 bindService 自 然 也 是 包含 在 Context 里 面 的 。 具 体 而 言 ， 
Context 只 是 提供 了 抽象 的 接口 ， 功 能 则 是 在 ContextWrapper 中 实现 
的 : 


/*frameworks/base/core/java/android/content/Contextwrapper. java*/ 
public boolean bindService(Intent service, ServiceConnection 
return mBase.bindService(service, conn, flags); //mBase 是 1 
} 


这 个 类 取 名 为 ContextWrapper 是 有 一 定 道理 的 ， 因 为 它 并 不 是 
Context 环 境 实现 的 主体 ， 更 多 的 只 是 为 mnBase 做 了 个 转向 功能 。 


上 述 变量 mBase 也 是 一 个 Context 对 象 ， 最 新 版 本 中 是 由 
Context1mp1 来 实现 的 (bindService 直 接 调用 bi ndServiceAsUser : 





/*frameworks/base/core/java/android/app/ContextImpl. java*/ 
public boolean bindServiceAsUser(Intent service, ServiceConnec 
UserHandle user) {... 
int res = ActivityManagerNative.getDefault().bindService( 
mMainThread.getApplicationThread(), getActivityTok 
service, service.resolveTypeIfNeeded(getContentRes 
sd, flags, userId); /*ActivityManager 出 现 了 ， 证 明了 我 





} 
那么 ， 应 用 程序 又 是 如 何 找到 AMS 并 与 之 建立 联系 的 呢 ? 


和 ServiceManager 一 样 ，AMS 也 同样 提供 了 ActivityManagerNative 
和 ActivityManagerProxy， 上 有 具体 如 下 : 


/*frameworks/base/core/java/android/app/ActivityManagerNativ 
static public IActivityManager getDefault() { 

return gDefault.get(); /* 得 到 默认 的 IActivityManager 对 象 */ 
} 


这 个 gDefault. get () 得 到 的 是 什么 ? 





/*frameworks/base/core/java/android/app/ActivityManagerNativ 
private static final Singleton<IActivityManager> gDefault =n 
Manager>() { 

/x*Singleton， 即 “ 单 实例 “是 一 种 常见 的 设计 模式 ， 它 保证 某 个 对 象 只 会 被 创建 一 
当 调 用 gDefault .get( ) 时 ,会 先进 行内 部 判断 :如 果 该 对 象 已 经 存在 ， 就 直接 i 
需要 通过 内 部 create( ) 新 建 一 个 对 象 实例 */ 

protected IActivityManager create() { 
IBinder b = ServiceManager .getService("activity");/* 通 过 Se 
取得 ActivityManagerService 的 IBinde 


























IActivityManager am = asInterface(b); /* 创 建 一 个 可 用 的 Activ: 


return am, 
} 
}; 


看 出 什么 了 吗 ? ActivityManagerNative 的 作用 之 一 ， 就 是 帮助 调 
用 者 方便 快速 地 取得 一 个 ActivityManagerProxy。 这 和 
ServiceManagerProxy 及 ServiceManagerNative 的 作用 基本 一 致 ， 
过 在 细节 上 有 略微 差异 。 


在 gDefault 这 个 单 实例 中 ， 获 取 一 个 有 效 的 1ActivityManager 对 象 
e 得 到 IBinder (BpBinder) ; 
。 将 IBindet 转 化 为 Iinterface (在 这 个 场景 中 ， 是 IactivityManagef) 。 
因为 ServiceManager 提 供 了 一 系列 静态 方法 ， 使 得 第 一 个 步骤 显得 
很 简洁 。 


顺便 说 一 下 ，ActivityManagerNative 的 另 一 个 作用 是 为 
ActivityManagerService 的 实现 提供 便利 。 如 果 仔细 观察 ， 就 会 发 现 
ActivityManagerNative 里 有 如 下 方法 : 


public boolean onTransact(int code, Parcel data, Parcel reply, in 


Switch (code) { 
case START_ACTIVITY_TRANSACTION: 


{ 
int result = startActivity(app, intent, resolvedType, 
grantedUriPermissions, grantedMode, resultTo, 
requestCode, onlyIfNeeded, debug, profileFile 
profileFd, autoStopPro filer); 
} 


这 样 在 AMS 里 只 要 继承 自 ActivityManagerNative， 就 已 经 将 用 户 的 
pe ce ee en 是 不 是 很 方便 ? 源 代 码 
Al: 


/*frameworks/base/services/java/com/android/server/am/ActivityMan 
public final class ActivityManagerService extends ActivityManager 
Activit 

implements Watchdog.Monitor, BatteryStatsImpl.BatteryCall 


因而 可 以 这 么 说 ，ActivityManagerNative 〈 其 他 服务 的 Native 也 
是 一 样 的 ) 既是 面向 调用 者 的 ， 也 是 面向 服务 实现 本 身 的 ， 只 不 过 这 个 
Native 的 名 称 取得 容易 产生 卜 义 。 


经 过 上 面 代码 的 分 析 ，Application1 和 Application2 的 进程 间 通 信 
还 应 该 再 加 上 ServiceManager 和 ActivityManagerService 的 支持 ， 如 图 
6-27 所 示 。 


Application! Application? 





A 6-27 Service Managet 对 进程 间 通 信 的 支持 


记 住 ， 不 管 形式 怎么 变 ， 整 个 PC 通信 都 是 基于 Binder 驱 动 来 开展 
的 。 因 而 建议 读者 在 思考 问题 时 最 好 以 Binder 驱 动 为 中 心 ， 以 看 得 
更 “透彻 ”。 


当 应 用 程序 需要 通过 ServiceManager 来 查询 革 个 Binder Server 
时 ， 调 用 的 是 getService 方 法。 相关 知识 在 前 面 小 节 已 经 详细 分 析 过 ， 
这 里 再 大 概 复习 几 个 关键 点 。 直 接 面 向 应 用 程序 的 是 Service 
Manager. java， 它 提供 了 多 个 static 接 口供 调用 者 获取 ServiceManager 
提供 的 服务 ， 如 Service Manager. getService。 这 些 静 态 另 数 内 部 通过 
get1ServiceManager 来 得 到 ServiceManagerProxy 对 象 一 一 后 者 作为 SM 
的 本 地 代理 ， 将 利用 1Binder 来 “穿越 ”JN1 层 调用 到 对 应 的 BpBinder， 
进而 使 用 ProcessState 和 1PCThreadState 的 相关 接口 ， 最 终 经 由 Binder 
驱动 完成 与 ServiceManager 的 通信 。 


先 总 结 一 下 到 目前 为 止 的 函数 调用 过 程 ， 如 图 6-28 所 示 。 


从 图 6-28 中 可 以 看 到 ，“ 万 里 长 征 ” 还 只 是 走 了 前 两 步 〈Step1 和 
Step2) ， 即 Application1 已 经 可 以 访问 到 AMS， 并 向 后 者 请 求 
bindService 了 。 接 下 来 AMS 要 针对 bindService 中 指定 的 1ntent 进 行 一 
系列 匹配 工作 ， 然 后 确定 需要 启动 的 Service 及 它 所 属 的 进程 。 这 部 分 
内 容 与 AMS 的 工作 原理 有 很 大 关系 ， 我 们 将 在 后 续 章节 进行 统一 解答 。 
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全 图 6-28  bindService 调用 流程 


本 小 节 以 一 个 简单 的 接口 函数 bindServi ce 为 切入 点 ， 回 大 家 展示 
了 隐藏 在 应 用 程序 背后 的 Binder 机 制 。 从 中 可 以 看 出 ，Goog le 为 了 简化 
应 用 开发 人 员 的 工作 可 谓 用 心 良 苦 一 一 不 过 由 此 带 来 的 一 个 负面 影响 就 
是 ， 整 个 Binder 的 “上 层 建 筑 ” 显 得 非常 烦琐 。 和 希望 读者 在 学 习 这 部 分 
知识 时 ， 能 够 始终 掌握 “Binder 驱 动 ”这 一 核心 ， 并 在 此 基础 上 层 层 递 
进来 逐步 理解 Android 所 做 的 封装 ， 相 信和 就 能 跳出 元 长 的 代码 “ 陷 
H” To 


6.6 Android 接 口 描 述 语 言 一 一 A1DL 


AIDL 是 Android Interface Description Language 的 简写 。 从 名 称 
上 看 它 是 一 种 语言 ， 而 且 是 专门 用 于 描述 接口 的 语言 。 准确 地 说 ， 它 是 
用 于 定义 客户 端 /服务 端 遂 信 接口 的 一 种 描述 语言 。 这 么 说 大 家 可 能 觉 
得 比较 抽象 ， 接 下 来 我 们 尝试 从 另 一 个 角度 来 理解 。 

如 前 面 小 节 反 复 强 调 的 ，Service Manager 本 身 也 是 一 个 Binder 


Server， 为 Binder Client 提 供 了 一 系列 服务 接口 。 仪 从 Service 
Manager 的 实现 来 看 ， 构 建 一 个 Binder Server 所 需 的 工作 如 下 。 


1. 启动 的 时 机 


比如 SM 是 开机 的 时 候 通 过 init. rc 文件 启动 的 ， 这 就 保证 了 它 是 系 
统 中 第 一 个 注册 成 “服务 大 管家 ”的 Service。 


2. 提供 一 致 的 服务 接口 


显然 ， 一 个 Binder Server 应 该 向 公众 暴露 它 所 能 提供 的 服务 ; 而 
且 客 户 端 使 用 的 服务 接口 和 服务 端 实 现 的 服务 接口 必须 是 完全 一 致 的 。 


SM 中 的 服务 接口 是 1ServiceManager 。 客 户 端 本 地 进程 中 的 
ServiceManagerProxy 及 ServiceManagerNative 都 继承 自 这 个 接口 。 而 
它 的 服务 端 是 直接 用 C 语 言 实现 的 (Service_manager.c) ， 所 以 不 存在 
继承 的 说 法 。 不 过 通过 分 析 其 内 部 binder_parse 函 数 可 知 ， 它 还 是 保持 
了 与 客户 端 接口 的 一 致 。 


3. 与 Bindet 驱 动 的 交互 方式 

一 个 Binder Server 需 要 与 Binder Driver 做 哪些 交互 呢 ? 除去 一 系 
列 必要 的 初始 化 以 外 (open，mmap 等 ) ， 就 是 要 通过 个 断 地 ioct1 来 循 
环 读 写 数 据 。 比 如 SM 就 是 通过 binder_1oop 也 数 中 的 一 个 for 死 循环 来 完 
成 这 一 工作 的 。 
4. 外 界 如 何 能 访问 到 这 个 Server 的 服务 


一 个 Server 最 终 的 价值 在 于 向 Client 提 供 服 务 ， 所 以 自然 会 有 一 个 


问题 ， 即 Client 如 何 去 访问 一 个 Server? 回想 一 下 前 几 个 小 节 讲 过 的 关 
于 Binder Server 的 知识 ， 至 少 有 两 种 方法 是 可 行 的 。 


方法 1: Server 在 ServiceManager 中 注册 。 


这 种 方法 普遍 存在 于 Android 系 统 服务 中 ， 如 
ActivityManagerService、WindowManagerService 等 都 在 
ServiceManager 中 做 了 注册 。 调 用 者 只 要 通过 
ServiceManager. getService (SERVICE NAME) 就 可 以 获取 到 Binder 
Server 的 本 地 代理 ， 然 后 与 之 通信 。 


方法 2: 通过 其 他 Server 作 为 中 介 。 


这 是 一 种 “匿名 ” 的 方法 。 换 句 话说 ， 这 种 类 型 的 Binder Server 
不 需要 在 ServiceManager 中 注册 。 那 么 ， 客 户 端 如 何 访问 它 呢 ? 


没 错 ， 就 是 通过 一 个 “第 三 方 ” 的 “实名 ”Server 因为 是 实名 
的 ， 调 用 者 可 以 通过 ServiceManager 来 首先 访问 到 它 ， 然 后 由 它 提 供 的 
接口 获取 “匿名 ”者 的 Binder 句 柄 。 举 个 互联 网 中 的 例子 ， 我 们 访问 某 
服务 器 A 通 常 要 先 由 DNS 做 域名 解析 ， 获 取 到 1P 地 址 后 才能 访问 网 站 。 但 
这 不 是 唯一 可 行 的 方法 。 假 设 服务 器 B 已 经 在 DNS 中 注册 ， 并 且 通 过 服务 
器 B 可 以 得 到 A 的 1P 地 址 ， 那 么 理论 上 客户 端 就 可 以 这 么 做 : 


通过 DNS 获得 服务 器 B 的 1P 地 址 访问 服务 器 B 一 向 服务 器 B 查 询 A 的 
IP 地 址 一 访问 服务 器 A 
在 这 种 情况 下 ， 实 际 上 服务 器 B 就 扮演 了 DNS 的 角色 。 


我 们 把 这 种 实现 方式 称 为 “匿名 ”Binder Server. EEAndroidA 
统 中 也 比较 常见 ， 如 后 面 章节 中 将 会 讲解 的 WindowSession 就 属于 这 一 


o 





以 上 几 点 就 是 一 个 Binder Server 构 建 所 需要 做 的 核心 内 容 。 我 们 
在 Service Manager 的 学 习 中 会 发 现 ， 它 基本 上 是 靠 开 发 人 员 一 行 行 手 
工 编写 出 来 的 。 那 么 ， 有 没有 其 他 更 简捷 的 方式 来 实现 一 个 Binder 


Server iE? 


答案 就 是 A1DL。 


当然 ， 不 管 是 手工 还 是 自动 ， 所 要 做 的 核心 内 容 并 没有 太 大 变化 ; 
只 是 自动 化 可 以 帮助 开发 人 员 更 快速 地 组 建 出 Binder Server。 本 小 节 
内 容 将 通过 一 个 范例 来 分 析 采 用 AI1DL 究 竟 可 以 为 Binder Server BRKE 
些 便利 以 及 它 的 内 部 实现 原理 。 


这 个 范例 是 本 书 显示 系统 章节 中 将 会 重点 讨论 的 
WindowManagerService。 


(1) 先 来 看 看 启动 时 机 的 问题 。 和 其 他 系统 服务 一 样 ，WMS 是 在 
SystemServer 中 启动 的 ， 具 体 过 程 可 以 参见 WMS 章节 ， 这 里 暂且 跳 过 。 


(2) 再 来 看 看 A1DL 是 如 何 保证 接口 的 一 致 性 的 。 使 用 AI1DL 首 先 要 
书写 一 个 *. aidl 文 件 来 描述 这 个 Server。 上 比如: 


/*IWindowManager.aid1l*/ 
interface IWindowManager 


IWindowSession openSession(in IInputMethodClient client,in IInput 
} 

为 了 让 大 家 看 得 更 清楚 些 ， 上 述 代码 段 只 保留 了 openSession 一 个 
OAK, HARADA AS SWi ndowManagerServicem TH iHid 

AIDL 的 语法 细节 这 里 就 不 详细 讲解 了 。 这 个 IWindowManager. aid| 
文件 经 过 工具 转化 后 ， 成 为 以 下 内 容 : 


/*IWindowManager . java*/ 
public interface IWindowManager extends android.os.IInterface 


public static abstract class Stub extends android.os.Binder //Stu 
implements android.view. IWindowManager 


public static android.view.IWindowManager asInterface(android.os. 


@Override public android.os.IBinder asBinder() 
return this; 


@Override public boolean onTransact(int code, android.os.Parcel d 
android.os.Parcel reply, int flags) throws android.os.RemoteExcep 


switch (code) 


{ 
case TRANSACTION_openSession: 


J. 

} 

return super.onTransact(code, data, reply, flags); 

} 

private static class Proxy implements android.view. IwindowManager 
//Proxy 就 是 “代理 ”， 我 们 已 经 多 次 讲解 














private android.os.IBinder mRemote; 

@override public android.os.IBinder asBinder( ) 
return mRemote; 

@Override public android.view. IWindowSession 


openSession(com.android.internal.view.IInputMethodClient client, 
com.android.internal.view.IInputContext inputContext) throws and 


{ 





} 
} //Proxy 结 束 
}//Stub 结 束 





static final int TRANSACTION_openSession =(android.os.IBinder.FIR 
/* 自 动 分 配 业 务 码 ， 大 家 可 以 和 ServiceManager 中 的 手工 分 配 做 下 对 比 */ 
}//IWindowManager 结 束 


这 个 文件 很 长 ， 而 且 因 为 通过 A1DL 工 具 自 动 生 成 的 内 容 没 有 格式 ， 
看 起 来 比较 吃力 。 我 们 尽 可 能 省 略 掉 无 关 部 分 ， 并 将 重要 的 3 个 类 高 亮 
显示 ， 即 1windowManager IWindowManager. Stub 和 
IWindowManager. Stub. Proxy. MMASRERER, FAKE 
|WindowManager 。 





e IWindowManager 


一 般 以 大 写字 母 1 开 头 的 表示 一 个 Interface。 在 AI1DL 中 ， 所 有 的 服 
务 接口 都 继承 于 1interface， 然 后 在 此 基础 上 声明 与 此 Server 上 服务 相关 
的 方法 。 比 如 IWindowManager 中 除了 两 个 能 套 类 外 ， 其 末尾 还 包含 了 它 
提供 的 服务 openSession、getRealDisplaySize、hasSystemNavBar 等 接 


口 的 原型 。 


e [WindowManager.Stub 


还 记得 ServiceManagerNative 吗 ? Stub 的 作用 和 它 类 似 。 它 包含 了 
—TEBA (Stub. Proxy) ， 以 及 各 种 常用 的 接口 方法 如 
aslnterface，asBinder 等 ) ， 其 中 最 重要 的 一 个 就 是 onTransact。 我 
们 知道 ServiceManagerNative 是 同时 面向 服务 器 和 客户 端的 ，Stub 也 同 
样 如 此 。 在 实际 使 用 中 ， 一 个 Binder Server 的 实现 类 通常 继承 自 
Stub。 而 Stub 又 继承 自 Binder 并 实现 了 该 Server 的 1XX 接 口 ， 如 
I1WindowManager 的 实现 类 WindowManagerService: 


public class WindowManagerService extends IWindowManager .Stub 
至 于 为 什么 要 继承 自 Binder 类 ， 后 面 会 有 详细 分 析 。 
e [WindowManager.Stub.Proxy 
Proxy 即 代理 ， 功 能 和 ServiceManager Proxy 类似。 因而 这 个 类 是 
面向 Binder Client 的 ， 它 可 以 让 调用 者 轻松 地 构造 出 Binder Server 
本 地 代理 对 象 。 


具体 如 图 6-29 所 示 。 











IWindowManager. Stub 
/\ 
WindowManagerService 


全 图 6-29 基于 AIDL 的 Binder Server 
这 样 通过 AI1DL 就 为 WMS 这 个 Binder Server 生 成 了 统一 的 服务 接口 。 


(3) 接 下 来 看 第 三 个 问题 ， 即 基于 A1DL 的 Binder Server 如 何 与 
Binder 驱 动 进行 交互 。 在 Service Manager 的 实现 中 ， 它 通过 死 循 环 不 
停 地 执行 ioct 1 来 获取 用 户 的 请 求 。 而 一 个 Client 在 获取 Service 
Manager 的 服务 时 ， 则 是 通过 ProcessState 和 1PCThreadState 来 处 理 各 
种 细节 。 那 么 ，WindowManagerService 这 个 使 用 AI1DL 的 Server 又 是 如 何 
实现 的 呢 ? 


如 果 读 者 只 是 单纯 地 阅读 WMS 的 源码 ， 可 能 很 难 发 现 谜底 所 在 ， 所 
以 需要 换 一 种 思路 。 我 们 在 系统 的 启动 过 程 章 节 讲 解 过 系统 服务 〈 比 如 
WindowManagerService, PowerManagerService, 

Locat ionManagerService=) 相关 的 知识 这 些 服务 统一 都 在 
java 中 局 动 。 而 在 这 之 前 ， 即 System_init. cpp 中 其 实 还 
隐藏 着 这 么 一 段 代 码 : 


/*frameworks/base/cmds/system_server/library/System_init.cpp*/ 
extern "C" status_t system_init() 





{ 
ALOGI ("System server: entering thread pool.\n"); 
ProcessState::self()->startThreadPool(); 
IPCThreadState::self()->joinThreadPool(); 

上 


通过 这 两 句 代码 ， 整 个 系统 服务 进程 就 进入 类 似 于 Service 
Manager 中 的 binder loop 循环 了 。 因 为 后 续 在 SystemServer 中 局 动 的 所 
有 系统 服务 都 运行 于 同一 个 进程 中 ， 所 以 它们 惑 没有 必要 再 单独 与 
Binder 驱 动 进行 交互 。 下 面具 体 看 看 这 两 句 代 码 都 做 了 些 什么 : 


/*frameworks/native/libs/binder/ProcessState.cpp*/ 
void ProcessState::startThreadPool() 
{ 
AutoMutex _1(mLock); 
if (!mThreadPoolStarted) { 
mThreadPoolStarted = true;// 表 明 已 经 启动 了 线程 池 了 ， 避 免 重复 操 人 
spawnPooledThread(true);// 产 生 一 个 线程 池 ， 注 意 传 参 为 true 





其 中 mThreadPoolStarted 用 来 标识 ThreadPoo| 是 否 已 经 开户 。 上 述 
代码 段 的 重点 还 不 在 spawnPooledThread 中 : 


void ProcessState: :spawnPooledThread(bool isMain)// 这 里 的 参数 为 true 


if (mThreadPoolStarted) { 
String8 name = makeBinderThreadName( );/* 为 线程 池 取 名 */ 
ALOGV("Spawning new pooled thread, name=%s\n", name.strin 
sp<Thread> t = new PoolThread(isMain);/* 生 成 线程 池 对 象 */ 
t->run(name.string());// 运 行 


这 个 函数 的 逻辑 很 简单 ， 首 先 为 Poo1Thread 取 一 个 名 字 ， 然 后 新 建 
PoolThread 对 象 ， 最 后 执行 :un 函数 《从 中 也 可 以 看 出 ， 线 程 池 必 定 是 
一 个 Thread 子 类 ) 


/*frameworks/native/libs/utils/Threads.cpp*/ 
status_t Thread::run(const char* name, int32_t priority, size_t s 


if (mCanCallJava) { 

res = createThreadEtc(_threadLoop, this, name, priority, s 
} else { 

res = androidCreateRawThreadEtc(_threadLoop, this, name, p 


} 
int Thread::_threadLoop(void* user) 
{ 
result = self->threadLoop() 


本 地 层 的 Thread 和 Java 层 的 实现 还 是 有 所 区 别 的 ， 如 上 面 代码 段 所 
mo Erun Bae 2879 AY Poo! ThreadfthreadLoop: 


class PoolThread : public Thread 


protected: 
virtual bool threadLoop() 


IPCThreadState: :self()->joinThreadPool(mIsMain);// 注 意 这 个 i 
return false; 


const bool mIsMain; 


}; 
可 以 看 到 ， 在 threadLoop 中 也 调用 了 一 次 joinThreadPoo1， 而 且 


mlsMain 为 true。 


这 样 就 进入 joinThreadPool 了 。 它 的 功能 类 似 于 Service Manager 
中 binder. c 的 binder loop: 


void IPCThreadState: :joinThreadPool(bool isMain) 


{ 
mOut.writeInt32(isMain ? BC_ENTER_LOOPER : BC_REGISTER_LOOPER 


status_t result; 
do {// 这 就 是 Binder Server 处 理 消 息 的 主 循环 了 
int32_t cmd; 














result = talkwithDriver();// 这 个 函数 前 面 小 节 中 已经 分 析 过 了 
if (result >= NO_ERROR) { 

size_t IN = mIn,dataAvail();// 有 没有 可 读数 据 ? 

if (IN < sizeof(int32_t)) continue; 

cmd = mIn.readInt32();// 读 取 一 个 cmd 








result = executeCommand (cmd);// 执 行 cmd 


} 


if(result == TIMED_OUT && !isMain) {// 超 时 ， 而 且 不 是 主要 的 Bi 
break; 





} 
} while (result != -ECONNREFUSED && result != -EBADF); 


mOut .writeInt32(BC_EXIT_LOOPER);// 告 知 Binder 了 驱动 退出 循环 
talkwithDriver(false); 


上 面 的 while 主 循环 不 断 地 talkWithDriver 然 后 executeCommand， 
这 和 binder_loop 的 主体 框架 基本 是 一 致 的 也 就 解决 了 Binder 
Server 如 何 与 Binder 驱 动 通信 的 问题 。 


(4) 最 后 还 有 一 个 疑问 是 我 们 必须 要 搞 清 楚 的 ， 即 当 一 个 进程 中 
有 多 个 Binder Server 存 在 时 ， 基 于 A1DL 的 实现 是 如 何 正 确 区 分 它们 的 
(因为 ProcessState 是 单 实例 ) ? 


在 ServiceManager 中 ， 这 并 不 是 问题 。 因 为 整个 SM 进程 就 一 个 





Server， 只 要 Binder 了 驱动 有 数据 要 处 理 ， 当 然 非 它 莫 属 〈 直 接 调用 
binder_parse 进 行 处 理 即 可 ) 。 而 当 一 个 进程 中 存在 多 个 Binder 
Server 〈 比 如 SystemServer 就 是 这 种 情况 ， 其 所 在 进程 中 有 
WindowManagerService，ActivityManagerService 等 一 系列 系统 服务 ) 
时 ，1PCThreadState 是 如 何 把 Binder 驱动 的 消息 准确 投递 给 对 应 的 
Server 的 ? 


有 的 读者 可 能 会 想 ， 让 1PCThreadState 记 录 下 进程 中 的 所 有 Binder 
Server 即 可 。 理 论 上 的 确 可 行 ， 不 过 显然 会 使 程序 的 逻辑 变 得 复杂 一 一 
因为 我 们 想 要 做 的 是 品 上 层 隐藏 一 切 与 Binder 底 层 相 关 的 操作 ， 做 
到 “无 颖 ”连接 。 


来 看 看 executeCommand 是 怎么 做 到 的 : 


status_t IPCThreadState: :executeCommand(int32_t cmd) 
{ 
BBinder* obj; 
RefBase: :weakref_type* refs; 
status_t result = NO_ERROR; 
switch (cmd) 4... 
case BR_TRANSACTION: 
{ 
binder_transaction_data tr; 
result = mIn.read(&tr, sizeof(tr));/*i HOLS i R*/ 





Parcel buffer; 

buffer .ipcSetDataReference(einterpret_cast<const uint8_t* 

tr.data_size, 

reinterpret_cast<const size_t*>(tr.data.ptr.offsets), 
tr.offsets_size/sizeof(size_t),freeBuffer, th 


Parcel reply; 


if (tr.target.ptr) {/* 如 果 target 中 指定 了 目标 对 象 */ 
sp<BBinder> b( (BBinder*)tr.cookie);/* 强 制 类 型 转换 为 BBint 
const status_t error = b->transact(tr.code, buffer, & 
if (error < NO_ERROR) reply.setError(error); 
} else { 
const status_t error = the_context_object->transac 
tr.flags); 
if (error < NO_ERROR) reply.setError(error); 





} 


break; 
} 


return result; 


在 对 BR_TRANSACTION 的 处 理 中 ， 首 先 整理 出 请 求 数据 ， 然 后 分 成 两 
种 情况 


e tr.target.ptr# X null 


将 tr. cookie 强 制 转换 成 一 个 BBinder ， 最 后 调用 BBinder- 
>transact 来 处 理 请 求 。 


e tr.target.ptr X null 
此 时 使 用 默认 的 the_context_ob ject 来 处 理 请 求 。 


通常 情况 下 程序 走 的 是 上 面 的 分 支 ， 看 来 这 个 BBinder 就 是 Server 
和 1PCThreadState 沟 通 的 桥梁 。 那 么 ，BBinder 又 是 什么 时 候 生成 的 
呢 ? 而 且 为 什么 Client 发 起 的 请 求 中 会 知道 这 个 信息 ? 


细心 的 读者 在 刚才 1WindowManager. java 中 应 该 已 经 发 现 了 ，Stub 
是 继承 于 Binder 的 。 即 : 


public static abstract class Stub extends android.os.<strong>Bind 


因为 Stub 类 在 构造 时 只 是 简单 地 调用 attachlnterface 来 设置 了 
owner 和 和 descr iptor ， 我 们 直接 来 看 看 Binder 的 构造 : 


/*frameworks/base/core/java/android/os/Binder .java*/ 
public Binder() { 
init(); 


这 个 init 是 一 个 native 国 数 ， 具 体 实 现 如 下 : 


/*frameworks/base/core/jni/android_util_Binder.cpp*/ 
static void android_os_Binder_init(JNIEnv* env, jobject obj) 


{ 


JavaBBinderHolder* jbh = new JavaBBinderHolder(); 


jbh->incStrong((void* )android_os_Binder_init); 
env->SetIntField(obj, gBinderOffsets.mObject, (int)jbh); 


上 述 代 码 段 首先 生成 一 个 JavaBBinderHolder 对 象 ， 从 名 称 上 看 它 
是 BBinder 的 载体 ， 内 部 持 有 一 个 JavaBBinder 的 弱 引 用 ， 而 后 者 又 继承 
自 BBinder。 男 外 ， 它 提供 了 一 个 get 方 法 用 于 获取 内 部 的 这 个 
JavaBBinder 的 强 引 用 〈 通 过 promote 转 换 ) ， 后 面 还 会 磁 到 这 个 方法 的 
使 用 场景 。 值 得 注意 的 是 ， 这 里 新 建 的 JavaBBinderHolder 对 象 并 没 
立刻 生成 JavaBBinder， 而 是 要 等 到 有 人 调用 时 它 才 会 真正 创建 出 来 。 


接着 init 函 数 增 加 了 强 引 用 计数 ， 并 通过 JN1 把 这 个 
JavaBBinderHolder 的 指针 值 保 存 到 Binder 的 m0b ject 内 部 变量 中 ， 以 便 
后 续 使 用 。 这 样 我 们 就 很 清楚 了 ， 当 一 个 基于 A1DL 的 Server 创 建 时 ， 它 
就 已 经 “有 预谋 ”地 要 生成 BBinder 了 。 这 个 “预谋 ”等 到 有 人 真正 使 
用 它 来 进行 跨 进 程 传递 时 ， 才 会 实施 。 比如 在 创建 Ws 的 同时 会 把 它 
注册 到 Service Manager: 


/*frameworks/base/services/java/com/android/server/SystemSer 

Slog.i(TAG, "Window Manager"); 

wm = WindowManagerService.main(context, power, display, inpu 
uiHandler, wmHandler,factoryTest != SystemServer. 
!firstBoot, onlyCore); 

ServiceManager .addService(Context.WINDOW_SERVICE, wm); 


关于 ServiceManager 前 面 小 节 已 经 详细 分 析 过 ， 这 里 看 下 
addService 的 核心 内 容 〈 注 意 ，ServiceManager 并 不 是 和 
WindowManagerService 一 样 运 行 在 系统 服务 进程 中 ， 而 是 通过 init. re 
启动 〉: 


public void addService(String name, IBinder service, boolean allo 
Parcel data = Parcel.obtain(); 


data.writeStrongBinder (service) ;//*3 A—‘*StrongBinder 
} 


上 面 的 语句 中 使 用 了 writeStrongBinder 将 service (在 这 个 场景 
中 ， 也 就 是 WindowManager Service 自 身 ) 写 入 Parcel 中 : 


/*frameworks/base/core/jni/android_os_Parcel.cpp*/ 
static void android_os_Parcel_writeStrongBinder(JNIEnv* env, jcla 


{ 


Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr); 
if (parcel != NULL) { 
const status_t err = parcel->writeStrongBinder (ibinderFor 


我 们 直接 从 JN1 的 实现 看 起 。 当 生成 一 个 Parcel (java) TRA, = 
在 构造 函数 中 通过 nat iveCreate 同 时 生成 一 个 native 层 的 Parce1 对 象 ， 
并 将 它 的 内 存 地 址 保存 到 Parcel (java) 中 ， 即 上 面 代码 中 的 
nativePtr。 另 外 函数 入 参 里 的 object 是 一 个 1Binder (java) WR, BB 
通过 ibinderForJava0b ject 进 行 转化 。 如 下 所 示 : 


/*frameworks/base/core/jni/android_util_Binder.cpp*/ 
sp<IBinder> ibinderForJavaObject(JNIEnv* env, jobject obj) 
{ 
if (obj == NULL) return NULL; 
if (env->IsInstanceOf(obj, gBinderOffsets.mClass)) { 
JavaBBinderHolder* jbh = (JavaBBinderHolder* )env->GetIntF 
mObject); 
return jbh != NULL ? jbh->get(env, obj) : NULL; 
} 


return NULL; 


这 个 函数 中 出 现 了 我 们 前 面 看 到 的 JavaBBinderHolder， 它 是 通过 
Binder. m0bject 变 量 保 存 的 。 因 而 这 里 再 利用 gBinder0ffsets. mObject 
把 它 取 出 来 ， 紧 接着 调用 JavaBBinderHolder. get 方 法 : 


sp<JavaBBinder> get(JNIEnv* env, jobject obj) 
{ 
AutoMutex _1(mLock); 
sp<JavaBBinder> b = mBinder.promote(); 
if (b == NULL) {/* 第 一 次 */ 
b = new JavaBBinder(env, obj); 
mBinder = b; 


return b; 


因为 是 第 一 次 调用 ， 所 以 需要 new 一 个 JavaBBinder 对 象 ， 它 实际 上 
是 一 个 BBinder 。 这 样 ibinderForJava0bject 得 到 的 是 一 个 JavaBBinder 


的 强 指针 ， 接 下 来 看 下 如 何 把 它 写 入 Parcel 中 : 


/*frameworks/native/libs/binder/Parcel.cpp */ 
status_t Parcel: :writeSstrongBinder(const sp<IBinder>& val) 


{ 
} 


return flatten_binder(ProcessState::self(), val, this); 


FE RBA BWA S flatten binder: 


/*frameworks/native/libs/binder/Parcel.cpp*/ 
status_t flatten_binder(const sp<ProcessState>& proc,const sp<IBi 
Parcel* out) 


{ 
flat_binder_object obj; 
obj.flags = Ox7f | FLAT_BINDER_FLAG_ACCEPTS_FDS; 
if (binder != NULL) { 
IBinder *local = binder->localBinder(); 
if (!local) { 
} else {/* 走 的 是 这 个 分 支 */ 
obj.type = BINDER_TYPE_BINDER; 
obj.binder = local->getWeakRefs(); 
obj.cookie = local; 
} 
} else { 
} 
return finish_flatten_binder(binder, obj, out);/* 把 obj 写 入 Parc 
} 


首先 变量 bi nder 不 为 nul1， 而 且 binder->localBinder () 得 到 
BBinder 自 身 也 不 为 空 ， 所 以 obj 的 类 型 是 BINDER_TYPE_BINDER; cookie 
记录 的 是 BBinder 这 个 对 象 。 最 后 调用 finish flatten binder 把 ob j 写 
入 out 中 ， 即 通过 write0bject 把 obj 写 到 Parce1 空 间 的 相应 位 置 。 经 过 
这 一 系列 操作 后 ， 我 们 就 把 一 个 Binder 对 象 填充 到 Parcel 中 了 。 当 后 续 
向 Binder 驱动 发 起 ioct 1 时， 它 会 作为 数据 的 一 部 分 发 过 去 。 我 们 来 看 
看 这 部 分 的 处 理 : 


/* (内核 工 程 ): drivers/staging/android/Binder.c*/ 


static void binder_transaction(struct binder_proc 


*proc,struct bi 


struct binder_transaction_data *tr, int rep 


{ 


off_end = (void *)offp + tr->offsets_size;/*offset kik ( Hite? 
for (; offp < off_end; offp++) {V/*object 很 有 可 能 不 只 一 个 ， 所 以 逐 





struct flat_binder_object *fp; 


fp = (struct flat_binder_object *)(t->buffer->data + *o 


switch (fp->type) { 


case BINDER_TYPE_BINDER:/*BINDER 类 型 的 情况 下 */ 





case BINDER_TYPE_WEAK_BINDER: { 
struct binder_ref *ref; 





struct binder_node *node = binder_get_node(proc, f 


if (node == NULL) {/* 这 是 一 个 新 节点 */ 


node = binder_new_node(proc, fp->binder, fp-> 


J 





ref = binder_get_ref_for_node(target_proc, node); 


if (fp->type == BINDER_TYPE_BINDER) 


fp->type = BINDER_TYPE_HANDLE;// 做 转换 


else 


fp->type = BINDER_TYPE_WEAK_HANDLE; 





fp->handle = ref->desc; 


} break; 


在 Binder 驱动 的 设计 中 ， 只 要 用 户 携带 一 个 Binder 对 象 “路 
过 ” 它 ， 就 会 被 记录 下 来 。 在 上 面 的 代码 中 ， binder_get_node 会 查找 
当前 proc 中 的 nodes 树 中 是 否 已 经 存在 这 一 Binder 对 象 〈 以 fp 一 binder 
为 关键 字 ) ， 否 则 就 生成 binder_new_node 一 个 binder_node 节 点 并 把 它 
加 入 nodes 树 中 。 因 而 属于 当前 Proc 的 所 有 Binder 对 象 在 驱动 中 都 是 有 


记录 的 : 
struct binder_node { 
union { 


struct rb_node rb_node; 
struct hlist_node dead_node; 





J}; 
struct binder_proc *proc; // 此 Binder 对 象 所属 的 进程 


void _ user *ptr; //fp->binder 
void __user *cookie;//AUMae, bunk My seh xt MW eBBinder xt Re 





}; 


在 这 个 场景 中 ，WindowManagerService 这 个 Binder 对 象 就 记录 在 
Android 系 统 服务 进程 中 。 那 么 ，Client 是 如 何 找到 它 的 呢 ? 因 为 我 们 在 
target_proc 中 要 添加 一 个 指向 此 binder_node 的 引用 : 
binder_get_ref_for_node。 这 个 涵 数 会 查找 proc->refs_by_node 树 中 
是 不 是 已 经 存在 这 样 的 节点 ， 否 则 就 生成 一 个 binder_ref 节 点 并 按 顺 序 
加 入 refs_by_node 树 中 : 


struct binder_ref { 


struct rb_node rb_node_desc; 
struct rb_node rb_node_node; 


struct binder_proc *proc; //binder_node 所 属 的 进程 
struct binder_node *node; // 这 个 ref 所 指向 的 binder_node 
uint32_t desc; //ref 编 号 ， 逐 渐 递 增 





Ek 





}; 


这 个 数据 结构 中 有 两 个 红 黑 树 节 点 ， 即 rb_node_desc 和 

rb_node_node， 前 者 将 使 binder_ref 被 加 入 proc-> refs_by_desc 树 

(desc 可 能 是 description 的 缩写 ) ， 而 后 者 则 加 入 refs_by_node。 为 
什么 同一 个 节点 要 加 入 两 棵 树 中 呢 ? 一 种 合理 的 解释 是 这 两 种 排序 方法 
可 以 在 不 同 的 场合 提高 检索 效率 。 另 外 ，desc 编 号 是 随 着 新 节点 的 加 入 
而 不 断 递增 的 ， 因 而 能 保证 它 的 了 唯 一 性 。 执 行 完 这 些 操作 后 ，fp->type 
类 型 就 被 改 成 BINDER_TYPE_HANDLE， 而 fp->hand1e 则 是 ref->desc。 当 
target 被 唤醒 时 ， 它 的 proc 中 已 经 有 了 指向 binder_node 的 binder_ref 
节点 了 ， 而 且 fp 中 记录 了 此 binder_ref 的 desc 值 。 


清楚 了 BBinder 的 由 来 后 ， 我 们 接着 刚才 的 executeCommand 逊 数 往 
下 看 : 


sp<BBinder> b((BBinder*)tr.cookie); 
const status_t error = b->transact(tr.code, buffer, &reply, tr.fl 


2E S518 SBBinderAytransactrey A: 


/*frameworks/native/libs/binder/Binder.cpp*/ 


status_t BBinder::transact(uint32_t code, const Parcel& data, Par 


{ 


data.setDataPosition(0); 


status_t err = NO_ERROR; 
switch (code) { 
case PING_TRANSACTION: 
reply->writeInt32(pingBinder()); 
break; 
default: 
err = onTransact(code, data, reply, flags); 
break; 


} 


return err; 


除了 PING_TRANSACTION 的 情况 外 ， 其 他 事项 一 律 调 用 onTransact 来 
处 理 。 而 JavaBBinder 重 载 了 这 个 方法 : 


/* JavaBBinder@android_util_Binder.cpp*/ 
virtual status_t onTransact(uint32_t code, const Parcel& data, Pa 
uint32_t flags = 0) 
{ 


JNIEnv* env = javavm_to_jnienv(mvM); 

IPCThreadState* thread_state = IPCThreadState::self(); 

const int strict_policy_before = thread_state->getStrictM 

thread_state->setLastTransactionBinderFlags(flags) ; 

jboolean res = env->CallBooleanMethod(mObject, gBinderOff 
code, (int32_t)&data, (int3 


显然 这 个 函数 的 重点 就 是 调用 Java 层 Binder 对 象 〈 即 AD1L 中 Stub 类 
的 父 类 ) dea lariat a 请 求 传递 过 去 。 这 个 接口 是 
Binder. execTransact， 已 经 预先 存储 在 gBinder0ffsets. mExec 
Transact f : 


/*Binder.java*/ 

private boolean execTransact(int code, int dataObj, int replyObj, 
Parcel data = Parcel.obtain(data0Obj); 
Parcel reply = Parcel.obtain(replyObj); 
boolean res; 


try { 
res = onTransact(code, data, reply, flags); 


} catch (RemoteException e) { 


return res; 


l 


终于 把 Binder Client 的 请 求 传递 到 Binder (java) 了 ， 因 为 涉及 JN| 
的 中 间 处 理 过 程 ， 使 得 整个 逻辑 显得 腑 肿 而 复杂 。 事 情 还 没 结束 ， 因 为 
每 个 Binder Server 肯 定 会 有 自己 的 业务 码 ， 所 以 它们 都 要 重 写 


onTransact 接 口 ， 如 WindowManagerService. java 中 


@Override 
public boolean onTransact(int code, Parcel data, Parcel reply 


try { 
return super.onTransact(code, data, reply, flags); 
} catch (RuntimeException e) { 


} 
} 


这 个 onTransact 似 乎 什么 也 没 做 。 


是 的 。 由 于 AIDL 自 动 生成 的 Stub 类 也 重 写 了 onTransact， 而 且 已 经 
为 开发 者 做 好 了 无 缝 跳 转 ， 所 以 我 们 在 编写 基于 A1DL 的 Server 时 ， 只 要 
实现 相应 的 业务 处 理 接口 就 行 了 。 比 如 : 


/*IWindowManager . java*/ 
@Override publicboolean onTransact(int code, android.os.Parcel da 


switch(code) 


{ 
case TRANSACTION_openSession: 
{ 


android.view.IWindowSession _result = this.openSession(_arg0, _ar 
reply.writeNoException(); 
reply.writeStrongBinder((((_result!=null))?(_result.asBinder()):( 
returntrue; 


J 


上 面 代 码 中 的 this. openSession 会 调用 
openSession@WindowManagerService. java， 而 且 还 负责 将 结果 写 入 
Parce1 并 通过 Binder 驱 动 返回 给 调用 者 一 一 对 比 SM 中 的 手工 实现 是 不 是 
方便 了 很 多 ? 


这 样 我 们 就 以 WindowManagerService 为 例 ， 完 整地 分 析 了 基于 A1DL 
的 Binder Server 的 实现 流程 。 


最 后 小 结 一 下 ， 仍 然 按 照 本 节 开 头 提出 的 几 个 疑问 来 展开 。 
。 启动 时 机 问题 

WMS 是 在 System_Server 中 局 动 的 。 
。 如 何 提 供 一 致 的 服务 接口 


通过 分 析 aidl 文 件 以 及 由 它 转 化 生成 的 java 接 口 文 件 ， 我 们 知道 一 
个 AIDL 接 口 包 插 了 IwindowManager，1WindowManager. Stub 和 
|WindowManager. Stub. Proxy 三 个 重要 类 。 后 两 者 分 别 面向 于 WMS 的 服务 
端 和 Binder Client 本 地 代理 的 实现 ， 且 都 继承 于 IWindowManager， 
而 就 保证 了 C1ient 和 Server 是 在 完全 一 致 的 服务 接口 上 进行 通信 的 。 


e 如 何 与 Bindet 驱 动 交互 的 
通过 人 解析， 我们 发 现 原来 系统 服务 进程 在 一 开始 就 调用 了 : 


ProcessState: :self()->startThreadPool( ); 
IPCThreadState: :self()->joinThreadPool(); 


它们 将 导致 程序 最 终 进 入 一 个 类 似 于 binder_loop 的 主 循环 。 因 
而 ， 在 这 个 进程 中 的 Binder 对 象 都 可 以 不 用 单独 与 驱动 进行 交互 。 


e Client 如 何 准确 地 访问 到 目标 进程 中 的 Binder Server 


有 两 种 方式 可 以 让 Binder Server 可 知 ， 其 一 是 通过 在 SM 中 注册 ， 
也 就 是 WMS 所 属 的 情况 。 其 二 就 是 下 一 小 节 我 们 会 谈 到 的 匿名 Server 实 
现 。 对 于 实名 的 Server， 当 它 利用 addServi ce 来 把 自身 注册 到 SM 中 时 ， 
会 “路 过 ”Binder 驱 动 ， 而 后 者 就 会 按 计 划 把 这 一 Binder 对 象 链接 到 
proc-> nodes， 以 及 target_proc-> refs by _ desc 和 target_proc-> 
refs_by_node 中 。 在 这 一 场景 中 ，proc 是 系统 服务 进程 ， 而 
target_proc 则 是 SM。 也 就 是 说 ，SM 中 拥有 了 一 个 描述 WMS 的 
binder_node 的 引用 。 这 样 当 一 个 Binder Client 通过 getService 回 SM 发 
起 查询 时 ， 后 者 就 可 以 准确 地 告知 这 个 调用 者 它 想 访问 的 WMS 节 点 所 在 


的 位 置 。 这 就 是 前 面 我 们 在 分 析 executeCommand 函 数 时 ，Client 发 过 来 
的 请 求 中 会 记录 着 WMS 的 BBi nder 对 象 地 址 的 原因 。 


6.7 匿名 Binder Server 


前 一 小 节 我 们 讨论 的 Wi ndowManagerService 服 务 ， 通 过 addService 
把 自己 注册 到 了 Service Manager 中 ， 因 而 任何 Binder Client 都 可 以 通 
过 SM 的 getService 接 口 来 获取 它 的 一 个 引用 。 我 们 称 这 种 类 型 的 Binder 
Server 为 “实名 ”Server。 


而 事实 上 ，Android 系 统 中 还 存在 着 另 一 种 Binder Server， 它 们 并 
不 在 Service Manager 中 注册 一 一 我 们 称 之 为 “匿名 ”的 Binder 
Server 。 匿 名 性 和 融 来 的 一 个 直接 好 处 是 安全 系数 的 提高 ， 如 某 个 应 用 程 
序 提供 了 某 种 Server 服 务 ， 但 并 不 希望 面向 公众 开放 。 显 然 实 名 的 
Server 无 法 避免 外 珊 的 访问 一 一 任何 第 三 方 的 程序 都 可 以 通过 Service 
Manager 提 供 的 getService 来 获取 到 这 一 Server。 而 “匿名 ”方式 的 
Binder Server 则 可 以 很 好 地 解决 这 一 问题 。 


本 小 节 将 以 后 续 显 示 系 统 中 将 会 出 现 的 1WindowSession 为 例 来 分 
析 “ 匿 名 ”Server 的 内 部 实现 。 


先 来 看 看 1WindowSession 的 接口 文件 : 


/*frameworks/base/core/java/android/view/IWindowSession.aidl*/ 
interface IWindowSession { 
int add(IWindow window, int seq, in WindowManager.LayoutParam 
in int viewVisibility, out Rect outContentInsets, 
out InputChannel outInputChannel); 
../V/ 其 他 接口 省 略 





这 个 aid1 文 件 经 过 工具 转化 后 ， 核 心 内 容 如 下 : 


public interfaceIWindowSession extends android.os.IInterface 
{public static abstract class Stubextends android.os.Binder imple 


{ 
@Override public boolean onTransact(int code, android.os.Parcel d 
Switch (code) 


case TRANSACTION_add: 
{ 


: 
> 


return super.onTransact(code, data, reply, flags); 


private static classProxy implements android.view. IWindowSession 


{ 


private android.os.IBinder mRemote; 


@Override public int add(..) throws android.os.RemoteException 


{ 
} 
} 
static final int TRANSACTION_add =(android.os.IBinder.FIRST_CALL_ 


public int add(...) throws android.os.RemoteException; 
} 


除了 业务 处 理 相关 的 代码 外 ， 它 和 前 一 小 节 的 I1WindowManager 基 本 
上 类 似 ， 因 而 此 处 不 再 袭 述 了 。 我 们 知道 ， 一 个 匿名 的 Binder Server 
必须 借助 于 其 他 手段 才能 被 Client 访 问 到 。 比 如 IWindowSession 就 是 靠 
WindowManagerService 这 一 实名 Server 提 供 的 openSession 获 取 的 。 代 
人 码 段 如 下 所 示 : 


/*frameworks/base/core/java/android/view/WindowManagerGlobal. java 
public static IWindowSession getWindowSession() { 
synchronized (WindowManagerGlobal.class) { 
if (sWindowSession == null) {// 全 局 变量 ， 用 于 避免 重复 操作 
try { 





IWindowManager windowManager = getWindowManage 
sWindowSession = windowManager.openSession( _ 
imm.getClient(), imm.getInputContext());//i8 


} catch (RemoteException e) { 
Log.e(TAG, "Failed to open window session", 
} 
} 


return sWindowSession; 


Android 4. 3 中 把 与 WindowManager 相 关 的 元 素 都 统一 封装 到 了 
WindowManagerGlobal. java 中 ， 包 括 上 面 的 I1WindowSession。 在 
getWindowSession 的 实现 中 ，WMS 属 于 实名 的 Binder Server， 因 而 可 以 
通过 调用 
getWindowManagerServicelWindowManager. Stub. aslnterface (Servicel 
getService ("window") ) 来 获取 到 它 的 本 地 代理 ， 而 1WindowSession 则 
3 “匿名 ”的 ， 它 必须 经 由 前 者 提供 的 openSession 接 口 来 间接 地 访问 
到 |: 


/*frameworks/base/services/java/com/android/server/wm/WindowManag 
public IWindowSession openSession(IInputMethodClient client, 
IInputContext input Cont 


Session session = new Session(this, client, inputContext) 
return session; 


这 个 时 候 Session (〈 它 是 IWindowSession 服 务 器 端的 实现 ) ARE 
正 地 创建 起 来 。 顺 便 说 一 人 下， 在 生成 Session 对 象 时 ， 同 时 传 入 了 thi s 
指针 〈 即 WMS 自身 ) ， 这 样 后 续 这 个 Session 对 象 就 可 以 把 从 应 用 程序 收 
到 的 请 求 转发 给 WMS 了 。 


有 了 这 个 IWindowSession 代 理 以 后 ， 我 们 就 可 以 像 使 用 其 他 Binder 
Server 一 样 获得 它 的 服务 了 。 比 如 在 


ensureTouchMode@VviewRoot Imp1. java 中 : 


mWindowSession.setInTouchMode(inTouchMode) ; 


后 小 结 一 下 : 一 个 匿名 Binder Server 与 实名 Server 的 差异 主要 
过 Service Manager 来 获得 对 它 的 引用 ; 而 前 者 则 是 以 
其 他 实名 Server 为 中 介 来 传递 这 一 引用 信息 ， 仅 此 而 已 。 另 外 ， 对 于 
Binder 驱 动 而 言 ， 只 要 是 “路 过 ” 它 且 以 前 没有 出 现 过 的 Binder 对 象 ， 
都 会 被 记录 下 来 。 所 以 : 


e 实名 Bindet Server 


通过 addService 把 Server 添 加 到 SM 时 是 它 第 一 次 “路 过 ”驱动 ， 因 

会 被 记录 到 binder_node 中 ， 并 在 SN 的 进程 信息 中 添加 binder_ ref5| 
用 。 这 样 后 面 有 客户 端 需要 查询 时 ，SM 就 能 准确 得 出 这 一 Server 所 在 的 
binder node 位置 了 。 


e  % Binder Server 


在 这 个 场景 中 ，IWindowSession 是 靠 WMS 来 传递 的 ;并 且 要 等 到 
Binder Client 调 用 openSession 时 才 真 正 地 生成 一 个 Session 对 象 一 一 
这 个 对 象 作为 reply 结 果 值 时 会 第 一 次 “路 过 ”Binder 驱 动 一 一 此 时 就 
会 被 记录 到 系统 服务 进程 的 proc->nodes 中 〈 注 意 ，IWindowSession 也 
存在 于 系统 服务 进程 中 ) ， 并 且 target_proc (也 就 是 ViewRoot1mp1 所 
在 进程 ) 会 有 一 个 binder_ref 指 向 这 一 binder_node 节 点 。 


Android Bait 


7.1 第 一 个 系统 进程 (init) 


Android 设 备 的 启动 必须 经 历 3 个 阶段 ， 即 Boot Loader, Linux 
Kerne1 和 Android 系 统 服 务 ， 默 认 情 况 下 它们 都 有 各 自 的 启动 宕 面 。 


严格 来 说 ，Android 系 统 实际 上 是 运行 于 Linux 内 核 之 上 的 一 系 
列 “ 服 务 进程 ”， 并 不 算 一 个 完整 意义 上 的 “操作 系统 ”。 这 些 进 程 是 
维持 设备 正常 工作 的 关键 ， 而 它们 的 “ 老 祖宗 ”就 是 init。 


作为 Android 中 第 一 个 被 启动 的 进程 ，init 的 P1D 值 为 0。 它 通过 解 
析 init. rc 脚本 来 构建 出 系统 的 初始 运行 形态 一 一 其 他 Android 系 统 服 务 
程序 大 多 是 在 这 个 “rec” 上 脚本 中 描述 并 被 相继 启动 的 。1nit. rc 不 但 语 
法 相对 简单 ， 而 且 因 为 采用 了 纯 文 本 的 编写 方式 ， 所 以 可 读 性 很 高 ， 是 
开发 商 控制 Android 系 统 局 动 状态 的 一 大 “利器 ”。 


接 下 来 首先 讲解 jnit. rc 脚本 的 语法 规则 。 
7.1.1 init. rc 语法 

Google 对 于 init. rc 的 注解 很 少 ， 唯 一 的 官方 文档 可 能 就 
fz/system/core/init/Readme. txt。 所 以 本 小 节 的 分 析 主 要 基于 两 个 依 
据 一 一 除了 这 个 Readme 文 件 外 ， 就 是 init 进 程 的 源码 实现 (与 init. rc 
解析 相关 的 代码 大 部 分 集中 在 Init_parser.c 中 ) 。 


一 个 完整 的 init. rc 脚本 由 4 种 类 型 的 声明 组 成 ， 即 : 


e Action (动作 ) 3 

e Commands (命令 ) ; 
e Services (服务 ) ; 

e Options (选项 ) 。 


首先 需要 了 解 一 些 通用 的 语法 规则 : 
° 注释 以 井 号 键 〈“#”) 开头 
° AHFMEBRUASEA a, FNAT R; 


° C 语 言 风 格 的 反 斜 杠 转 义 字符 V) 可 以 用 来 为 参数 添加 空 
格 ; 


为 了 防止 字符 串 中 的 空格 把 其 切割 成 多 个 部 分 ， 我 们 需要 对 其 
使 用 双 引 号 ; 


° 行 尾 的 反 斜 杠 用 来 表示 下 面 一 行 是 同一 行 ; 

e Actions (动作) Services (ARS) 暗示 着 一 个 新 语句 的 开 
始 ， 这 两 个 关键 字 后 面 跟着 的 commands (MS) 或 者 options Ge 
项 ) 都 属于 这 个 新 语句 ; 


° Actions (动作 ) 和 Services (ARS) 有 唯一 的 名 字 ， 如 果 出 
现 和 已 有 动作 或 服务 重 名 的 ， 将 会 被 当成 错误 忽略 掉 。 


接 下 来 详细 分 析 各 组 成 元 素 。 
1. Actions (动作 ) 
动作 的 一 般 格式 如 下 : 


on <trigger> ## 触 发 条 件 
<Command1> ## 执 行 命令 
<command2>## 可 以 执行 多 个 命令 
<command3> 


从 上 面 的 描述 可 以 知道 ， 一 个 Action 其 实 就 是 响应 某 事 件 的 过 程 。 
即 当 <trigger> 所 描述 的 触发 事件 产生 时 ， 依 次 执行 各 种 command (同一 
事件 可 以 对 应 多 个 命令 ) 。 从 源码 实现 的 角度 来 说 ， 当 相应 的 事件 发 生 
后 ， 系 统 会 对 init. rc 中 的 各 <trigger> 进 行 匹配 一 一 只 要 发 现 符合 条 件 
的 Action， 融 会 把 它 加 入 “命令 执行 队列 ”的 尾部 《除非 这 个 Act ion 在 
队列 中 已 经 存在 ) ， 然 后 系统 再 对 这 些 命令 按 顺 序 执行 。 


2. Commands (命令 ) 
命令 将 在 所 属 事件 发 生 时 被 一 个 个 地 执行 。 
表 7-1 列 出 了 init 中 定义 的 一 些 常见 事件 。 
表 7-1 Init. rc 中 常见 触发 事件 


| 
box | 这 是 init 程 序 局 动 后 触发 的 第 一 个 事件 


当 属 性 <name> 满 足 特 定 <vaule> 时 触发 。 后 面 有 
关于 属性 的 进 一 





当 设 备 节 点 添加 /删除 时 触发 此 事件 


当 指 定 的 服务 <name> 存 在 时 触发 





针对 这 些 事件 ， 有 如 表 7-2 所 示 命 令 可 供 使 用 。 


57-2 init. rc 中 的 常见 命令 





Fork 并 执行 一 个 程序 ， 其 路 径 为 <path>。 
这 条 命令 将 阻塞 直到 该 程序 启动 完成 ， 因 
此 它 有 可 能 造成 init 程 序 在 某 个 点 不 停 地 等 





设置 某 个 环境 变量 <name> 的 值 为 
<value> 。 这 是 对 全 局 有 效 的 ， 即 其 后 所 有 
进程 都 将 继承 这 个 变量 


解析 另 一 个 配置 文件 ， 名 为 <filename>， 
以 扩展 当前 配置 


chdir <directory> 更 改 工 作 目 录 为 <directory> 


chmod <octal-mode> 
<path> 


import <filename> 





chown <owner> | 更 改 文件 所 有 者 和 组 群 


<group><path> 





ae <directory> iia 目录 位 置 | 


class_start 启动 由 <serviceclass> 类 名 指定 的 所 有 相关 
<serviceclass> 服务 ， 如 果 它 们 不 在 运行 状态 的 话 





class_stop 停止 所 有 由 <serviceclass> 指 定 的 服务 ， 如 
<serviceclass> 果 它 们 当前 正在 运行 的 话 


在 <path> 路 径 上 安装 一 个 模块 





<device><dir> [ 
<mountoption> ]* 


设置 系统 属性 <name> 的 值 为 <value> 





设置 一 种 资源 的 使 用 限制 。 这 个 概念 亦 存 
setrlimit <resource> jj 在 于 Linux 系 统 中 ，<cur> 表 示 软 限制 ， 
<cur><max> <max> 表 示 便 限制 。 更 多 详情 请 参考 Linux 

资料 





. 这 个 命令 将 启动 一 个 服务 ， 如 果 它 没有 处 
于 运行 状态 的 话 


l eS aR ORE IE ARS. MR E IE 
< > Let /a i 
stop <service 在 云 行 的 话 


symlink <target> 创建 一 个 <path> 路 径 的 链接 ， 目 标 为 


write <path><string> 打开 一 个 文件 ， 并 写 入 一 个 或 多 个 字 串 


[ <string> ]* 


3. Services (服务 ) 


Services 其 实 是 可 执行 程序 ， 它 们 在 特定 选项 的 约束 下 会 被 init 程 
序 运行 或 者 重启 (Service 可 以 在 配置 中 指定 是 否 需要 退出 时 重启 ， 这 
样 当 Service 出 现 异常 crash 时 就 可 以 有 机 会 复原 )。 

它 的 一 般 格式 为 : 


service <name><pathname> [ <argument> ]* 
<option> 
<option> 


@ <name> 


表示 此 service 的 名 称 。 
e <pathname> 
此 service 所 在 路 径 。 因 为 是 可 执行 文件 ， 所 以 一 定 有 存储 路 径 。 
e <argument> 
启动 service 所 带 的 参数 。 
。<option> 
对 此 service 的 约束 选项 《后面 有 详细 列表 说 明 ) 。 
4, Options GEA) 
Services 中 的 可 用 选项 如 表 7-3 所 示 。 


表 7-3 Services 中 的 可 用 选项 


表明 这 是 对 设备 至 关 重 要 的 一 个 服务 。 如 果 它 在 
四 分 钟 内 退出 超过 四 次 ， 则 设备 将 重 局 进入 恢复 








此 服务 不 会 自动 启动 ， 而 是 需 


setenv <name> 


设置 环境 变量 <name> 为 某 个 值 <value> 
<value> 





socket <name>j 创 建 一 个 名 为 /dev/socket/<name> 的 unix domain 


socket， 然 后 将 它 的 fd 值 传 给 局 动 它 的 进程 有 效 


<type><perm> | 的 <type> 值 包括 dgram,stream 和 seqpacket。 而 user 
和 group 的 默认 值 是 0 





在 局 动 服务 前 将 用 户 切 换 至 <username>， 默 认 情 
况 下 用 户 都 是 root 





综合 以 上 的 分 析 会 发 现 ， 其 实 init. rc 的 语法 可 以 用 一 个 统一 的 形 
式 来 理解 。 如 下 所 示 E 


On<SOMETHING - HAPPENED> 
<WHAT - TO-DO> 


对 于 Action 来 说 ， 它 是 当 《trigger3》 发 生 时 去 执行 命令 ; 而 对 于 


Service 来 说 ， 它 是 always 发 生 的 不 需要 局 动 触 发 条 件 ) ， 然 后 去 局 
动 指 定 的 可 执行 文件 “并 且 由 0ption 来 限制 执行 条 件 )。 


7.1.2 init. rc 实例 分 析 
本 小 节 通 过 分 析 一 个 init. rc 范例 来 进一步 理解 它 的 语法 规则 : 


on boot#boot 事 件 
export PATH /sbin:/system/sbin:/system/bin  # 响 应 boot 事 件 ， 设 置 系 
export LD_LIBRARY_PATH /system/1lib # 咱 应 boot 事 件 ， 设 置 库 路 径 
mkdir /dev # 创 建 /dev 目 录 
mkdir /proc # 创 建 /proc 目 录 
mkdir /sys # 创 建 /sys 目 录 。 这 时 还 没有 超出 on boot 的 作用 范围 ， 下 同 
mount tmpfs tmpfs /dev 
mkdir /dev/pts 
mkdir /dev/socket 
mount devpts devpts /dev/pts 
mount proc proc /proc 
mount sysfs sysfs /sys # 以 上 几 行 用 于 挂 载 文件 系统 以 及 创建 新 的 目录 
write /proc/cpu/alignment 4 # 打 开 文 件 ， 并 写 入 数值 
ifup lo # 建 立 ]0 网 络 连 接 
hostname localhost # 设 置 主机 名 
domainname localhost # 设 置 域名 
mount yaffs2 mtd@system /system 
mount yaffs2 mtd@userdata /data 
import /system/etc/init.conf # 导 入 另 一 个 配置 文件 
class_start default # 启 动 所 有 标志 为 default 的 服务 
service adbd /sbin/adbd # 启 动 adbd 服 务 进程 
user adb 
group adb # Adbd 是 android debug bridge daemon 的 缩写 ， 它 为 开发 者 与 设 
# 我 们 将 在 本 书 工具 篇 中 对 adb 进 行 详细 分 析 。 
service usbd /system/bin/usbd -r 
user usbd 
group Usbd 
socket usbd 666 # 启 动 usbd 服 务 。 
service zygote /system/bin/app_process -Xzygote /system/bin --zyg 
socket zygote 666 # 启 动 zygote 服 务 。Zygote 是 系统 的 “孵化 器 "， 负 责 生产 全 
on device-added-/dev/compass 
start akmd # 当 增加 了 /dev/compass 节 点 后 ， 启 动 akmd 服 务 
on device-removed-/dev/compass 
stop akmd # 当 移 除了 /dev/compass 节 点 后 ， 停 止 akmd 服 务 
service akmd /sbin/akmd 
disabled 
user akmd 
group akmd # 因 为 这 里 对 akmd 服 务 使 用 了 disabled 选 项 ， 所 以 系统 不 会 主动 去 启 z 
# 描 述 的 /dev/compass 节 点 出 现时 ， 才 显 式 地 调用 此 服务 


7.2 系统 关键 服务 的 局 动 简 析 





















































作为 Android 系 统 的 第 一 个 进程 ，init 将 通过 解析 init_ ro 来 陆续 启 
动 其 他 关键 的 系统 服务 进程 一 一 其 中 最 重要 的 就 是 ServiceManager、 
Zygote 和 SystemServer 。 





7.2.1 Android 的 “DNS 服务 器 ” ServiceManager 


ServiceManager 是 Binder 机 制 中 的 “DNS 服务 器 ”， 负 责 域 名 〈 某 
Binder 服 务 在 ServiceManager 注 册 时 提供 的 名 称 ) 到 IP 地 址 (由 底层 
Binder 驱 动 分 配 的 值 ) 的 解析 。 


B ServiceManager 4 Init. rc 里 描述 并 由 init 进 程 启动 的 。 如 下 所 
示 : 


/*sytem/core/rootdir/Init.rc*/ 
service servicemanager /system/bin/servicemanager 
class core 
user system 
group system 
critical 
onrestart restart healthd 
onrestart restart zygote 
onrestart restart media 
Onrestart restart surfaceflinger 
onrestart restart drm 


可 以 看 到 ，servicemanger 是 一 个 Linux 程 序 。 它 在 设备 中 的 存储 路 
径 是 /system/bin/service- manager， 源 码 路 径 则 
是 /frameworks/native/cmds/servicemanager。 


ServiceManager 所 属 class 是 core， 其 他 同类 的 系统 进程 包括 
ueventd、console (/system/bin/sh) 、adbd 等 。 根 据 core 组 的 特性 ， 这 
些 进 程 会 同时 被 启动 或 停止 。 另 外 ，critical 选 项 说 明 它 是 系统 的 关键 
进程 一 一 意味 着 如 果 进 程 不 幸 地 在 4 分 钟 内 异常 退出 超过 4 次 ， 则 设备 将 
重启 并 进入 还 原 模式 。 当 ServiceManager 每 次 重启 时 ， 其 他 关键 进程 如 
Zygote、media、surfacef|inger 等 也 会 被 restart。 


7.2.2 “孕育 ”新 的 线程 和 进程 一 一 Zygote 


Zygote 这 个 词 的 字面 意思 是 “受精 卵 ”， 因 而 可 以 “孕育 ”出 一 
个 “新 生命 ”。 正 如 其 名 所 示 ，Android 中 大 多 数 应 用 进程 和 系统 进程 


都 是 通过 Zygote 来 生成 的 。 
接 下 来 具体 分 析 下 Zygote 是 如 何 启 动 的 。 


和 ServiceManager 类 似 ，Zygote 也 是 由 init 解 析 rc 脚 本 时 启动 的 。 
早期 的 Android 版 本 中 Zygote 的 启动 命令 直接 被 书写 在 init. rc 中 。 但 随 
着 硬件 的 不 断 升级 换代 ，Android 系 统 不 得 不 面 对 32 位 和 64 位 机 器 同时 
存在 的 状况 ， 因 而 ， 对 Zygote 的 局 动 也 需要 根据 不 同 的 情况 区 分 对 待 : 


/*system/core/rootdir/init.rc*/ 
import /init.${ro.hardware}.rc 
import /init.${ro.zygote}.rc 


根据 系统 属性 ro. zygote 的 具体 值 ， 我 们 需要 加 载 不 同 的 描述 
Zygote 的 rc 脚本 。 壁 如 下 面 是 一 个 典型 的 例子 : 


|_] init.zygote32.rc 
|_| init.zygote32_64.rc 
|_| init.zygote64.rc 
|_| init.zygote64_32.rc 


其 中 zygote32 和 zygote64 分 别 对 应 32 位 和 64 位 机 器 的 情况 ;而 
zygote32 64 和 zygote064 32 则 是 Primary Arch 和 Secondary Arch 的 组 
合 。 我 们 以 init. zygote64. rc 为 例 ， 相 关 代码 如 下 : 


service zygote /system/bin/app_process64 -Xzygote /system/bin --z 
class main 
socket zygote stream 660 root system 
Onrestart write /sys/android_power/request_state wake 
onrestart write /sys/power/state on 
onrestart restart media 
onrestart restart netd 


从 上 面 这 段 脚本 摘 述 可 以 看 出 : 


ServiceName: zygote 
Path: /system/bin/app_process64 
Arguments: -Xzygote /system/bin --zygote --start-system-server 


Zygote 所 属 class 为 main， 而 不 是 core。 和 其 同 class 的 系统 进程 有 
netd, debuggerd, rild=. 


从 zygote 的 path 路 径 可 以 看 出 ， 它 所 在 的 程序 名 
叫 “app_process64”， 而 不 像 Servi ceManager 一 样 在 一 个 独立 的 程序 
中 。 通 过 指定 --zygote 人 参数，app_process 可 以 识别 出 用 户 是 否 需要 启 
动 zygote。 那 么 ，app_process 又 是 何方 神圣 呢 ? 


这 个 命名 有 些 “ 怪 异 ” 的 程序 源码 路 径 
在 /frameworks/base/cmds/app_process 中 ， 先 来 看 看 它 的 
Android. mk: 


LOCAL_PATH:= $(call my-dir) 
include $(CLEAR_VARS ) 


LOCAL_SRC_FILES:= \ 
app_main.cpp 


LOCAL_SHARED_LIBRARIES := \ 
libcutils \ 
libutils \ 
liblog \ 
libbinder \ 
libandroid_runtime 


LOCAL_MODULE:= app_process 
LOCAL_MULTILIB := both 
LOCAL_MODULE_STEM_32 := app_process32 
LOCAL_MODULE_STEM_64 := app_process64 
include $(BUILD_EXECUTABLE) 


上 述 是 构建 Multilib (64 位 和 32 位 系统 ) 的 一 个 编译 脚本 范例 。 其 
中 LOCAL_MULTILIB 用 于 指示 你 希望 针对 的 硬件 平台 架构 。 可 选 值 如 下 : 


«39» 

表示 只 编译 32 位 版 本 。 
“64” 

表示 只 编译 64 位 版 本 。 


“both” 


表示 同时 编译 32 位 和 64 位 的 版 本 。 
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表示 由 系统 根据 其 他 变量 来 决定 要 编译 的 目标 。 


这 些 知 识 点 我 们 在 本 书 的 编译 章节 已 经 做 过 详细 分 析 ， 不 清楚 的 读 
者 可 以 回头 复习 。 


从 上 面 的 摘 述 可 以 很 明显 地 看 到 ，app_process 其 实 扮演 了 一 个 类 
UF “E HAE, MACRATH “AR WE? 


只 要 分 析 一 下 app_process 的 主 函 数 实现 就 知道 答案 了 : 


/*frameworks/base/cmds/app_process/App_main.cpp*/ 
int main(int argc, char* const argv[]) 


{.. 


AppRuntime runtime(argv[0], computeArgBlockSize(argc, argv)); 


bool zygote = false; 

bool startSystemServer = false; 
bool application = false; 
String8 niceName; 

String8 className; 


++i; // Skip unused "parent dir" argument. 
while (i < argc) { 
const char* arg = argv[it+]; 
if (stremp(arg, "--zygote") == 0) { // 当 前 进程 是 否 用 于 承载 zy( 
zygote = true; 
niceName = ZYGOTE_NICE_NAME; 


} else if (strcmp(arg, "--start-system-server") == 0) {// 
startSystemServer = true; 

} else if (strcmp(arg, "--application") == 0) { 
application = true; 

} else if (strncmp(arg, "--nice-name=", 12) == 0) { 
niceName.setTo(arg + 12); 

} else if (strncmp(arg, "--", 2) != 0) { 
className.setTo(arg); 
break; 

} else { 
--İ; 
break; 
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if (zygote) { 
runtime.start("com.android.internal.os.ZygoteInit", args) 
} else if (className) { 
runtime.start("com.android.internal.os.RuntimeInit", args 
} else { 
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这 个 函数 用 于 解析 启动 app_process 时 传 入 的 参数 ， 具 体 如 下 。 
--zygote: 表示 当前 进程 用 于 承载 zygote。 
—-start-system-server: 是 否 需要 局 动 system server. 
—-application: 局 动 进入 独立 的 程序 模式 。 

一 nice-name: 此 进程 的 “别名 ”。 


对 于 非 zygote 的 情况 下 ， 在 上 述 参数 的 末尾 会 跟 上 main class 的 名 
称 ， 而 后 的 其 他 参数 则 属于 这 个 class 的 主 函 数 入 参 ; 对 于 zygote 的 情 
况 ， 所 有 参数 则 会 作为 它 的 主 肖 数 入 参 使 用 。 


在 我 们 这 个 场景 中 ，init. rc 指定 了 --zygote 选 项 ， 因 而 
app_process 接 下 来 将 启动 “Zygotelnit” 并 传 入 edt system- 
server”。 之 后 Zygotelnit 会 运行 于 Java 虚 拟 机 上 ， 为 什么 ? 


原因 就 是 runtime 这 个 变量 一 一 它 实际 上 是 一 个 AndroidRuntime 对 
象 ， 其 start 函 数 源 码 如 下 : 


/*frameworks/base/core/jni/AndroidRuntime.cpp*/ 
void AndroidRuntime::start(const char* className, const char* opt 


{ 


JNIEnv* env; 
if (startVm(&mJavaVM, &env) != 0) {// 启 动 虚 拟 机 
return; 





} 
onVmCreated(env);// 虚 拟 机 启动 后 的 回调 


对 于 虚拟 机 的 具体 启动 和 运行 过 程 ， 本 书 的 ART 虚 拟 机 一 章 有 详细 
介绍 ， 请 大 家 参考 阅读 。 我 们 这 里 假设 VM 可 以 成 功 启动 ， 并 进入 
Zygotelnit 的 执行 中 : 


/*frameworks/base/core/java/com/android/internal/os/ZygoteInit.ja 
public static void main(String argv[]) { 


try {.. 
boolean startSystemServer = false; 
String socketName = "zygote"; 


String abiList = null; 
for (int i = 1; i < argv.length; i++) { 
if ("start-system-server".equals(argv[i])) { 
startSystemServer = true;// 需 要 启动 System Serve) 
} else if (argv[i].startsWith(ABI_LIST_ARG)) { 
abiList = argv[i].substring(ABI_LIST_ARG.lengt 
} else if (argv[i].startswith(SOCKET_NAME_ARG)) { 
socketName = argv[i].substring(SOCKET_NAME_ARG 
} else { 
throw new RuntimeException("Unknown command li 
} 
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if (abiList == null) { 
throw new RuntimeException("No ABI list supplied. 
} 


registerZygoteSocket (socketName) ;// 注 册 一 个 Socket 
preload( ) ; // 预 加 载 各 类 资源 


if (startSystemServer) { 
startSystemServer(abiList, socketName);//Ja xt JEK 
} 


Log.i(TAG, "Accepting command socket connections"); 
runSelectLoop(abiList); 


closeServerSocket(); 

} catch (MethodAndArgsCaller caller) { 
caller.run(); 

} catch (RuntimeException ex) { 
Log.e(TAG, "Zygote died with exception", ex); 
closeServerSocket(); 
throw ex; 


Zygotelnit 的 主 函 数 并 不 复杂 ， 它 主要 完成 两 项 工作 : 


e 注册 一 个 Socket 





Zygote 是 “ 旷 化 器 ”， 一 旦 有 新 程序 需要 运行 时 ， 系 统 会 通过 这 个 
Socket (完整 的 名 称 为 ANDRO1D SOCKET zygote) 在 第 一 时 间 通 知 “ 总 
管家 ”， 并 由 它 负责 实际 的 进程 旷 化 过 程 。 


。 预 加 载 各 类 资源 
函数 preload 用 于 加 载 虚 拟 机 运行 时 所 需 的 各 类 资源 ， 包 括 : 


preloadClasses(); 
preloadResources(); 
preloadOpenGL(); 
preloadSharedLibraries(); 


从 名 称 中 相信 不 难看 出 上 述 各 个 preload 函 数 的 作用 。 以 
preloadClasses 为 例 ， 它 负责 加 载 和 初始 化 常用 的 一 些 classes。 这 些 
需要 预 加 载 的 classes 被 记录 在 framework. jar 的 preloaded-classes 
中 ， 如 下 例子 所 示 : 


# Classes which are preloaded by com.android.internal.os.ZygoteIn 
# Automatically generated by frameworks/base/tools/preload/writeP 


java. 


# MIN_LOAD_TIME_MICROS=1250 





# MIN_PROCESSES=10 
R$styleable 


android. 
android. 
android. 
android. 
android. 
android. 
android. 
android. 
android. 
android. 
android. 
android. 
android. 
android. 
android. 
android. 


accounts 
accounts 
accounts 
accounts 
accounts 
accounts 
accounts 
accounts 
accounts 
accounts 


.Account 

.Account$1 

.AccountManager 
.AccountManager$12 
.AccountManager$13 
.AccountManager$6 
.AccountManager$AmsTask 
.AccountManager$AmsTask$1 
.AccountManager$AmsTask$Response 
.AccountManagerFuture 

accounts. 
accounts. 
accounts. 
accounts. 
accounts. 


TAccountManager 
TAccountManager$Stub 
TAccountManager$Stub$Proxy 
IAccountManagerResponse 
TAccountManagerResponse$Stub 


android.accounts.OnAccountsUpdateListener 


从 程序 可 以 看 到 ，preloaded-classes 中 含有 多 达 数 和 干 个 classes， 
而 且 包 括 了 1ibcore 里 的 重要 基础 资源 ， 例 如 android. system 
android. util 等 。 另 外 ， 从 preloaded-classes 文 件 头 中 的 注释 可 以 看 
出 ， 这 个 记录 表示 通过 
frameworks/base/tools/preload/WritePreloadedClassFile. java 生 成 
的 。 感 兴趣 的 读者 可 以 自行 阅读 这 个 文件 了 解 其 中 的 细节 。 


启动 System Server 


如 果 app_ process 的 调用 参 参数 中 带 有 “--start-system-server”,， 
那么 此 时 就 会 通过 startSystemServer 来 启动 System Server， 我 们 将 在 
稍 后 对 这 个 函数 进行 具体 分 析 。 


Zygote 在 前 期 主要 担任 启动 系统 服务 的 工作 ， 后 期 则 又 担当 “程序 
及 化 ”的 重任 。 但 是 Zygote 只 在 init. rc 中 被 启动 一 次 ， 它 如 何 协 调 好 
这 两 项 工作 的 关系 呢 ? 我们 可 以 推断 一 下 ， 上 述 的 startSystemServer 
应 该 会 新 建 一 个 专门 的 进程 来 承载 系统 服务 的 运行 ， 而 后 app_ process 
= AYE FEMISS SS AZygotesy) “IHLA THI. PABZTSKET 
Ne ? 


/* frameworks/base/core/java/com/android/internal/os/ZygoteInit. j 
private static boolean startSystemServer(String abiList, String s 
throws MethodAndArgsCaller, RuntimeException { 


/* Hardcoded command line to start the system server */ 
String args[] = { 
"--setuid=1000", 
"--setgid=1000", 
"--setgroups=1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 
1032, 3001, 3002, 3003, 3006, 3007", 
"--capabilities="_+ capabilities + "," + capabilities 
"--runtime-init", 
"--nice-name=system_server", 
"com.android.server.SystemServer", 
】 


ZygoteConnection.Arguments parsedArgs = null; 


int pid; 


try { 
parsedArgs = new ZygoteConnection.Arguments(args); 


ZygoteConnection.applyDebuggerSystemProperty(parsedAr 
ZygoteConnection.applyInvokewithSystemProperty(parsed. 


/* Request to fork the system server process */ 
pid = Zygote.forkSystemServer ( 
parsedArgs.uid, parsedArgs.gid, 
parsedArgs.gids, 
parsedArgs.debugFlags, 
null, 
parsedArgs.permittedCapabilities, 
parsedArgs.effectiveCapabilities); // PREF 
} catch (IllegalArgumentException ex) { 
throw new RuntimeException(ex); 
} 


if (pid == 0) {// 子 进程 ， 即 System Server 所 承载 进程 
if (hasSecondZygote(abiList)) { 
waitForSecondaryZygote(socketName) ; 
} 


handleSystemServerProcess(parsedArgs);// 启 动 各 System S 





} 


return true; 
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上 述 代码 段 又 出 现 了 我 们 熟悉 的 fork 流 程 一 一 forkSystemServer 在 
内 部 利用 UN1X 的 fork 机 制 创建 了 一 个 新 进程 ， 而 这 个 “新 生 儿 ”“ 即 
pid==0 分 支 ) 会 在 随后 的 执行 过 程 中 通过 handleSystemServerProcess 
来 启动 各 种 支撑 系统 运行 的 System Server。 


在 跟踪 System Server 的 具体 启动 过 程 之 前 ， 我 们 先 来 为 Zygote 接 
下 来 的 工作 做 一 个 分 析 。 与 我 们 之 前 所 见 的 fork 处 理 流程 不 同 的 是 ， 
startSystemServer 中 并 没有 为 父 进程 专门 开辟 一 个 代码 分 支 ， 因 而 这 
个 函数 最 后 会 通过 return true 而 返回 到 Zygotelnit 的 主 函 数 中 。 紧 随 
其 后 的 语句 就 是 : 


runSelectLoop(abiList); 


从 runSelectLoop 的 函数 名 称 可 以 猜 到 ， 这 很 可 能 会 是 一 个 “和 死 循 
环 ” 一 一 除非 Zygote 退 出 或 者 出 现 异常 才 会 跳出 循环 : 


/* frameworks/base/core/java/com/android/internal/os/ZygoteIn 

private static void runSelectLoop(String abiList) throws Meth 
ArrayList<FileDescriptor> fds = new ArrayList<FileDescrip 
ArrayList<ZygoteConnection> peers = new ArrayList<ZygoteC 
FileDescriptor[] fdArray = new FileDescriptor[4]; 


fds.add(sServerSocket.getFileDescriptor()); 
peers.add(null);// 添 加 null 是 为 了 保持 fds 和 peers 的 一 致 性 


int loopCount = GC_LOOP_COUNT;// 设 定 多 少 次 循环 才 调 用 垃圾 回收 函 
while (true) {// 确 实 如 我 们 所 料 ， 是 一 个 死 循环 
int index; 
if (loopCount <= 0) { 
gc();// 达 到 10 次 循环 ， 做 一 次 gc 
loopCount = GC_LOOP_COUNT; 
} else { 
loopCount--; 
} 


try { 

fdArray = fds.toArray(fdArray); 

index = selectReadable(fdArray); 
} catch (IOException ex) { 

throw new RuntimeException("Error in select()", e 
} 


if (index < 0) {// 出 错 的 情况 
throw new RuntimeException( "error in select()"); 

} else if (index == 0) {// 有 新 的 连接 请 求 
ZygoteConnection newPeer = acceptCommandPeer (abiL 
peers.add(newPeer ) ; 
fds.add(newPeer.getFileDescriptor()); 

} else {// 已 建立 的 连接 中 有 客户 端 发 过 来 的 数据 需要 处 理 
boolean done; 
done = peers.get(index).runOnce(); 












































if (done) { 
peers.remove(index) ; 
fds.remove(index); 


} 


Ay 中 可 以 看 到 ，runSelectLoop 的 主体 的 确 是 一 个 whi le 死 循 
RK, € 将 作为 zygote 的 守护 体 存在 。 因为 zygote 此 时 运 和 了 在 虚拟 机 环境 
中 ， 所 以 它 需要 考虑 垃圾 回收 的 问题 。 不 过 这 是 一 项 非常 耗 时 的 操作 ， 


如 果 操 作 过 于 频繁 ， 每 次 回收 的 垃圾 并 不 会 很 多 ， 那 么 就 得 不 偿 失 。 所 
以 上 述 函 数 中 设 定 了 GC_LOOP_COUNT 为 10， 意 味 着 whi 1e 每 循环 十 次 才 会 
调用 一 次 gc 0 。 那 么 whi le 执行 一 轮 都 完成 了 哪些 工作 呢 ? 


我 们 从 sServerSocket. getFileDescr iptor () 获取 到 的 是 前 面 通过 
registerZygoteSocket 创 建 的 Server Socket 的 文件 描述 符 ， 它 会 被 添 
加 到 一 个 ArrayList<Fi leDescriptor> 类 型 的 fds 变 量 中 。 这 同时 也 意味 
着 zygote 中 不 光 只 有 一 个 Socket 产 生 。 具 体 而 言 ，whi le 循环 中 会 先 通 
过 如 下 两 个 语句 来 判断 当前 哪个 fd 处 于 可 读 状 态 : 


fdArray = fds.toArray(fdArray); 
index = selectReadable(fdArray); 


当 fds 这 个 ArrayLi st 指示 的 某 个 文件 有 可 读数 据 时 ， 返 回 的 index 
值 就 代表 此 文件 对 应 的 fi le descriptor 在 队列 中 的 序列 。 另 外 ， 这 个 
函数 还 有 一 个 特殊 的 返回 值 : 0。 因 为 fds 中 的 第 一 个 元 素 为 Zygote 的 
Server Socket， 所 以 index 为 0 代表 了 有 新 的 连接 请 求 。 这 和 网 络 连接 
中 的 Socket 概 念 是 一 致 的 。 


e index ==0 


此 时 我 们 需要 通过 acceptCommandPeer 来 接受 来 自 客 户 端的 连接 ， 
产生 一 个 新 的 Zygote Connection， 然 后 分 别 更 新 peers 和 fds。 为 了 保 
证 这 两 个 列表 中 的 对 象 序列 号 保持 一 致 ， 可 以 看 到 peers 在 初始 化 时 专 
门 添加 了 一 个 nul1， 对 应 的 是 Zygote Server Socket 这 个 “监听 者 ” 


e index >0 


此 时 说 明 已 经 建立 的 Socket 连 接 中 有 来 自 客户 端的 数据 需要 处 理 ， 
完成 具体 工作 的 是 run0nce， 下 面 我 们 详细 分 析 一 下 这 个 函数 : 


/*frameworks/base/core/java/com/android/internal/os/ZygoteConne 
boolean runOnce() throws ZygoteInit.MethodAndArgsCaller { 
String args[]; 
Arguments parsedArgs = null; 
FileDescriptor[] descriptors; 


try{.. 
checkTime(startTime, "zygoteConnection.runOnce: preFo 
pid = Zygote.forkAndSpecialize(parsedArgs.uid, parsed. 


parsedArgs.gids, parsedArgs.de 
parsedArgs.mountExternal, parsedA 
parsedArgs.niceName, fdsToClose, parsedArgs.ins 
parsedArgs.appDataDir); 
checkTime(startTime, "zygoteConnection.runOnce: postF 


} catch (IOException ex) { 

logAndPrintError(newStderr, "Exception creating pipe" 
} catch (ErrnoException ex) { 

logAndPrintError(newStderr, "Exception creating pipe" 
} catch (IllegalArgumentException ex) { 

logAndPrintError(newStderr, "Invalid zygote arguments 
} catch (ZygoteSecurityException ex) { 

logAndPrintError(newStderr, 

"Zygote security policy prevents request: ", 

} 
try { 

if (pid == 0) { 

// in child 


IoUtils.closeQuietly(serverPipeFd) ; 
serverPipeFd = null; 
handleChildProc(parsedArgs, descriptors, childPip 
return true; 
} else { 
IoUtils.closeQuietly(childPipeFd) ; 
childPipeFd = null; 
return handleParentProc(pid, descriptors, serverP 


} 

} finally { 
IoUtils.closeQuietly(childPipeFd) ; 
IoUtils.closeQuietly(serverPipeFd) ; 
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这 个 函数 比较 长 ， 其 中 有 两 个 地 方 需要 我 们 重点 关注 : 
。 创建 承载 应 用 程序 的 新 进程 


这 是 在 意料 之 中 的 ，zygote 需 要 为 每 个 新 启动 的 应 用 程序 生成 自己 
独立 的 进程 。 不 过 run0nce 中 并 没有 直接 使 用 fork 来 完成 这 一 工作 ， 而 
是 调用 了 forkAndSpecialize， 我 们 稍 后 会 分 析 这 个 函数 的 实现 。 另 
外 ， 新 创建 的 进程 中 一 定 需要 运行 应 用 程序 本 身 的 代码 ， 这 一 部 分 工作 
是 在 hand1eChi1dProc 中 展开 的 。 


。 父 进程 的 “扫尾 ”工作 





执行 完 上 述 的 任务 后 ， 父 进程 还 需要 做 一 些 清 尾 工作 才 算 “大 功 告 


a o BA: 将 子 进程 加 入 进程 组 ; 正确 关闭 文件 ; 调用 方 返回 结果 值 


Specialize 的 字面 意思 是 “专门 化 ”， 表 达 了 forkAndSpecialize 
在 “ 旷 化 ”的 同时 也 把 它 转 变 为 Android 应 用 程序 的 目标 。 函 数 
forkAndSpecial iize 的 处 理 分 为 3 个 阶段 ， 即 preFork、 
nativeForkAndSpecialize 以 及 postForkCommon: 


/*frameworks/base/core/java/com/android/internal/os/Zygote. java*/ 
public static int forkAndSpecialize(int uid, int gid, int[] gids, 
int[][] rlimits, int mountExternal, String seInfo, String 
int[] fdsToClose, String instructionSet, String appDataDi 
long startTime = SystemClock.elapsedRealtime(); 
VM_HOOKS.preFork(); 
checkTime(startTime, "Zygote.preFork"); 
int pid = nativeForkAndSpecialize( 
uid, gid, gids, debugFlags, rlimits, mountExternal, 
fdsToClose, instructionSet, appDataDir); 
checkTime(startTime, "Zygote.nativeForkAndSpecialize" ); 
VM_HOOKS.postForkCommon( ) ; 
checkTime(startTime, "Zygote.postForkCommon") ; 
return pid; 


中 间 过 程 限 于 篇 幅 我 们 不 去 深究 ， 接 下 来 直接 分 析 preFork 在 
Zygote 中 对 应 的 实现 : 


/*art/runtime/native/dalvik_system_ZygoteHooks.cc*/ 

static jlong ZygoteHooks_nativePreFork(JNIEnv* env, jclass) { 
Runtime* runtime = Runtime::Current(); 
CHECK(runtime->IsZygote()) << "runtime instance not started wit 
runtime->PreZygoteFork(); 
// Grab thread before fork potentially makes Thread: :pthread_ke 
Thread* self = Thread::Current(); 
return reinterpret_cast<jlong>(self); 


这 里 的 Runtime 实 例 具 体 而 言 指 的 是 Zygote 进 程 中 的 运行 环境 ， 我 
们 在 本 书 虚 拟 机 章节 中 会 有 详细 分 析 。 而 runt ime 一 PreZygoteFork 又 会 
间接 调用 Heap : :PreZygoteFork， 从 而 完成 堆 空间 的 初始 操作 。 


负数 nativeForkAndSpecialize 是 一 个 native 方 法 ， 具 体 对 应 的 实 
现 是 com_android_internal os Zygote nativeForkAndSpecialize,， 后 
者 则 又 进一步 调用 了 ForkAnd Special izeCommon: 


/*frameworks/base/core/jni/com_android_internal_os_Zygote.cpp*/ 
static pid_t ForkAndSpecializeCommon(JNIEnv* env, uid_t uid, gid_ 
jintArray javaGids, 
jint debug_flags, jobjectArr 
jlong permittedCapabilities, 
jlong effectiveCapabilities, 
jint mount_external, 
jstring java_se_info, jstrin 
bool is_system_server, jintA 
jstring instructionSet, jstr 
uint64_t start = MsTime(); 
SetSigChldHandler(); 
ckTime(start, "ForkAndSpecializeCommon:SetSigChldHandler") ; 


pid_t pid = fork();//iX #7 BIER HA PEE 
if (pid == 0) {...// 子 进程 中 


env->CallStaticVoidMethod(gZygoteClass, gCallPostForkChildHoo 
is_system_server ? NULL : instructi 


} else if (pid > 0) { 
// 父 进程 ， 这 里 什么 也 不 做 ， 因 为 run0nce 中 有 处 理 
} 


return pid; 

















XP MAES fork—THIAE, FEpid==0IK—-AMPAMRICHN 
进程 完成 一 系列 初始 化 操作 ， 而 后 执行 Cal |StaticVoidMethod. HA 
gZygoteClass 对 应 的 是 “com/android/internal/os/Zygote”， 而 
gCal |PostForkChi 1dHooks 则 是 Zygote 这 个 类 中 的 成 员 函 数 
cal1PostForkChi1dHooks 一 一 从 名 称 可 以 看 出 用 于 执行 及 化 后 的 一 些 处 
理工 作 。ForkAndSpecializeCommon 也 还 没有 涉及 与 应 用 程序 相关 的 具 
体 业务 ， 这 部 分 工作 会 由 runOnce 中 的 hand1eChi 1dProc 来 完成 ， 核 心 代 
码 如 下 : 


/*frameworks/base/core/java/com/android/internal/os/ZygoteConnect 

private void handleChildProc(Arguments parsedArgs, 
FileDescriptor[] descriptors, FileDescriptor pipeFd, Pri 
throws ZygoteInit.MethodAndArgsCaller 4.. 








if (parsedArgs.niceName != null) {// 子 进程 的 别名 
Process.setArgV0O(parsedArgs.niceName) ; 


l 


if (parsedArgs.runtimeInit) 4... 
} else {// 应 用 程序 的 ActivityThread 将 在 这 里 被 执行 
String className; 


try { 
className = parsedArgs.remainingArgs[0];// 实 际 对 应 的 大 


} catch (ArrayIndexOutOfBoundsException ex) { 
logAndPrintError(newStderr, 
"Missing required class name argument", null 
return; 


} 


String[] mainArgs = new String[parsedArgs.remainingArgs 


System.arraycopy(parsedArgs.remainingArgs, 1, 
mainArgs, 0, mainArgs.length);//className + KI: 


if (parsedArgs.invokewith != null) {...//invoke-with 的 情况 
} else { 
ClassLoader cloader; 
if (parsedArgs.classpath != null) { 
cloader = new PathClassLoader(parsedArgs.classp 
ClassLoader .getSystemClassLoader()); 





} else { 
cloader = ClassLoader.getSystemClassLoader(); 
} 


try {V// 执 行 main 函 数 
ZygoteInit.invokeStaticMain(cloader, className, 
} catch (RuntimeException ex) { 
logAndPrintError(newStderr, "Error starting.", 
} 


这 个 函数 的 任务 用 一 句 话 来 概况 ， 就 是 找到 并 执行 目标 进程 的 入 口 
函数 。Android 系 统 中 所 有 应 用 程序 理论 上 都 是 由 Zygote 启 动 的 ; MA 
从 本 小 节 的 分 析 中 ， 我 们 不 难 发 现 Zygote 会 为 新 启动 的 应 用 程序 fork 一 
个 进程 。 不 过 和 传统 的 内 核 中 的 fork+exec 的 作法 不 同 的 地 方 是 ， 
Zygote 中 并 不 会 执行 exec () 。 这 在 le ee 比如 
无 法 使 用 valgr ind 来 监测 程序 的 内 存 泄露 情况 。 为 了 响应 开发 人 员 的 类 
似 需求 ，Android 系 统 特别 提供 了 一 mn 并 通过 


parsedArgs. invokeWith 来 加 以 控制 。 有 兴趣 的 读者 可 以 自行 搜索 相关 
资料 了 解 其 中 的 详情 。 


在 handleChi 1dProc 这 个 函数 中 ， 最 重要 的 参数 之 一 是 className。 
可 以 看 到 ，handleChi1dProc 会 把 className 对 应 的 类 加 载 到 内 存 中 ， 然 
后 执行 其 中 的 main 函 数 。 那 么 这 个 className 具 体 是 指 什么 呢 ? 


要 回答 这 个 问题 并 不 是 件 容 易 的 事 ， 需 要 大 家 对 应 用 程序 的 局 动 流 
程 有 一 个 全 局 的 认识 。 本 书 的 其 他 章节 对 此 有 详细 介绍 ， 有 需要 的 读者 
可 以 穿插 阅读 。 我 们 这 里 假设 当前 流程 已 经 到 了 
ActivityManagerService， 它 会 向 Zygote 发 起 一 个 创建 新 进程 的 请 求 ， 
如 下 所 示 : 


/*frameworks/base/services/core/java/com/android/server/am/Activi 

private final void startProcessLocked(ProcessRecord app, String 
String hostingNameStr, String abiOverride, String entry 
String[] entryPointArgs) 4.. 

Process.ProcessStartResult startResult = Process.start(entryPo 
app.processName, uid, uid, gids, debugFlags, mou 
app.info.targetSdkVersion, app.info.seinfo, 
requiredAbi, instructionSet, 

app.info,dataDir，entryPointArgs);// 这 些 参数 将 被 转化 为 


Process 的 字面 意思 虽然 是 进程 ， 但 其 实 它 只 属于 “进程 类 ”， 或 
者 称 为 “进程 管家 ”会 贴切 些 。Process. start 显 然 是 去 启动 一 个 新 的 
进程 以 承载 业务 ， 而 函数 的 第 一 个 参数 entryPoint， 即 我 们 在 
handleChi1dProc 中 看 到 的 className。 这 是 因为 
ActivityManagerService 传 递 过 来 的 字符 串 形 式 的 参数 列表 会 被 
Arguments. parseArgs 解 析 成 Arguments 中 的 各 成 员 变 量 ， 比 如 表 7-4 所 
/小 。 






参数 格式 





"--setuid=" 


Bn | gid 


"--target-sdk-version=" targetSdkVersion 


"--runtime-init" runtimelnit 
"-classpath" classpath 
"--nice-name=" nicename 


剩余 的 参数 











className 对 应 的 是 表 7-1 中 的 remainingArgs[0]。 


现在 问题 转化 为 ，ActivityManagerService 中 的 entryPoint 是 如 何 
得 来 的 呢 ? 它 的 来 源 简 单 来 讲 就 是 下 面 这 个 语句 : 
if (entryPoint == null) entryPoint = "android.app.ActivityThread" 
换 句 话说 ，Zygote 中 主动 执行 的 类 是 ActivityThread， 这 同时 也 是 
我 们 熟知 的 Android 应 用 程序 的 “主线 程 ” : 
/*frameworks/base/core/java/android/app/ActivityThread. java*/ 
public static void main(String[] args) 4.. 


Looper .prepareMainLooper (); 


ActivityThread thread = new ActivityThread(); 
thread.attach(false); 


if (sMainThreadHandler == null) { 
sMainThreadHandler = thread.getHandler(); 
} 


AsyncTask.init(); 


Looper.loop(); 


throw new RuntimeException("Main thread loop unexpectedly 


} 


上 述 的 代码 段 我 们 在 A A 只 章节 已 经 接触 过 了 ， 这 
里 再 一 次 列 出 来 ， 以 便 大 家 可 以 把 各 知识 点 “串联 ”起 来 。 


到 目前 为 止 ， 我 们 已 经 分 析 了 Zygote 作 为 守护 进程 时 ， 如 何 为 
Android 应 用 程序 的 启动 而 服务 的 。 在 本 小 节 剩 余 的 内 容 中 ， 大 家 将 学 
习 到 它 男 一 方面 的 工作 ， 即 引导 系统 各 重要 服务 的 启动 过 程 。 


从 前 面 的 分 析 可 以 知道 ，System Server 的 启动 是 在 
startSystemServer 中 完成 的 。 Zygote 首 先 会 利用 
Zygote. forkSystemServer 来 哼 化 出 一 个 子 进程 ， 然 后 在 pid==0 的 分 支 
中 调用 handleSystem ServerProcess， 后 者 在 国 数 的 末尾 又 会 进一步 调 
用 Runtimelnit. zygotelnit: 


/*frameworks/base/core/java/com/android/internal/os/RuntimeInit.j 
public static final void zygoteInit(int targetSdkVersion, String[ 
ClassLoader classLoader) throws ZygoteInit.MethodAndArgsCaller 4... 
commonInit(); 
nativeZygoteInit(); 


applicationInit(targetSdkVersion, argv, classLoader); 


贡 数 zygotelnit 通 过 3 个 方面 来 完成 初始 化 ， 分 别 是 


e commonlnit 


通用 部 分 的 初始 化 ， 包 括 设置 默认 的 uncaught exception 
handler (具体 对 应 的 是 Runtime1nit 中 的 UncaughtHandler 类 ) ;为 
HttpURLConnect ion 准 备 好 默认 的 HTTP User-Agent (User Agent 包 含 了 
与 系统 浏览 器 相关 的 一 系列 信息 ， 如 “Dalvik/1.1.0 (Linux; U; 
Android Eclair Bui1d/MASTER) ”. ) ;开启 trace 模 式 (只 在 emulator 下 
才 有 必要 ) 等 。 


e nativeZygotelnit 


一 个 本 地 初始 化 函数 ， 也 是 zygotelnit 中 的 重点 ， 我 们 稍 后 做 


e applicationInit 


这 个 水 数 的 声明 为 : private static void applicationInit (int 
targetSdkVersion, String[] argv, Class Loader classLoader) ;从 
中 可 以 看 出 它 是 程序 运行 的 “起 点 ”。 在 我 们 这 个 场景 中 ， 程 序 指 的 是 
System Servers, Mm “AQ” 是 什么 呢 ? 这 就 和 第 二 个 参数 argv 有 关 
系 。 这 个 String[] 实际 上 包含 了 两 个 重要 的 成 员 变 量 ， aeaa 
startArgs。 而 这 两 个 变量 的 赋值 可 以 追溯 到 startSystemServer 中 ， 具 
体 代 码 如 下 : 


String args[] = { 
"--setuid=1000", 
"--setgid=1000", 
"--setgroups=1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 

1009, 1010, 1018, 1032, 3001, 3002, 3003, 3006, 3007", 

"--capabilities="_+ capabilities + "," + capabilities 
"--runtime-init", 
"--nice-name=system_server", 
"com.android.server.SystemServer", 


ti 
换 句 话说 ，startClass 对 应 的 就 是 


com. android. server. SystemServer 。 因 而 applicationlnit 最 终 将 调用 
main@SystemServer : 


public static void main(String[] args) { 
new SystemServer().run(); 
} 


经 过 上 面 的 初始 化 后 ， 程 序 现在 会 有 两 个 分 支 ， 其 一 
nativeZygotelnit 主 导 的 本 地 系统 服务 的 局 动 ; 另 一 me 
applicationlnit 负 责 的 Java 层 系统 服务 的 启动 。 


(1) 本 地 系统 服务 的 局 动 


在 JNI 机 制 中 ，Nat ive 函 数 在 Java 层 会 有 一 个 声明 ， 然 后 在 本 地 技 
得 到 真正 的 实现 。 那 么 当 我 们 调用 了 Java 层 的 函数 后 ， 系 统 是 如 何 找到 
Native 中 与 之 对 应 的 函数 的 呢 ? 通常 情况 下 ，Native 中 的 C++ 文件 命名 
是 以 Java 层 的 package 为 基础 的 ， 如 Java 层 的 包 名 为 


com. android. internal. XX， 那 么 其 对 应 的 JNI 层 文件 则 是 
com_android_internal_XX。 不 过 这 种 对 应 关系 并 不 是 绝对 不 变 的 ， 可 
以 根据 开发 人 员 的 需求 进行 调整 。 辟 如 我 们 上 面 的 Zygotelnit 所 在 的 
Java 包 是 com. android. internal. os， 而 实际 上 JN1 的 实现 则 为 
AndroidRuntime. cpp。 开 发 人 员 一 定 要 学 会 这 其 中 的 规则 ， 才 能 快速 找 
到 自己 所 需 的 资源 。 


AndroidRuntime 表 明 这 个 class 的 任务 是 “负责 Android 的 运行 时 环 
境 ”。 当 我 们 调用 了 nativeZygotelnit 后 ， 实 际 上 是 执行 了 
com android internal os Runtimelnit nativeZygotelnit@ 
AndroidRuntime. cpp， 如 下 所 示 : 


static void com android internal os_ RuntimeInit_nativeZygoteInit( 


gCurRuntime->onZygoteInit(); 


全 局 变量 gCurRunt ime 是 一 个 AndroidRunt ime 的 对 象 ， 结 合 本 节 前 
面 内 容 的 学 习 ， 大 家 应 该 能 想到 实际 上 AndroidRunt ime 是 一 个 父 类 ， 真 
正 的 实现 则 在 App_main. cpp 中 的 AppRuntime。 当 我 们 新 建 AppRunt ime X} 
象 时 ， 它 的 父 类 的 构造 函数 会 被 调用 ， 并 为 gCurRunt ime 赋 值 。 上 述 的 
onZygotelnit 也 在 这 个 App_main. cpp 文 件 中 ， 如 下 所 示 : 


/*frameworks/base/cmds/app_process/App_main.cpp*/ 
virtual void onZygoteInit() 


{... 
sp<ProcessState> proc = ProcessState::self(); 
ALOGV( "App process: starting thread pool.\n"); 
proc->startThreadPool(); 

} 


上 面 这 段 代 码 是 Binder 机 制 中 的 重要 组 成 部 分 ， 其 中 
startThreadPool 将 开局 Binder 线 程 池 以 保证 其 他 进程 可 以 正确 访问 到 
Zygote 所 提供 的 服务 。Zygote 通 过 JN1 和 回调 的 方式 非常 巧妙 地 把 本 地 
层 和 Java 层 、SystemServer 和 app process 关 联 起 来 了 。 

关于 Binder 的 更 多 信息 ， 请 大 家 参考 本 书 相 关 章 节 的 详细 分 析 。 

(2) Java 层 系统 服务 的 启动 


Java 层 的 系统 服务 比较 多 ， 它 们 各 司 其 职 ， 缺 一 不 可 。 我 们 知道 ， 


Zygote 会 为 System Server 的 运行 启动 和 初始 化 虚拟 机 ， ee 
main@SystemServer. java 开启“ 系统 服务 之 旅 ”。 不 过 main 函 数 只 

到 “ 门 ” 的 作用 ， 它 又 会 直接 调用 SystemServer 0. run(), 后 者 才 是 真 
正 实现 服务 的 地 方 : 


/*frameworks/base/services/java/com/android/server/SystemServer , j 
private void run() {.. 
SystemProperties.set("persist.sys.dalvik.vm.1ib.2", 
VMRuntime.getRuntime().vmLibrary()); 


android.os.Process.setThreadPriority( 
android.os.Process.THREAD_PRIORITY_FOREGROUND) ; 

android.os.Process.setCanSelfBackground( false) ; 

Looper .prepareMainLooper();// 准 备 主 循环 体 


// Initialize native services. 
System.loadLibrary("android_servers");// 加 载 本 地 服务 库 
nativeInit();// 本 地 服务 初始 化 


// Initialize the system context. 
createSystemContext(); 


// Create the system service manager. 
mSystemServiceManager = new SystemServiceManager (mSystemC 
LocalServices.addService(SystemServiceManager.class, mSys 


// Start services. 
try { 
startBootstrapServices(); 
startCoreServices(); 
start0OtherServices();// 分 别 启动 各 种 类 型 的 System Server 
} catch (Throwable ex) 4.. 
} 


Looper .100p();// 进 入 死 循环 ， 直 到 设备 关机 
throw new RuntimeException("Main thread loop unexpectedly 


} 


System Server 在 启动 前 首先 需 5 要 做 很 多 初始 化 i 入 置 ， 包 括 将 VM 的 
版 本 记录 到 系统 变量 中 ， 人 设置 堆 的 使 用 率 等 。 我 们 知 
道 ，Android 系 统 服务 会 被 分 为 两 类 ， 一 是 Java 层 的 ， 其 二 是 本 地 层 
的 。 后 者 具体 是 由 System. Re android_servers") 实现 的 ， 
而 Java 层 的 服务 将 在 下 一 小 节 做 重点 分 析 。 


通过 以 上 讲解 ， 我 们 可 以 看 到 app_process 就 是 系统 服务 的 “根据 
地 ”。 它 在 init 进 程 的 帮助 下 ， 通 过 Zygote 逐 步 建 立 起 各 SystemServer 
的 运行 环境 ， 继 而 为 上 层 的 “繁殖 壮大 ”提供 “土壤 环境 ”。 
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全 图 7-1 ZygoteFeSystem Server 的 启动 流程 
7.2.3 Android 的 “系统 服务 ”一 -一 SystemServer 


SystemServer 是 Android 进 入 Launcher 前 的 最 后 准备 。 由 其 名 称 就 
可 看 出 ， 它 提供 了 众多 由 Java 语 言 编写 的 “系统 服务 ”。 


由 上 一 小 节 的 学 习 可 知 ， 一 旦 我 们 在 init. rc 中 为 Zygote 指 定 了 启 
动人 参数 --start-system-server， 那 么 Zygotelnit 就 会 调用 
startSystemServer 来 进入 SystemServer 。 而 且 系 统 服务 又 分 别 分 为 
Java 层 和 本 地 层 两 类 。 其 中 Nat ive 层 服务 的 实现 体 在 android servers 
中 ， 需 要 在 run@SystemServer 中 首先 通过 
System. loadLibrary ("android servers") 加 载 到 内 存 中 才能 使 用 。 而 
nativelnit 则 负责 为 启动 本 地 层 服务 而 努力 。 这 部 分 实现 在 Android 的 
历 版 变迁 中 改动 不 小 ， 特 别 是 对 两 类 系统 服务 的 管辖 范围 有 不 小 差异 。 
以 最 新 的 Android 版 本 而 言 ， 它 实际 上 在 本 地 层 只 留 下 Sensor 服 务 了 : 


/*frameworks/base/services/core/jni/com_android_server_SystemServ 
static void android_server_SystemServer_nativeInit(JNIEnv* env, j 
char propBuf [PROPERTY_VALUE_MAX]; 
property_get("system_init.startsensorservice", propBuf, "1"); 
if (strcmp(propBuf, "1") == 0) { 
// Start the sensor service 
SensorService: :instantiate()j; 


} 


上 述 代 码 段 用 于 SensorService 的 启动 和 初始 化 。Android 系 统 中 的 
Sensor 可 以 理解 为 比较 小 的 硬件 器 件 ， 如 光线 、 陀 螺 仪 、 重 力 感 应 等 。 
它们 在 属性 特征 上 相对 一 致 ， 而 在 数据 量 上 则 普遍 不 大 。 传 统 的 
Android 模 拟 器 对 其 中 一 些 Sensor 实 现 了 简单 的 模拟 ， 功 能 有 限 。 市 面 
上 也 有 一 些 厂商 为 了 便于 开发 者 调 测 应 用 程序 ， 推 出 了 专门 的 器 件 模 拟 
oe T “无 缝 集成 ”。 大 家 有 兴趣 的 话 可 以 自行 上 网 

索 了 解 。 


我 们 再 回 到 Java 层 来 看 一 下 这 类 系统 服务 是 如 何 管理 的 。 从 代码 中 
可 以 看 到 ， 这 部 分 Server 又 可 细 分 为 3 类 ， 如 下 所 示 : 


e Bootstrap Services 


BootStrap 的 原意 是 “引导 程序 ”， 用 在 这 里 则 代表 系统 服务 中 最 
核心 的 那 一 部 分 。 另 外 ， 这 些 Services 间 相互 的 依赖 关系 比较 强 ， 因 而 
需要 在 一 起 统一 管理 启动 ， 具 体 对 应 的 是 startBootstrapServices 这 个 
浮 数 。 按 照 Android 的 建议 ， 如 果 你 自己 添加 的 系统 服务 和 它们 也 有 较 
强 的 依赖 ， 那 么 可 以 与 这 类 系统 服务 统一 放置 ， 否 则 就 应 该 考虑 下 面 所 
述 的 另 两 类 服务 : 


/*frameworks/base/services/java/com/android/server/SystemServer . j 
private void startBootstrapServices() { 
mInstaller = mSystemServiceManager.startService(Installer 
mActivityManagerService = mSystemServiceManager.startServ 
ActivityManagerService.Lifecycle.class).getServic 
mActivityManagerService.setSystemServiceManager (mSystemSe 
mPowerManagerService = mSystemServiceManager.startService 
mActivityManagerService. initPowerManagement(); 
mDisplayManagerService = mSystemServiceManager.startServi 
mSystemServiceManager .startBootPhase(SystemService.PHASE 


// Only run "core" apps if we're encrypting the device. 
String cryptState = SystemProperties.get("vold.decrypt"); 
if (ENCRYPTING_STATE.equals(cryptState)) { 
Slog.w(TAG, "Detected encryption in progress - only p 
mOnlyCore = true; 
} else if (ENCRYPTED_STATE.equals(cryptState)) { 
Slog.w(TAG, "Device encrypted - only parsing core app 
mOnlyCore = true; 


} 


// Start the package manager. 

Slog.i(TAG, "Package Manager"); 

mPackageManagerService = PackageManagerService.main(mSyst 
mFactoryTestMode != FactoryTest.FACTORY_TEST_OFF, 

mFirstBoot = mPackageManagerService.isFirstBoot(); 

mPackageManager = mSystemContext.getPackageManager (); 


Slog.i(TAG, "User Service"); 
ServiceManager .addService(Context.USER_SERVICE, UserManag 


// Initialize attribute cache used to cache resources fro 
AttributeCache.init(mSystemContext); 


// Set up the Application instance for the system process 
mActivityManagerService.setSystemProcess(); 


ARMREST, EVRA RSA 
mSystemServiceManager. startService。 这 和 旧版 本 Android 系 统 中 服 
务 “ 各 自 为 政 ” 的 做 法 有 不 小 差异 ， 换 名 话说， 目前 所 有 System 
Serv i ce 都 统一 由 SystemServiceManager 来 管理 。 


System Service Manager 首 先 会 启动 Installer， 这 是 为 了 让 
Installer 可 以 优先 完成 初始 化 ， 并 完成 关键 目录 〈 如 /data/user) 的 
创建 。 这 些 都 是 其 他 服务 可 以 顺利 启动 的 先决 条 件 。 接 下 来 局 动 的 系统 
服务 是 ActivityManagerService， 我 们 在 其 他 章节 会 做 专门 的 分 析 ， 这 
BARBIA. 


在 AMS 之 后 相继 启动 的 服务 包括 电源 管理 Power Manager, Display 
Manager 、PackageManager 等 ， 最 后 调用 setSystemProcess 来 添加 进程 
相关 的 服务 ， 如 meminfo、gfxinfo、dbinfo、cpuinfo 等 ， 从 而 完成 最 
核心 部 分 系统 服务 的 启动 。 


e Cote Services 


Core Service 相 对 于 BootStrap 的 优先 级 略 低 ， 主 要 包括 LED 和 背光 
管理 器 、 电 池 电 量 管理 器 、 应 用 程序 使 用 情况 (Usage Status) SHEA 


o 


dÈ 


e Other Services 


这 部 分 服务 在 3 类 Servi ce 中 优先 级 最 低 ， 但 数量 却 最 多 。 比 如 
AccountManagerService, VibratorService, MountService, 
NetworkManagementService, NetworkStatsService, 
ConnectivityService, WindowManagerService, UsbService, 
SerialService、AudioService 等 。 这 些 服 务 全 面 构 筑 起 Android 系 统 这 
座 “ 人 参天 大 厦 ”， 为 其 他 进程 、 应 用 程序 的 正常 运行 商定 了 基础 。 


最 后 ，SystemServer 通 过 Looper. loop O 进入 长 循环 中 ， 并 依托 
onZygotelnit 中 局 动 的 Binder 服 务 接 受 和 处 理 外 呐 的 请 求 一 一 Android 
系统 的 “万 里 长 征 ” 终 于 开始 了 。 

7.2.4 Vold 和 External Storage 存 储 设备 


和 i0S 不 同 的 是 ，Android 系 统 支 持 多 种 存储 设备 ， 包 括 外 置 的 


SDCARD、U 盘 等 。 这 些 存储 设备 的 管理 机 制 在 不 同 的 Android 版 本 中 差异 
很 大 ， 我 们 将 在 本 小 节 做 一 个 简单 的 介绍 。 


Android 系 统 中 的 内 /外 存储 设备 定义 如 下 : 
e Internal Storage 
按照 Android 的 设计 理念 ，lnternal Storage 代 表 的 是 /data 存 储 目 
录 。 所 以 目前 不 少 文件 管理 器 事实 上 混淆 了 Internal Storage 的 概念 ， 
请 大 家 特别 注意 。 


e External Storage 


所 有 除 Internal Storage 之 外 的 可 存储 区 域 ， 参 见 下 面 的 详细 描 


Ss 


从 物理 设备 的 角度 来 看 ，External Storage 由 如 下 几 种 类 型 组 成 : 


e Emulated Storage 


Android 设 备 中 存在 的 一 个 典型 做 法 ， 是 从 Internal Storage (44 
Flash) 中 划分 一 定 的 区 域 (如 1GB) 来 作为 外 部 存储 设备 ， 称 为 
Emulated Storage 


e SDCARD/USB Devices 


通过 扩展 卡 模 或 者 USB 端 口 来 扩展 设备 的 存储 能 力 ， 也 是 Android 设 
备 中 的 常见 情况 


另外 在 某 些 场合 ，Android 6. 0 之 前 的 External Storage 会 被 称 为 
Traditional Storage， 从 这 个 角度 看 它 又 可 以 细 分 成 emulated 和 
portable _ storage 两 个 类 型 。Portab le 顾名思义 就 是 指 那些 没有 和 系统 
绑 定 在 一 起 的 ， 可 以 随时 移 除 的 设备 。 正 是 由 于 这 类 设备 的 “暂时 性 和 

不 稳定 性 ”， 它 们 并 不 适合 用 于 存储 一 些 敏感 数据 ， 例 如 系统 代码 、 应 
用 程序 数据 等 。 Android 6. 0 则 引入 了 一 种 叫做 “Adoptable 
A 的 存储 概念 ， 简 单 来 说 就 是 让 外 部 设备 可 以 像 内 部 设备 一 样 
被 处 理 。 


为 了 达到 上 述 的 效果 ， 被 “adopted” 的 存储 设备 需要 格式 化 并 经 
过 加 密 过 程 ， 以 保证 数据 的 安全 性 。 当 然 ， 系 统 会 在 用 户 插入 新 的 外 部 
设备 时 首先 询问 是 否 要 把 它 变 为 adoptable storage。 如 果 答 案 是 肯定 
的 才 会 执行 这 些 处 理 ; 否则 还 是 把 它 当 成 普通 的 存储 设备 ， 如 图 7-2 所 
7J“ o 


Set up your Virtual SD 
card 





© Use as portable storage 


For moving photos and other 
media between devices. 


© Use as internal storage 
For storing anything on this 
device only, including apps and 
photos. Requires formatting that 





全 图 7-2 存储 设备 


Android 系 统 中 的 外 部 存储 设备 由 Vold 和 Mount Service 来 统一 管 
理 。 其 中 Vold 对 应 的 源码 路 径 是 : A0SP/system/vold。 它 是 通过 
init. rc 启动 的 ， 如 下 所 示 : 


on post-fs-data 


start vold 


值得 一 提 的 是 FUSE services 也 不 再 放 在 init. rc 中 统一 加 载 ， 而 改 
由 vo1d 根 据 具 体 情 况 来 动态 决定 是 否 需要 启动 。 


Vold 在 启动 以 后 ， 会 通过 NETLINK 和 内 核 取得 联系 ， 并 根据 后 者 提 
供 的 event 来 构建 存储 设备 管理 系统 。 和 以 往 版 本 不 同 的 是 ，Vo1d 的 配 
置 文件 不 再 是 vold. fstab， 而 变 成 了 /fstab. 《ro. hardware>。 例 如 
AOSP/device/fugu/fstab. fugu: 


/dev/block/by-name/system /systenm ext4 ro,noatime Wait 
/dev/block/by-name/cache /cache ext4 nosuid,nodev,noatime, barrier=1, data=ordered wait, check 
/dev/block/by-name/userdata /data ext4  nosuid,nodev, noatime, discard, barrier=1,data=ordered, noauto da alloc wait, check 
/dev/block/by-name/factory /factory ext4  nosuid,nodev,noatime, barrier=1,data=ordered wait 
/dev/block/by-name/misc /misc emmc defaults defaults 

/dev/block/zram0 none swap defaults zramsize=104857600 
/devices/*/dwc3-host.2/usb* auto auto defaults voldmanaged=usb: auto, encryptable=userdata 


Android 6. 0 及 以 后 版 本 中 ， 根 据 设 备 具体 情况 不 同 主 要 有 如 下 几 
种 典型 配置 : 


(1) Emulated primary only 


即 只 有 Emulated Storage 的 情况 ， 此 时 fstab. device 的 配置 范例 如 
下 : 


/devices/*/xhci-hcd.0.auto/usb* auto auto defaults 
voldmanaged=usb: auto 


(2) Physical primary only 


即 只 有 一 个 外 置物 理 存 储 设备 的 情况 ， 此 时 fstab. devi ce 的 配置 范 
例如 下 : 


/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults 
voldmanaged=sdcard0: auto, encryptable=userdata, noemulatedsd 


(3) Emulated primary, physical secondary 


有 两 个 外 置 的 物理 存储 设备 ， 它 们 会 被 分 别 设 定 为 pr imary 和 
secondary， 此 时 fstab. device 的 配置 范例 如 下 : 


/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults 
voldmanaged=sdcard1: auto, encryptable=userdata 


fstab 的 语法 规则 如 下 : 


<src> <mnt_point> <type> <mnt_flags> <fs_mgr_flags> 
src: 在 sysfs 文 件 系统 下 用 于 描述 设备 的 节点 的 路 径 。 
mnt_point: 设备 挂 载 点 。 
type: 文件 系统 类 型 。 
mnt flags: 最 新 版 本 的 vo1d 会 忽略 这 一 项 。 


fs mer flags: 对 于 没有 包含 “voldmanaged=” 的 一 律 会 被 忽略 ， 
换 句 话说 “voldManaged” 表 示 的 是 它 可 以 被 vo1d 管 理 。 


Vol1d 在 启动 过 程 中 会 通过 process_config 国 数 来 处 理 fstab 配 置 文 

件 ， 并 把 它们 存储 在 VolumeManager 的 全 局 变量 中 。 后 续 当 收 到 内 核 的 

Netl inkEvent (add) 时 ，VolumeManager 有 再 在 handleBlockEvent 中 根据 

规则 判断 本 次 事件 是 否 和 之 前 记录 的 fstab 配 置 相 匹 配 一 一 如 果 答 案 是 

肯定 的 话 ， 则 新 创建 一 个 Disk 对 象 来 管理 ， 并 将 它们 统一 添加 到 mDi sks 
中 ， 如 图 7-3 所 示 。 
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全 图 7-3 Vold 框 架 简 图 


我 们 不 难 发 现 ，Emulated Storage 所 需 的 存储 空间 来 源 于 设备 的 
data 分 区 。 换 句 话 说 ，Emulated Storage 的 存储 空间 和 data 分 区 是 共享 
存储 区 域 的 。Emulated Storage 当 然 也 是 由 Volume Manager 来 统一 管理 


的 ， 如 下 所 示 : 


/*system/vold/VolumeManager .cpp*/ 
int VolumeManager::start() {.. 
CHECK(mInternalEmulated == nullptr); 
mInternalEmulated = std::shared_ptr<android: :vold: :VolumeBase 
new android: :vold: :EmulatedVolume("/data/media" ) ); 
mInternalEmulated->create()j; 
return Q; 


VolumeManager : :start 会 被 vol1d 的 main 国 数 调 用 ， 因 而 从 Vol1d 的 角 
度 来 看 所 有 Android 设 备 都 是 带 有 Emulated Storage 的 ， 只 不 过 最 终 是 
否 需 要 执行 mount 操 作 则 由 MountService 来 决定 。 从 Emulatedyolume 构 
造 函数 的 参数 可 以 看 到 ， 它 在 data 分 区 中 对 应 的 路 径 是 /data/media。 
volumeManager 的 全 局 变量 mlnternalEmulated 用 于 记录 系统 的 Emulated 
Storage. 


接 下 来 mlnternalEmulated->create () 除了 给 Storage 创 建 运行 环境 
外 ， 还 会 向 MountService 发 送 一 个 VolumeCreated 的 消息 ， 并 将 自身 的 
状态 迁移 到 kUnmounted。MountService 收 到 这 一 信息 后 ， 会 根据 系统 的 
实际 情况 决定 是 否 挂 载 这 个 Storage 一 一 如 果 答 案 是 肯定 的 话 ， 那 么 它 
会 回应 一 个 mount 指 令 给 vo1d， 而 后 者 对 此 的 处 理 过 程 中 会 进一步 调用 
到 doMount 了 涵 数 一 一 这 个 了 水 数 最 关键 的 步骤 之 一 是 fork 一 个 新 进程 ， 用 
于 运行 /system/bin/sdcard。 





例如 domount@EmulatedVolume. cpp 中 的 如 下 代码 段 : 


if (!(mFusePid = fork())) { 
if (execl(kFusePath, kFusePath, 
"u", "1023", // AID_MEDIA_RW 
"-g", "1023", // AID_MEDIA_RW 
" -m", 
" -w", 
mRawPath.c_str(), 
label.c_str(), 
NULL)) { 
PLOG(ERROR) << "Failed to exec"; 


} 


LOG(ERROR) << "FUSE exiting"; 
_exit(1); 


变量 kFusePath 指 向 的 是 “/system/bin/sdcard”， 我 们 可 以 通过 
exec1 系 统 调用 将 其 启动 起 来 。Sdcard daemon 对 应 的 源 代码 目录 是 
AOSP/system/core/sdcard. 


Sdcard daemon 属 于 Fuse Service。Fuse 的 全 称 是 “Filesystem in 
Userspace”， 即 在 用 户 态 实现 的 一 种 Fi le System。 它 的 典型 框架 如 图 
7-4 所 示 。 
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全 图 7-4 框架 {-:-} (4] A Á Wikipedia) 


当 使 用 者 〈 左 半 部 分 ) 希望 访问 FUSE 文 件 系统 时 ， 这 一 请 求 会 经 过 
Kerne1 的 VFS 首 先 传递 给 FUSE 对 应 的 驱动 模块 ， 然 后 再 通知 到 用 户 层 的 
fuse 管 控 程 序 (例如 这 个 场景 中 的 sdcard) 。 后 者 处 理 请 求 完 成 后 会 将 
结果 数据 返回 给 最 初 的 调用 者 ， 从 而 完成 一 次 交互 过 程 。 可 见 与 传统 的 
文件 系统 相 比 ，FUSE 文 件 系 统 因 为 处 理 层次 较 多 ， 所 以 在 效率 上 注定 会 
存在 不 足 的 地 方 。 不 过 “下 不 掩 瑜 ”，FUSE 文 件 系 统 的 灵活 性 依然 为 其 
获得 了 广泛 的 应 用 。 


了 解 了 FUSE 文 件 系统 后 ， 我 们 再 来 看 sdcard daemon 是 怎么 做 的 。 
简单 来 说 它 会 执行 以 下 几 个 核心 操作 。 


e 将 /dev/fuse 挂 载 到 3 个 目标 路 径 下 


这 几 个 目标 路 径 分 别 
是 : /mnt/runtime/default/%s、/mnt/runtime/read/%s 
和 和 /mnt/runtime/write/%s， 其 中 “%s” 代 表 的 是 Volume 的 label， 在 
Emulated Storage 这 个 场景 下 对 应 的 是 “emulated”。 


© 创建 3 个 线程 


在 代码 中 对 应 的 是 thread default, thread read 和 
thread_write。 这 3 个 线程 启动 后 都 会 进入 for 死 循环 ， 然 后 不 停 地 从 自 
己 对 应 的 fuse->fd 〈 即 打开 /dev/fuse 产 生 的 文件 描述 符 ) 中 读 取 fuse 
模块 发 过 来 的 消息 命令 ， 并 根据 命令 的 具体 类 型 〈 例 如 FUSE_READ、 
FUSE WRITE、FUSE_0PEN 等 ) 执行 处 理 函 数 。 


为 什么 我 们 需要 将 /dev/fuse 挂 载 到 3 个 路 径 下 ， 并 通过 不 同 的 线程 
来 管理 呢 ? 这 和 Android 6. 0 中 引入 的 Runtime Permission 有 关系 。 


不 同 于 以 往 Install Time Permissions 〈 应 用 程序 所 需 的 权限 是 在 
安装 或 者 版 本 升级 过 程 中 赋予 的 ) 这 种 “一 刀 切 ”的 管理 方式 ， 
Runtime permission 人 允许 用 户 在 程序 运行 到 某 些 特别 功能 时 再 动态 决定 
是 否 赋予 程序 相应 的 权限 。 这 样 带 来 的 好 处 是 用 户 可 以 更 清楚 地 知道 应 
用 程序 需要 〈 或 者 已 经 授予 了 ) 哪些 权限 ， 以 实现 更 为 “透明 ”的 管 
理 。 不 过 Runtime Permission 只 对 那些 系统 认为 危险 的 权限 进行 保护 ， 


大 家 可 以 利用 如 下 命令 获取 详细 的 权限 列表 : 
adb shell pm list permissions -g -d 


下 面 是 某 Android 6. 0 设备 执行 上 述 命令 后 的 结果 截图 。 


group:android.permission—group.LOCATION 
permission-:android.permission.ACCESS_FINE_LOCATION 
permission:com.google.android.gms.permission.CAR_SPEED 
permission-:android.permission.ACCESS_COARSE_ LOCATION 


group:android. permiss ion—group.STORAGE 
permission-:android.permission.READ_EXTERNAL_STORAGE 
permission-:android.permission.WRITE_EXTERNAL_STORAGE 





从 图 中 可 以 看 到 读 写 外 置 存储 设备 的 权限 就 在 此 列 。 


从 开发 者 的 角度 来 看 ， 当 应 用 程序 运行 到 需要 Runtime Permission 
的 功能 时 〈 也 有 应 用 程序 在 启动 时 一 口气 申请 所 有 Runt ime 
Permission， 从 而 导致 很 不 好 的 用 户 体 验 ， 这 种 做 法 是 不 推荐 的 ) ， 手 
动 调用 相应 的 系统 AP1 进 行 权 限 申请 ， 此 时 会 弹出 类 似 于 下 面 的 对 话 框 
供用 户 选 择 ， 如 图 7-5 所 示 。 


如 果 用 户 拒绝 了 应 用 程序 的 权限 请 求 ， 并 且 勾 选 了 “Never ask 
again…”， 那 么 应 用 程序 下 次 再 申请 同一 权限 时 系统 将 直接 拒绝 。 这 
种 情况 下 应 用 程序 的 一 种 常见 处 理 方法 是 自行 弹出 一 个 提示 框 ， 疝 述 申 
请 此 权限 的 重要 性 ， 以 保证 用 户 可 以 被 充分 说 服 ， 并 手动 去 系统 设置 中 
进行 授权 操作 。 范 例如 图 7-6 所 示 。 


Access the SD card 


Files requires access to the following 
permission: Storage. Allow? 


Configure permissions from Settings > Manage 
apps > Permissions. 


(~) Never ask again after deny permission 


Restrict Always allow 


全 图 7-5 对话 框 


Prompt 


Files requires access to your photos, media 
files, and storage to provide data management 
services. Please enable these permissions from 
settings. 


Cancel Confirm 


全 图 7-6 进行 授权 操作 


可 见 Runtime Permission 权 限 管 理 方 式 的 一 种 很 重要 的 特性 就 是 要 
求 应 用 程序 的 权限 可 以 在 运行 过 程 中 进行 动态 调整 ， 而 且 不 能 导致 应 用 
程序 的 重启 。 这 其 中 就 涉及 Package Manager Service、Activity 
Manager Service、Zygote 等 多 个 系统 服务 ， 我 们 按照 顺序 逐一 曾 述 


首先 需要 关注 的 是 应 用 程序 启动 时 的 初始 化 权限 处 理 ， 此 时 AMS 在 
startProcessLocked 中 会 做 如 下 处 理 : 


/*frameworks/base/services/core/java/com/android/server/am/Activi 
private final void startProcessLocked(ProcessRecord app, String h 
String hostingNameStr, String abiOverride, String entryPoint 
try { 
checkTime(startTime, "startProcess: getting gids from 
final IPackageManager pm = AppGlobals.getPackageManag 
permGids = pm.getPackageGids(app.info.packageName, ap 
MountServiceInternal mountServiceInternal = LocalServ 
MountServiceInternal.class); 
mountExternal = mountServiceInternal.getExternalStora 
app.info.packageName) ; 
} catch (RemoteException e) { 
throw e.rethrowAsRuntimeException(); 


} 


Process.ProcessStartResult startResult = Process.start(ent 
app.processName, uid, uid, gids, debugFlags, mo 
app.info.targetSdkVersion, app.info.seinfo, req 
instructionSet, app.info.dataDir, entryPointArg 


我 们 需要 特别 注意 的 是 mountExternal 这 个 变量 的 赋值 过 程 ， 它 将 
为 后 续 Zygote 中 的 bind mount 提 供 参 考 。 从 上 面 的 代码 段 不 难看 出 ， 
mountExternal 是 由 MountService 提 供 的 ， 其 代码 实现 如 下 所 示 : 


public int getExternalStorageMountMode(int uid, String pa 
// No locking - CopyOnWriteArrayList 
int mountMode = Integer .MAX_VALUE; 
for (ExternalStorageMountPolicy policy : mPolicies) { 
final int policyMode = policy.getMountMode(uid, p 
if (policyMode == Zygote.MOUNT_EXTERNAL_NONE) { 
return Zygote.MOUNT_EXTERNAL_NONE; 


mountMode = Math.min(mountMode, policyMode) ; 


if (mountMode == Integer.MAX_VALUE) { 
return Zygote.MOUNT_EXTERNAL_NONE; 
} 


return mountMode; 


i; 


这 个 遂 数 的 处 理 逻 辑 是 : 遍历 所 有 的 Poli cy 规则 ， 并 从 中 挑选 出 数 
值 最 小 的 MountMode 一 一 按照 由 小 而 大 的 顺序 排列 ， 它 们 依次 是 : 
MOUNT EXTERNAL NONE、 MOUNT EXTERNAL DEFAULT, 

MOUNT EXTERNAL READ 和 MOUNT EXTERNAL WRITE。 应 用 程序 的 MountMode 
的 具体 取 值 主要 由 PMS 的 checkUidPermission 来 判断 ， 而 后 者 则 会 根据 
APP 在 AndroidManifest 中 申请 WRITE_MED1A_STORAGE、 
READ_EXTERNAL_STORAGE 和 WRITE_EXTERNAL_STORAGE 等 权限 的 情况 来 给 
出 结论 。 


当 Zygote 旷 化 出 一 个 应 用 程序 进程 后 ， 会 在 MountEmulatedStorage 
中 对 Mount Mode 做 进一步 处 理 ， 核 心 实现 如 下 : 


if (unshare(CLONE_NEWNS) == -1) { 
ALOGW("Failed to unshare(): %s", strerror(errno)); 
return false; 





String storageSource; 


if (mount_mode == MOUNT_EXTERNAL_DEFAULT) { 


storageSource = "/mnt/runtime/default"; 

} else if (mount_mode == MOUNT_EXTERNAL_READ) { 
storageSource = "/mnt/runtime/read"; 

} else if (mount_mode == MOUNT_EXTERNAL_WRITE) { 
storageSource = "/mnt/runtime/write"; 

} else { 


// Sane default of no storage visible 
return true; 


} 
if (TEMP_FAILURE_RETRY(mount(storageSource.string(), "/storag 
NULL, MS_BIND | MS REC | MS_SLAVE, NULL)) == -1) {.. 


我 们 不 得 不 承认 Android 的 很 多 新 功能 是 和 Linux Kerne1 的 更 新 换 
代 息 息 相关 的 ， 例 如 上 述 代码 段 中 就 用 到 了 mount namespace, bind 
ee 多 项 内 核 技 术 。 建 议 大 家 可 以 先 自行 查阅 相关 资料 了 解 这 些 技 


Android 6.0 中 引入 了 如 下 几 个 被 称 为 “View” 的 mount point: 
e /mnt/runtime/default 


提供 给 没有 特殊 权限 的 应 用 程序 ， 以 及 adbd 等 系统 组 件 所 在 的 root 


namespace。 
e /mnt/runtime/read 
提供 给 那些 具有 READ_EXTERNAL_STORAGE 权 限 的 应 用 程序 
e /mnt/runtime/write 
提供 给 那些 具有 WRITE_EXTERNAL_STORAGE 权 限 的 应 用 程序 


透 过 不 同 的 “View” 所 能 “看 到 ”的 Mount Tree 是 不 一 样 的 ， 从 而 
实现 了 程序 在 外 部 存储 上 的 分 权限 管理 。 更 为 重要 的 是 ， 采 用 这 种 实现 
方式 在 应 对 Runtime pa atl igen tn 
效 的 。 具 体 来 说 ， 当 程序 取得 Storage 新 的 Runtime Permission 以 后 ， 
PS 安 通 过 ount&ervice 向 Vold 的 GonerdListener £ — 条 名 
为 “remount_uid” 的 命令 ， 后 者 则 进一步 将 消息 传递 给 Vold 的 
VolumeManager : : remountU i dekj 24 在 这 个 函数 中 就 可 以 对 相应 的 进 





程 进行 “视角 ”的 重新 调整 ， 从 而 达到 我 们 的 预期 效果 。 


其 他 Runtime Permission 的 实现 原理 也 是 类 似 的 ， 大 家 可 以 自行 分 
析 了 解 。 


7.3 多 用 户 管 理 


Android 的 多 用 户 管理 功能 并 不 算 流行 ， 但 是 它 会 影响 到 不 少 模块 
的 内 部 实现 ， 蔷 如 存储 管理 、 权 限 管理 等 (参考 上 一 小 节 ) 。 因 而 我 们 
re elm ea 以 便 读者 在 遇 到 类 似 场景 时 有 一 个 清楚 
I 认识。 


多 用 户 管理 意味 着 我 们 可 以 在 同一 台 设 备 中 支持 多 个 使 用 者 。 类 似 
于 Windows 系 统 中 的 做 法 ，Android 中 的 用 户 也 是 分 类 型 的 ， 具 体 如 下 所 
/小 。 


e Primary 


这 是 设备 的 第 一 个 同时 也 是 首选 的 用 户 ， 类 似 于 Windows 中 的 
Administrator. Primary User 是 不 能 被 删除 的 ， 而 且 会 一 直 处 于 运行 
状态 。 另 外 ， 它 拥有 一 些 特 殊 的 权限 和 设置 项 。 


e Secondary 


这 是 被 添加 到 设备 中 的 除 pr imary user 外 的 其 他 用 户 。 它 可 以 被 移 
除 ， 并 且 不 能 影响 设备 中 的 其 他 用 户 。 


e Guest 
临时 性 的 secondary user， 系 统 中 同时 只 能 有 一 个 Guest user. 


用 户 类 型 也 直接 决定 了 它们 的 权限 范围 ， 例 如 只 有 primary user 才 
拥有 对 phone cal1 和 texts 的 完全 控制 权 。 而 secondary 默 认 情 况 下 只 能 
接听 电话 ， 而 无 权 技 打 或 者 操作 短信 功能 。 当 然 ， 这 也 取决 于 
Settings->Users 中 针对 secondary user 的 授权 情况 。 


用 户 安装 的 程序 虽然 都 在 /data/app 目 录 下 ， 但 是 它们 的 数据 存储 
位 置 则 有 所 差异 。 具 体 来 说 ，/data/data 目 录 下 保存 的 是 Pr imary User 
的 数据 ， 而 其 他 用 户 的 数据 则 被 放置 于 /data/user/<uid>/ 中 
(/data/user/0 和 /data/data 中 的 内 容 是 一 臻 的) 。 


不 过 从 Android 5. 0 开始 ， 多 用 户 的 特性 默认 情况 下 是 被 关闭 的 。 


我 们 需要 修改 以 下 配置 文件 来 打开 : 


/*frameworks/base/core/res/res/values/config.xm1l*/ 


<!-- Maximum number of Supported users --> 
<integer name="config_multiuserMaximumUsers">1</integer> 
<!-- Whether UI for multi user should be shown --> 


<bool name="config_enableMultiUserUI">false</bool> 


设备 商 可 以 根据 需要 来 修改 上 述 两 个 配置 项 ， 只 有 这 样 才 能 开局 设 
备 的 多 用 户 功能 。 


管理 Activity 和 组 件 运 行 状态 的 系统 进程 一 一 
ActivityManagerService (AMS) 


ActivityManagerService (AMS) 是 Android 提 供 的 一 个 用 于 管理 
Activity 《和 其 他 组 件 ) 运行 状态 的 系统 进程 ， 也 是 我 们 编写 APK 应 用 
程序 时 使 用 得 最 频繁 的 一 个 系统 服务 。 

本 章 内 容 编 排 如 下 : 

。 AMS 功 能 概述 

虽然 开发 者 经 常会 使 用 到 AMS 提 供 的 一 些 功能 ， 但 可 能 鲜 有 机 会 对 
它 进 行 统一 的 整理 与 分 析 。 因 此 我 们 先 对 AMS 的 功能 进行 整体 概述 ， 从 
而 为 后 面 分 析 其 内 部 实现 打下 基础 。 

e ActivityStack 


理解 了 AMS 所 需 完 成 的 功能 后 ， 我 们 会 深入 代码 层 来 讲解 它们 的 实 
现 一 一 其 中 最 重要 的 两 个 核心 就 是 ActivityStack 和 ActivityTask。 


从 名 称 就 可 以 看 出 ，ActivityStack 是 Activity 的 记录 者 与 管理 
者 ， 同 时 也 为 AMS 管 理 系统 运行 情况 提供 了 基础 。 


e ActivityTask 
Task 是 Android 应 用 程序 中 的 一 大 利器 ， 而 且 其 中 涉及 的 逻辑 关系 


相对 复杂 ， 因 而 我 们 专门 用 一 个 小 节 具 体 讲解 。 


8.1 AMS 功 能 概述 


和 WMS 一 样 ，AMS 也 是 寄存 于 systemServer 中 的 。 它 会 在 系统 启动 
时 ， 创 建 一 个 线程 来 循环 处 理 客 户 的 请 求 。 值 得 一 提 的 是 ，AMS 会 向 
ServiceManager 登 记 多 种 Binder Server 
如 “activity” “meminfo” “cpuinfo” 等 一 一 不 过 只 有 第 
个 “activity” 才 是 AMS 的 “ 主 业 ”， 并 由 Activity ManagerService 实 
见 ; 剩余 服务 的 功能 则 是 由 其 他 类 提供 的 。 


先 来 看 看 AMS 的 启动 过 程 。 如 下 所 示 : 


/*frameworks/base/services/java/com/android/server/SystemServer , j 
public void run() { 


Slog.i(TAG, "Activity Manager"); 
context = ActivityManagerService.main(factoryTest); // 启 动 AMS 


ActivityManagerService.setSystemProcess(); // 问 Service Manage 


ActivityManagerService 提 供 了 一 个 静态 的 main 函 数 ， 通 过 它 可 以 
松 地 启动 AMS。 se 
服务 注册 到 ServiceManager 。 由 此 可 见 它 和 WMS 一 样 ， 都 是 “实名 ”的 


Binder Server: 


/*frameworks/base/services/java/com/android/server/am/ActivityMan 
public static final Context main(int factoryTest) { 
AThread thr = new AThread(); // 创 建 AMS 线 程 
thr.start(); // 启 动 AMS 线 程 
synchronized (thr) { 
while (thr .mService == null) {/* 注 意 ， 这 段 代 码 是 运行 在 Syst 
所 以 通过 mService 是 否 为 空 来 判断 AMS 成 功 启动 与 否 : oS 
继续 执行 ， 否 则 就 一 直 等 待 。 Android 在 处 理 “ 系 统 级 进程 "出 错时 的 : 
了 ， 任 何 补救 都 是 无 力 回 天 的 “， 所 以 它 的 异常 处 理 部 分 经 常 是 空 的 */ 
try { 
thr.wait(); 
} catch (InterruptedException e) { 
} 























m.mMainStack = new ActivityStack(m, context, true); /* 创 建 
这 是 AMS 的 核心 ， 很 多 工作 都 是 


return context; 


} 


我 们 在 线程 章节 讨论 过 wait 的 用 法 ， 这 里 就 是 一 个 典型 应 用 。 对 于 
SystemServer 所 在 线程 来 说 ， 它 需要 等 到 AThread 〈 即 上 述 的 变量 thr ) 
成 功 局 动 后 才能 继续 往 下 执行 。 所 以 当 thr. start () 后 ， 就 通过 
thr. wait () 进 入 等 待 。 那 么 ， 什 么 时 候 唤 醒 呢 ? 答案 就 在 AThread 内 


部 : 


static class AThread extends Thread 4.. 
public void run() {.. 
synchronized (this) { 
mService = m; 
mLooper = Looper.myLooper()j; 
notifyAll(); 
} 


上 面 的 notifyAl1 会 唤醒 所 有 在 thr 这 个 ob ject 所 在 等 待 队列 上 的 目 
标 ， 自 然 也 就 包括 了 SystemServer 所 属 线程 。 这 么 做 的 原因 是 
SystemServer 的 后 续 运 行将 依赖 于 AMS， 所 以 如 果 在 AMS 还 未 就 绪 的 情况 
下 就 贸然 返回 ， 很 可 能 会 造成 系统 宕 机 。 


将 AMS 注 册 到 Servi ceManager 很 简单 ， 唯 一 要 注意 的 是 它 不 只 注册 
了 自己 一 个 Server， 而 是 一 系列 与 进程 管理 相关 的 服务 。 如 下 所 示 : 


public static void setSystemProcess() { 
try { 
ActivityManagerService m = mSelf; 
ServiceManager.addService("activity", m, true);//AMSff 
ServiceManager .addService("meminfo", new MemBinder (m) 
../V 其 他 服务 省 略 
} 


要 了 解 AMS 提 供 的 所 有 功能 ， 最 好 的 方法 就 是 查看 
IAct ivityManager. java。AMS 所 做 的 工作 就 是 围绕 这 份 接口 声明 展开 的 
不 过 因为 文件 行 数 比 较 多 ， 此 处 不 一 行 行列 出 ， 而 是 直接 对 它 进 行 


分 类 摘 述 。 


1. 组 件 状 态 管理 





这 里 的 组 件 不 仅仅 指 Activity， 而 是 所 有 四 大 组 件 。 状 态 管 理 包 括 
组 件 的 开启 、 关 闭 等 一 系列 操作 ， 如 startActivity、 
startActivityAndWait, activityPaused, startService, 
stopService, remove ContentProvider=#. 


2. 组 件 状态 查询 


这 类 防 数 用 于 查询 组 件 当 前 的 运行 情况 ， 如 getCallingActivity、 
getServices 等 。 


3. Task 相 关 

Task 相 关 的 函数 包括 removeSubTask、removeTask、 
moveTaskBackwards、moveTaskToFront 等 。 本 章 最 后 一 个 小 节 将 会 重点 
介绍 Task 。 


4. 其 他 


除了 上 述 类 型 的 函数 外 ，AMS 还 提供 了 不 少 辅助 功能 ， 如 系统 运行 
时 信息 的 查询 (getMemory lnfo，setDebugApp 等 ) 。 


接 下 来 的 两 个 小 节 ， 我 们 主要 分 析 AMS 中 与 “组 件 和 Task 部 分 ” 相 
天 功能 的 实现 原理 。 





8.2 管理 当前 系统 中 Act ivity 状 态 


我 们 在 查看 AMS 代 码 时 ， 会 发 现 很 多 地 方 用 到 了 一 个 名 为 
mMai nStack 的 变量 。 它 是 ActivityStack 类 型 的 对 象 ， 并 且 在 AMS 局 动 时 
就 创建 出 来 了 : 


/*frameworks/base/services/java/com/android/server/am/ActivityMan 
public static final Context main(int factoryTest) {/*main( ) HAGE) 


Activity Stack 


ActivityManagerService m = thr.mService; 


m.mMainStack = new ActivityStack(m, context, true, thr.mLoop 


从 名 称 上 看 ，Act ivityStack 是 管理 当前 系统 中 所 有 Act ivity 状 态 
的 一 个 数据 结构 。 那 么 ， 是 不 是 这 样 的 呢 ? 我 们 来 看 看 这 个 类 里 面 有 哪 
些 重要 的 成 员 元 素 和 接口 。 

以 下 内 容 是 从 ActivityStack. java 中 提取 出 来 的 。 
1. ActivityState 

描述 了 一 个 Activity 所 可 能 经 历 的 所 有 状态 。 其 定义 如 下 : 


enum ActivityState { 
INITIALIZING，// 正 在 初始 化 


RESUMED, // 恢 复 

PAUSING, // 正 在 暂停 
PAUSED, // 已 经 暂停 
STOPPING, // 正 在 停止 
STOPPED, // 己 经 停止 


FINISHING, // 正 在 完成 

DESTROYING, // 正 在 销毁 

DESTROYED // 己 经 销毁 
} 


结合 Activity 状 态 改变 时 其 自身 所 能 收 到 的 回调 函数 ， 我 们 来 描述 
下 它 的 状态 迁移 图 。 读 者 可 以 将 图 8-1 和 前 面 列 出 的 各 Activity 状 态 做 
一 个 对 照 。 


2. ArrayList 


除了 状态 管理 外 ，ActivityStack 中 还 有 一 系列 不 同 功能 的 
ArrayList 成 员 变 量 。 它 们 的 共同 点 在 于 列表 元 素 都 是 ActivityRecord 
这 个 类 负责 记录 每 个 Activity 的 运行 时 信息 。 因 而 也 可 以 看 出 ， 
ActivityStack 确 实 是 AMS 中 管理 Activity 的 “大 仓库 ”。 
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全 图 8-1 Activity 状 态 迁 移 图 
表 8-1 列 出 了 其 中 几 个 重要 的 ArrayList。 


一 和 (部 分 ) 


所 有 Activity 的 信息 在 这 里 都 有 记录 ， 
Hale ee 


正在 运行 的 Activity 的 列表 集合 ， 以 最 
mLRUActivities 近 的 使 用 情况 来 排序 ， 即 队 头 元 素 是 
最 近 使 用 最 少 的 元 素 


人 的 Activity 已 经 可 以 被 Stop ， 但 
mStoppingActivities 是 还 得 等 待 下 一 个 Activity 处 于 就 绪 状 


JO 


a Aci HR 


列表 中 的 Activity 不 考虑 状态 间 迁 移动 


mNoAnimActivities 画 


列表 中 的 Activity 已 经 可 以 被 finished， 


mFinishingActivities 但 还 需要 等 待 上 一 个 Activity 就 绪 





3. 记录 特殊 状态 下 的 Activity 


除了 上 面 的 ArrayList 用 来 描述 各 种 状态 下 的 Activity 集 合 外 ， 
ActivityStack 还 通过 以 下 多 个 变量 来 专门 记录 一 些 特殊 状态 下 的 
Activity 实 例 ， 具 体 如 表 8-2 所 示 。 


表 8-2 ”特殊 状态 下 的 Act ivi a 


当前 正在 被 暂停 (pausing) FY) Activity 





以 上 所 述 的 3 类 变量 构成 了 ActivityStack 的 主 框架 。 如 果 用 一 句 话 
来 简单 概述 AMS 的 功能 ， 就 是 : 


“AMS 是 通过 ActivityStack 《和 其 他 数据 结构 ) 来 记录 、 管 理 系统 
eee 
这 句 话 包含 了 以 下 几 个 重点 。 
1. AMS 的 主要 工作 就 是 管理 、 记 录 、 查 询 
打 个 比方 ，AMS 就 像 户籍 登记 处 。 所 有 新 加 入 或 者 注销 的 家 庭 都 需 
要 到 这 里 办 理 业 务 ; 而 且 它 还 提供 对 外 的 查询 功能 这 应 类 似 于 公 
局 开具 的 “户籍 证 明 ”， 用 于 表明 办 证 者 当前 的 户口 状态 。 


2. AMS 是 系统 进程 的 一 部 分 (确切 地 说 它 运行 于 一 个 独立 的 线程 中 ) 





从 内 核 的 角度 来 说 ，AMS 其 实 也 是 普通 进程 中 的 一 部 分 ， 只 不 过 它 
提供 的 是 全 局 性 的 系统 服务 。 接 着 上 面 打 的 比方 ， 户 籍 登 记 处 和 家 庭 一 
样 ， 也 是 在 一 个 “房子 ”进程 里 运行 的 。 它 有 一 套 严 格 的 办 事 规程 
《线程 ) ， 来 处 理 户主 的 各 种 请 求 〈 登 记 、 注 销 、 查 询 等 ) 。 值 得 一 提 
的 是 ，AMS 的 任务 只 是 负责 保管 Activity《〈 及 其 他 组 件 ) 的 状态 信息 ， 
而 像 Activity 中 描述 的 UI 表 面 如 何在 物理 屏幕 上 显示 等 工作 则 是 由 
WindowManagerService 和 SurfaceF1inger 来 完成 的 (后 续 章 节 有 详细 讲 
解 ) 。 


8.3 startActivity 流 程 


前 两 个 小 节理 清 了 AMS 所 能 提供 的 功能 以 及 内 部 的 一 些 重要 变量 。 
那么 ，AMS 具 体 是 如 何 开展 工作 的 呢 ? 


如 果 单 纯 从 理论 的 角度 来 分 析 ， 大 家 很 可 能 会 有 “ 云 里 雪 里 ”的 感 


贯穿 起 来 一 一 这 个 例子 就 是 startAct ivity () 函数 的 执行 过 程 〈 在 讲解 
过 程 中 我 们 会 省 略 Binder 通 信 等 中 间 细 节 ， 因 为 这 部 分 内 容 在 前 面 章节 
已 有 详细 前 述 ) 。 


相信 大 家 对 startActivity (Intent) 的 功能 不 会 陌生 。 它 用 于 启动 
一 个 目标 Activity 一 一 具体 是 哪个 Activity 则 是 AMS 通 过 对 系统 中 安装 
的 所 有 程序 包 进 行 “Intent 匹 配 ” 得 到 的 ， 并 不 局 限于 调用 者 本 身 所 在 
的 package 范 围 。 换 句 话说 ，startActivity () 最 终 很 可 能 局 动 的 是 其 他 
进程 中 的 组 件 。 当 系统 匹配 到 某 个 目标 Activity 后 分 为 两 种 情况 。 


。 如 果 通 过 Intent 匹 配 到 的 目标 对 象 ， 其 所 属 程序 包 中 已 经 有 其 他 元 
素 在 运行 (意味 着 该 程序 进程 已 启动 ) ， 那 么 AMS 就 会 通知 这 个 进 
程 来 加 载运 行 我 们 指定 的 目标 Activity。 

。 如 果 当 前 Activity 所 属 程序 没有 进程 在 运行 ，AMS 就 会 先 启动 它 的 一 
个 实例 ， 然 后 让 其 运行 目标 Activity。 


先 大 致 讲解 一 下 startActivity() 所 经 历 的 函数 调用 流程 ， 从 调用 
A (Activity1) 开始 : Activity1 一 
startActivity@Contextimpl. Java 一 execStartActivityo@lnstrumentat | 
Service. javao 


因而 经 过 层 层 中 转 后 ， 调 用 者 发 起 的 startAct ivity 最 终 还 是 在 AMS 
中 实现 的 。 接 下 来 的 问题 就 转化 为 : AMS 内 部 对 startActivity 是 如 何 处 
理 的 ? 


“理想 很 丰满 ， 现 实 很 骨 感 ”， 看 似 简 单 的 一 个 功能 ， 实 际 上 AMS 
要 做 的 工作 还 是 很 多 的 首先 来 辨别 下 AMS 中 5 个 “长 相 ” 类 似 的 
startActivity 函 数 ， 以 防 后 期 混淆 。 统 一 列 出 如 下 : 











e startActivity@ActivityManagerService.java 

o startActivityAsUser@ ActivityManagerService.java 
e startActivityMayWait@ActivityStack.java 

e startActivityLocked@ActivityStack. java 

e startActivityUncheckedLocked@ActivityStack.java 


这 5 个 函数 存在 先后 调用 的 关系 。 源 代码 如 下 : 


/*frameworks/base/services/java/com/android/server/am/ActivityMan 
public final int startActivity(IApplicationThread caller, Str 
Intent intent, String resolvedType, IBinder resultTo, 
String resultWho, int requestCode, int startFlags, 
String profileFile, ParcelFileDescriptor profileFd, Bu 
return startActivityAsUser(caller, callingPackage, intent 
result To, resultwWho, requestCode, star 
profileFile, profileFd, options, UserHa 


} 


可 以 看 到 ，startActivityAsUser 与 startActivity 只 多 了 最 后 一 个 
参数 user1d， 它 表示 调用 者 的 用 户 1D 值 ， 因 而 可 以 通过 Binder 机 制 的 
getCallingUid 获 得 : 


public final int startActivityAsUser(IApplicationThread calle 
Intent intent, String resolvedType, IBinder resultTo, 
String resultWho, int requestCode, int startFlags, Stri 
ParcelFileDescriptor profileFd, Bundle options, int use 
enforceNotIsolatedCaller("startActivity"); 
userId = handleIncomingUser (Binder.getCallingPid(), Binder. 
false, true, "startActivity", null); 
return mMainStack.startActivityMayWait (caller, -1,callingPac 
resultTo, resultWho, requestCode, startFlags, profile 
null, null, options, userId) ;/*ixX*Mmw#eActivityStacks 
} 


哨 数 startActivityAsUser 的 一 大 重点 就 是 做 权限 检查 ， 包 括 : 
e enforceNotlsolatedCaller 
检查 调用 者 是 否 属于 被 隔离 的 对 象 。 


e handleIncomingUser 


调用 者 是 否 有 权力 执行 这 一 操作 。 


由 此 也 可 以 看 出 ，5 个 “startActivityXX” 其 实 是 5 个 执行 步骤 ， 
而 且 一 旦 其 中 一 步 出 现 错误 就 会 中 止 整个 流程 。 


接着 往 下 分 析 startAct ivityMayWait 这 个 函数 。 因 为 代码 很 长 ， 我 
们 直接 把 其 中 的 核心 工作 提取 出 来 ， 如 图 8-2 所 示 。 


根据 [ntent 查 找 符 


erat Activity 
的 Actvity Info 


startActivity 
Locked 





全 图 8-2 startActivityMayWait 
根据 图 8-2 中 的 描述 ， 在 startActivityMayWait 中 : 


e 然 是 要 启动 某 个 符合 Intent 要 求 的 Activity， 那 么 首先 就 应 确定 这 个 
目标 Activity: 如 果 是 显 式 的 Intent， 问 题 很 好 解决 ， 因 为 Intent 信 息 


中 已 经 带 有 目标 Activity 的 相关 信息 ; 否则 就 调用 resolveActivity0 进 
行 查找 一 一 具体 过 程 可 以 参见 本 书 应 用 篇 中 Intent 匹 配 章节 的 描 
判断 目标 Activity 所 属 进程 是 不 是 重量 级 (heavy -weight) 的 。 如 果 当 
前 系统 中 已 经 存在 的 重量 级 进程 (mService.mHeavyWeightProcess ) 
不 是 即将 要 局 动 的 这 个 ， 那 么 就 要 给 Intent 重 新 赋值 。 

调用 stattActivityLocked 来 进一步 执行 启动 工作 。 

如 果 outResult 不 为 空 ， 还 需要 将 函数 的 结果 写 入 这 个 变量 中 。 因 为 
前 面 startActivity 传 入 时 此 参数 为 nul， 所 以 这 里 可 以 直接 略 过 。 


这 个 函数 的 名 称 表 明 它 有 可 能 会 “wait” 具体 就 表现 在 对 
outResult 的 处 理 上 。 有 兴趣 的 读者 可 以 自行 分 析 ， 具 体 如 图 8-3 所 示 。 
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startActivityUncheckedLocked 启动 权限 判断 





全 图 8-3 startActivityLocked(1) 执 行 流程 


紧 接 着 被 调用 的 函数 是 startAct ivityLocked。 需 要 特别 注意 的 
是 ，ActivityStack 中 存在 两 个 同名 的 startActivityLocked 印 数 ， 但 人 参 
数 不 同 。 我 们 把 参数 较 多 的 那个 称 为 startActivityLocked (1) , A— 
个 则 是 startActivityLocked (2) 。Android 源 码 中 的 很 多 函数 后 面 都 


有 Locked 标 志 ， 用 于 提醒 我 们 必须 保证 这 些 函 数 的 线程 安全 一 一 内 为 它 
们 涉及 不 可 重 入 资源 的 处 理 。 图 中 所 示 的 是 startActivityLocked (1) 
函数 的 处 理 流程 。 主 要 工作 是 : 


Step1@startActivityLocked (1) ， 确 保 调用 者 本 身 的 进程 是 存在 
的 ， 否 则 就 直接 返回 START_PERM1SS10N_DEN1ED 错 误 。 这 种 情况 是 有 可 
能 发 生 的 ， 如 调用 者 被 系统 杀 死 ， 或 者 异常 退出 等 。 


Step2@startActivityLocked(1)， 处 理 FLAG_ACTIVITY_FORWARD_RESULT 


这 个 标志 具有 跨越 式 传递 的 作用 。 比 如 Activity1 正 常 启动 了 
Activity2， 而 当 Activity2 启 动 Activity3 时 使 用 了 这 个 标志 ， 那 么 当 
Activity3 调 用 setResult 时 ，result 并 不 会 像 一 般 情 况 中 那样 传递 给 
Activity2， 而 是 传递 给 最 初 的 Activity1。 


为 了 达到 这 一 目的 ， 就 需要 将 新 局 动 的 Activity3 的 cal ler 改 为 
Activity1。 有 具体 如 下 所 示 : 


if ((launchFlags&Intent .FLAG_ACTIVITY_FORWARD_RESULT ) 
I= 0&& sourceRecord != null) { 
if (requestCode >= 0) { 
ActivityOptions.abort(options) ; 
return ActivityManager .START_FORWARD_AND_REQUEST_ 





} 


resultRecord = sourceRecord.resultTo; 

resultWho = sourceRecord.resultwho; 

requestCode = sourceRecord.requestCode; 

sourceRecord.resultTo = null; 

if (resultRecord != null) { 
resultRecord.removeResultsLocked(sourceRecord, re 

} 


J 


因为 在 这 个 标志 下 ，Activity2 已 经 把 接收 result 的 目标 对 象 设 置 
为 Activity1， 因 而 它 自身 不 能 再 通过 startActivityForResult 来 启动 
Activity3 了 ， 否 则 就 会 报 START_FORWARD_AND_REQUEST_CONFLICT 的 错 
io 


Step3@startActivityLocked (1) ， 如 果 此 时 还 没有 找到 合适 的 目 
标 Act ivity 来 处 理 Intent， 或 者 这 个 目标 的 Activitylnfo 为 空 ， 都 说 明 
这 个 Intent 没 有 办 法 继续 处 理 了 ， 因 此 程序 会 直接 报错 返回 。 


Step4@startActivityLocked (1) ， 上 面 的 判断 通过 后 ， 还 需要 查 
验 调用 者 是 否 有 权限 来 启动 指定 的 Activity。 具 体 如 下 所 示 : 


final int startAnyPerm = mService.checkPermission(START_ANY_A 
callingPid, 

final int componentPerm = mService.checkComponentPermission(a 
callingPid, callingUid, aInfo.applicationInfo.uid, al 


上 述 这 两 个 权限 检查 必须 全 部 通过 ， 否 则 会 抛 出 


Secur ityException. 


Step5@startActivityLocked (1) ， 生 成 一 个 ActivityRecord 变 量 
+， 记 录 当前 的 各 项 判断 结果 ， 然 后 进一步 调用 
startActivityUncheckedLocked 这 个 函数 里 将 涉及 一 系列 启动 模式 
和 lntent 标 志 的 处 理 ， 建 议 读 者 穿插 阅读 Act ivityTask 小 节 中 对 这 些 标 
志 的 说 明 。 


接 下 来 我 们 再 详细 讲解 startActivityUncheckedLocked 这 个 函数 。 





Step1@startActivityUncheckedLocked， 前 期 准备 


首先 得 到 1ntent 中 的 启动 标志 : 


int launchFlags = intent.getFlags(); 


然后 处 理 FLAG ACTIVITY NO USER ACTION。 这 个 标志 表示 并 不 是 用 
户 “ 主 观 意 愿 ” 启 动 的 Activity， 而 是 如 来 电 、 闸 钟 事件 等 触发 的 
Activity 启 动 。 


如 果 调 用 者 指示 先 不 要 resume (doResume 为 空 ) ， 那 么 我 们 将 
delayedResume 设 置 为 true。 如 果 使 用 了 
FLAG ACTIVITY PREVIOUS IS TOP， 则 notTop 为 r 本 身 ， 否 则 为 空 。 


Step2@startActivityUncheckedLocked。 
START_FLAG ONLY_1IF_NEEDED 


只 在 需要 的 情况 下 才 启 动 目标 ， 即 如 果 被 启动 的 对 象 和 调用 者 是 同 
一 个 ， 那 么 就 没有 必要 重复 操作 。 


Step3@startActivityUncheckedLocked。 判 断 是 否 要 局 动 新 的 Task 


变量 launchFlags 是 用 于 记录 Activity 的 局 动 方式 的 。 如 果 
sourceRecord 为 空 ， 表 明 我 们 应 该 启动 一 个 新 的 task 来 容纳 目标 
Activity， 因 而 需要 设置 FLAG_ACTIVITY_NEW_TASK; 否则 如 果 
sourceRecord 的 launchMode 为 LAUNCH_SINGLE_INSTANCE， 或 者 目标 
ActivityRecord 的 1aunchMode 为 LAUNCH SINGLE_INSTANCE#O 
LAUNCH_SINGLE_TASK 中 的 任何 一 个 〈launchMode 是 在 AndroidManifest 
中 设置 的 ) ， 也 需要 在 新 的 Task 中 局 动 。 


Step4@startActivityUncheckedLocked。 在 启动 新 Task 的 情况 下 无 
法 返回 结果 值 


如 果 上 一 步骤 判断 的 结果 是 需要 启动 一 个 新 的 Task， 那 么 目标 
Activity 就 和 原先 的 调用 者 不 在 一 个 Task 中 了 。 由 于 startActivity 的 
结果 是 没有 办 法 跨越 Task 传 递 的 ， 这 时 我 们 返回 一 个 
RESULT CANCELED. 


sendActivityResultLocked(-1, r.resultTo, r.resultWho, r.requestCo 
Activity.RESULT_CANCELED, null); 


Step5@startActivityUncheckedLocked。 对 于 新 Task 的 细 化 处 理 


ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH 
? findTaskLocked(intent, r.info) 
: findActivityLocked(intent, r.info); 


Op 52 4S FZLAUNCH SINGLE_INSTANCE, ABA FRA f indTaskLocked 
来 找到 符合 要 求 的 Task 一 一 此 Task 的 最 顶端 就 是 我 们 要 找 的 目标 
Activity; 如 果 设 置 了 标志 LAUNCH_SINGLE_INSTANCE， 说 明 这 个 
Activity 所 在 的 Task 只 能 容纳 目标 Act ivity 一 个 实例 。 这 两 个 函数 ， 即 
findTaskLocked 和 findActivityLocked 都 有 可 能 返回 空 。 





如 果 用 户 设置 了 FLAG ACTIVITY_RESET _TASK_IF_NEEDED， 那 么 执行 
resetTask1fNeeded Locked 来 清理 Task。 如果 
START_FLAG_0NLY_1F_NEEDED 不 为 空 ， 那 么 有 两 种 可 能 : 要 么 resume 顶 
部 的 Activity (doResume 不 为 空 ) ;要 么 abort。 


如 果 标 志 FLAG_ACTIVITY_NEW_TASK 和 FLAG_ACTIVITY_CLEAR_TASK 同 
时 存在 ， 那 么 我 们 清理 整个 Task (performClearTaskLocked) ; 否则 如 
FAFLAG ACTIVITY CLEAR TOP 或 者 1aunchMode 为 singleTask (或 


singlelnstance) ， 那 么 就 清理 目标 Activity 以 上 的 那些 元 素 ; 否则 如 
果 Task 中 最 顶层 Activity 就 是 目标 对 象 ， 那 么 我 们 把 整个 Task 提 到 前 
台 ; 否则 如 果 设 置 了 标志 FLAG_ACTIVITY_RESET_TASK_IF_NEEDED， 那 么 
我 们 将 目标 对 象 加 入 Task 顶 端 。 


假如 当前 Task 最 顶端 的 Activity 与 我 们 的 目标 对 象 是 同一 个 ， 那 么 
我 们 需要 确认 这 个 目标 是 否 只 能 启动 一 次 。 


Step6@startActivityUncheckedLocked。 接 下 来 的 代码 是 基于 
newTask 为 fal se 的 情况 ， 不 过 也 有 例外 。 比 如 设置 了 
FLAG_ACTIVITY_NEW_TASK， 但 是 经 过 前 面 的 判断 后 addi ngToTask 为 
false， 此 时 newTask 还 是 为 真 。 


Step7@startActivityUncheckedLocked。 最 后 调用 
startActivityLocked(2) 来 真正 地 执行 启动 操作 。 这 个 函数 不 仅 是 AMS 
启动 Activity 的 关键 ， 同 时 也 是 Activity 后 续 能 否 在 WMS 中 得 到 正常 处 
理 的 关键 。 


函数 startActivityLocked (2) 是 启动 Activity 的 最 后 一 站 ， 主 要 包 
含 以 下 几 方 面 的 工作 。 


Step1@startActivityLocked (2) 。 首 先 ， 如 果 目 标 Activity 不 是 在 
新 task 中 启动 的 ， 即 newTask 变 量 为 false， 那 么 程序 要 找 出 目标 
Activity 位 于 哪个 老 task 中 〈 这 可 以 通过 遍历 整个 mnHi story 列 表 来 实 
现 ) 。 找 到 后 ， 如 果 这 个 task 当 前 对 用 户 还 不 是 可 见 的 ， 那 么 只 需要 将 
它 加 入 mHi story， 并 在 WMS 中 做 好 注册 ， 但 不 启动 它 。 


Step2@startActivityLocked (2) 。 将 这 个 Activity 放 在 stack 的 最 
顶层 ， 这 样 才能 与 用 户 交 互 。 添 加 的 语句 如 下 : 


mHistory.add(addPos, r); 
r.putInHistory(); 
r.frontoOfTask = newTask; 


上 面 代码 的 第 一 句 在 mHi story 中 添加 r (ActivityRecord) WR, Æ 
二 句 则 更 新 r 内 部 变量 并 增加 它 所 在 task 的 Activity 成 员 计数 ， 最 后 一 
名 表明 这 个 Activity 是 否 为 此 task 的 root 元 素 如 果 是 新 task 的 话 ， 
那么 答案 就 是 肯定 的 。 





Step3@startActivityLocked (2) 。 接 下 来 ， 如 果 不 是 AMS 中 的 第 一 
“Activity (mHistory 中 个 数 >0) ， 则 执行 切换 动画 〈 不 过 这 也 要 取决 
于 FLAG_ACTIVITY_NO_ANIMATION 标 志 ) 。 执 行 的 动画 类 型 分 为 
WindowManagerPol icy. TRANSIT TASK OPEN 〈 如 果 是 启动 新 的 task) 及 
Window ManagerPolicy. TRANSIT_ACTIVITY_OPEN 〈 不 启动 新 的 task) 两 
种 。 


Step4@startActivityLocked(2). —~SActivityHJUIA BA SEX 
端 屏幕 上 显示 出 来 ， 很 重要 的 一 点 就 是 它 在 WMS 中 必须 “有 档 可 查 ”。 
这 个 “ 档 ” 就 是 appToken， 它 是 在 startActivity 中 添加 的 。 即 : 


mService.mWindowManager .addAppToken( 
addPos, r.appToken, r.task.taskId, r.info.screenOrientatio 


后 续 在 WMS 章节 中 还 会 看 到 关于 这 个 appToken 的 更 多 讲解 。 


Step5@startActivityLocked (2) 。 在 ActivityStack 小 节 ， 我 们 说 
过 Activity 是 有 affinity 的 一 一 言 下 之 意 ， 就 是 它们 “更 亲近 ”与 某 些 
affinity 相 符 的 task。 因 而 如 果 局 动 了 一 个 新 task， 就 需要 检查 是 否 存 
在 “ 同 兴趣 ”的 其 他 Activity。 另 外 ， 如 果 用 户 使 用 了 
FLAG_ACTIVITY_RESET_TASK_IF_NEEDED， 就 满足 “NEEDED” 条 件 了 ， 
而 需要 调用 resetTask1fNeededLocked。 





Step6@startActivityLocked (2) 。 调 用 resumeTopActivityLocked 


至 此 ，startActivity 函 数 的 一 系列 处 理 流程 就 分 析 完 了 一 一 
过 Activity 的 局 动 过 程 还 没有 结束 。 一 方面 ，AMS 会 继续 调用 
resumeTopAct ivityLocked 来 恢复 最 上 层 的 Activity， 并 pause 之 前 的 
Activity; 另 一 方面 ， 在 Activity 切 换 的 过 程 中 还 要 首先 展示 切换 动 
画 ， 然 后 两 个 新 旧 Activity 还 会 向 WMS 分 别 申 请 和 释放 Surface， 最 终 将 
它们 显示 /不 显示 在 屏幕 上 。 这 些 内 容 会 在 WMS 章节 中 再 详细 分 析 。 


这 里 先 看 看 resumeTopActivityLocked 国 数 的 处 理 。 


Step1@resumeTopActivityLocked. WAH 
topRunningActivityLocked， 用 于 从 mHistory 中 取出 ActivityStack 中 
最 上 面 有 效 的 ActivityRecord。 代 码 如 下 : 


int i = mHistory,size()-1;// 所 有 Activity 的 数量 


while (i >= 0) { 
ActivityRecord r = mHistory.get(1); 
if (!r.finishing && r != notTop && okToShow(r)) { 
return r; 
} 


ita 
} 


return null; 


#HHhnotTop Æ AAHAS, AE Ænull. BAF ASIF Ami story 
中 逐个 取出 ActivityRecord 进 行 判断 ， 直 到 符合 下 列 要 求 的 元 素 出 现 : 
状态 不 是 finishing， 不 等 于 notTop 〈 即 nul1) ， 且 可 以 被 显示 出 来 
(一 种 特殊 的 情况 是 当 系 统 锁 屏 时 ， 要 求 这 个 Activity 必 须 带 有 
FLAG_SHOW_ON_LOCK_SCREEN 标 志 ) 。 由 topRunningActivityLocked 返 回 
的 ActivityRecord 结 果 将 赋值 给 resume TopActivityLocked rk PAY 
next = 要 特别 注意 的 是 ， 它 有 可 能 为 空 。 比 如 系统 第 一 次 开机 
时 ， 此 时 mHi story 的 si ze 为 0。 


Step2@resumeTopActivityLocked。 假 如 next 为 空 ， 那 么 我 们 就 要 
启动 Launcher 主 四 面 。 换 句 话 说 ， 无 论 何 时 Android 系 统 都 会 有 正在 运 
行 的 Activity， 默 认 就 是 Launcher。 





Step3@resumeTopActivityLocked。 判 断 当 前 正在 运行 的 Activity 
是 否 就 是 目标 对 象 (mResumedActivity == next && next. state == 
ActivityState. RESUMED) ， 如 果 答 案 是 肯定 的 就 没有 必要 重复 启动 
Ts 


Step4@resumeTopActivityLocked。 假 如 目标 Activity 正 在 
stopping， 那 么 就 要 终止 它 的 这 一 操作 ， 即 从 mStoppingActivities， 
mGoingToSleepActivities，mWaitingVisibleActivities 中 将 它 移 除 ， 
sleeping 标 志 置 false。 


Step5@resumeTopActivityLocked。 执 行 到 这 里 ， 说 明 准 备 工作 已 
经 就 绪 。 接 下 来 程序 分 为 几 个 方向 。 如 果 mPausingAct ivity 不 为 空 ， 证 
明 当 前 正在 pause 前 一 个 Act ivity， 我 们 要 等 待 操作 结束 ， 所 以 函数 中 
止 ， 直 接 返 回 false; 否则 如 果 mResumedAct ivity 不 为 空 ， 说 明 前 一 个 
Activity 还 在 运行 ， 那 么 就 要 先 执行 pause 操 作 ， 流 程 如 图 8-4 所 示 。 


Step6@resumeTopActivityLocked。 如 果 即 将 启动 的 Activity 不 是 
可 见 的 (nowVisible 为 false) ， 将 其 添加 到 


mWaitingVisibleActivities#; 否则 我 们 需要 隐藏 前 一 个 Activity， 
即 调 用 WMS 中 的 setAppVisibility (prev. appToken, false) 。 


Step7@resumeTopActivityLocked。 在 启动 新 Activity 之 前 ， 需 要 
通知 WMS 前 一 个 显示 的 Activity 即 将 被 隐藏 (setAppWi 11lBeHidden) 。 


Step8@resumeTopActivityLocked。 接 下 来 可 以 正式 启动 目标 
Activity 了 。 分 为 两 种 情况 : 要 么 目标 Activity 所 属 程序 已 有 进程 实例 
在 运行 ; 要么 Activity 的 承载 进程 还 没有 局 动 。 






mPausingActivity!=null mResumedActivity'= null 


startPausingl.ocked 


全 图 8-4 流程 图 
假如 是 第 一 种 情况 ， 也 就 是 : 
next.app != null && next.app.thread != null 


那么 我 们 可 以 通知 WMS 这 个 Activity 已 经 具备 了 显示 的 条 件 。 即 : 


mService.mWindowManager.setAppVisibility(next.appToken, true); 


后 更 新 一 系列 全 局 变量 ， 如 mResumedActivity; 并 刷新 与 此 操作 
an E 数据 ， 如 updateCpuStats， dh E AR 
有 任何 正在 等 待 启动 结果 的 对 象 ， 我 们 也 要 一 一 通知 ， 然 后 通 





next.app.thread.scheduleResumeActivity(next.appToken, mService.is 
告知 目标 线程 要 resume 指 定 的 Activity。 


如 果 是 第 二 种 情况 ， 也 就 是 目标 Activity 所 属 程序 并 没有 进程 在 运 
行 的 话 ， 那 么 处 理 过 程 就 要 复杂 一 些 首先 要 调用 
startSpecificActivityLocked 来 启动 能 承载 目标 Activity 的 进程 。 和 
startActivity 一 样 ， 这 个 函数 会 不 断 调用 多 个 “长 相 ” 类 似 的 函数 实 
现 ， 即 startSpecificActivity Locked 一 
startProcessLocked (1) 一 startProcessLocked(2) ， 最 终 调 用 Zygote 来 
启动 一 个 新 进程 。 具 体 如 下 所 示 : 


Process.ProcessStartResult startResult = 
Process.start("<strong>android.app.ActivityThread</str 
debugFlags,app.info.targetSdkVersion, nul 


由 上 面 的 代码 段 也 可 以 看 出 ， 当 一 个 应 用 程序 进程 启动 时 ， 实 际 上 
加 载 了 ActivityThread 这 一 主线 程 。 那 么 ， 新 启动 的 进程 在 什么 时 候 会 
真正 运行 目标 Activity 呢 ? 


细心 的 读者 一 定 已 经 想到 了 ， 进 程 启 动 后 还 需要 通知 AMS， 后 者 才 
能 继续 执行 之 前 未 完成 的 startActivity。AMS 预 留 了 一 段 时 间 来 等 待 这 
一 回调 ， 在 不 同 的 设备 上 标准 有 所 差异 : 要 么 是 10 秒 ， 要 么 是 300 秒 。 
假如 被 启动 的 进程 没有 在 指定 的 时 间 内 完成 attachApplication 回 调 ， 
那么 AMS 就 认为 发 生 了 异常 。 如 果 新 启动 的 进程 在 规定 时 间 内 正常 调用 
了 attachApplication， 那 么 AMS 就 会 判断 当前 是 不 是 有 Act ivity 在 等 待 
这 个 进程 的 启动 。 如 果 是 的 话 就 调用 realStartActivityLocked 〈 看 到 
EER RAMS PAD RS SOE? 这 时 才 是 真正 启动 Activity 的 
WA. ) 继续 之 前 的 任务 。 接 着 就 是 应 用 程序 开发 人 员 所 熟悉 的 一 系列 
Activity 生 命 周 期 的 开始 : onCreate 一 onStart 一 onResume 等 ， 并 且 在 
WMS 与 SurfaceFl1inger 的 配合 下 ， 目 标 Activity 描 述 的 U1 界面 会 呈现 到 
物理 屏幕 上 一 一 至 此 ， 整 个 startActivity 的 流程 才 算 真正 完成 。 


我 们 用 以 下 函数 调用 流程 图 来 小 结 一 下 本 节 的 内 容 。AMS 中 
startActivity 的 过 程 如 图 8-5 所 示 。 





startActivity | 













startActivilyAsUser 
startActivity May Wait 


startActivityLocked(1) 


startActivity UncheckedLocked 


startActvityL_ocked(2) 


resume lopActivityLocked 


如 果 mResumedActivity 不 为 空 ， 和 需要 pause 当 前 的 Aclivity 
À p ) 


| 
Pausc 完 成 ， 通 过 activityPauscd 回 调 







resumeTopActivityLocked 
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如 果 当 前 不 存在 日 标 Activity 实 例 ， 调 用 startSpecificActivityLocked | 
l | 

l 
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如 果 上 月 标 Activity 所 属 进行 不 存在 ， 先 启动 它 ， 同 时 启动 定时 蜂 等 待 同调 


l 
l 
realStartActivityLocked 
l 





scheduleLaunchActivity 


全 图 8-5 AMS #startActivity Fz A 


值得 一 提 的 是 ， 随 着 NDK 的 不 断 完善 ， 目 前 Android 已 经 支持 纯 
C/C++ 语言 实现 的 pp 了 ， 即 NativeActivity。NDK 目 录 下 的 
samples\native-activity 就 是 一 个 很 好 的 例子 ， 如 下 所 示 : 


点 jni 

出 res 

“| AndroidManifest.xml 
__| default.properties 


可 以 看 到 ， 纯 C/C++ 工程 结构 的 最 大 变化 就 是 src 和 res 文 件 夹 没有 
了 。 而 AndroidManifest. xm| 中 会 有 如 下 声明 : 


<activity android:name="android.app.NativeActivity" 
android: Llabel="@string/app_name" 
android: configChanges="orientation|keyboardHidden 
<!-- Tell NativeActivity the name of or .so --> 
<meta-data android: name="android.app.lib name" 
android: value="native-activity" /> 


看 上 去 是 不 是 和 Java 实 现 方案 中 的 Activity 很 类 似 ? Nis, BE 
Android 系 统 只 是 通过 一 个 预先 实现 
BY “android. app. NativeActivity” 作 为 中 转 ， 为 开发 者 省 去 了 人 工 编 
ae ee ee 
i=] 66 汤 不 bb) o 


那么 CXC++ 的 入 口 地 址 在 哪里 呢 ? 


答案 是 android main。NativeActivity 在 onCreate 时 会 去 加 载 上 述 
meta-data 中 指定 的 so 库 ， 并 在 其 中 查找 名 
为 “ANativeActivity onCreate” 的 函数 实现 。 这 个 函数 不 但 会 为 本 地 
层 代 码 运行 创建 一 个 新 线程 ， 而 且 会 调用 到 android_main， 这 样 一 来 就 
进入 到 应 用 程序 自 定义 的 C0/C++ 处 理 逻 辑 中 了 。 


和 SDK 一 样 ，NDK 也 提供 了 丰富 的 AP1 来 供应 用 程序 使 用 。 开 发 者 需 
要 include 模 块 的 头 文 件 ， 并 在 Android. mk 中 导入 相应 的 so 库 。 这 些 资 
源 被 集中 放置 在 NDK 的 platforms 目 录 下 根据 AP1 等 级 和 机 器 平台 来 分 


类 ) 9 如 图 8-6 所 示 。 


J android 
J arpa 
J asm 


J asm-generic 


J EGL 


J GLES 
dJ GLES2 
dJ GLES3 
J KHR 
linux 

Ji machine 
dJi media 
J net 

Ji netinet 
J netpacket 
J OMXAL 
D rs 

J SLES 

出 sys 

|_| alloca.h 
|_| arh 

|_| assert.h 


|_| byteswap.h 


Bi rs 
L ertbegin_dynamic.o 
|_| ertbegin_so.o 

|_| ertbegin_static.o 
|_| ertend_android.o 
|_| crtend_so.o 
libandroid.so 

|_| libe.a 

libc.so 

libdl.so 

libEGL.so 
libGLESv1_CM.so 
libGLESv2.so 
libGLESv3.so 
libjnigraphics.so 
liblog.so 

| libm.a 

libm.so 

|_| libm_hard.a 
libmediandk.so 
libOpenMAXAL.so 
libOpenSLES.so 
|_| libstdce++.a 
libstdc++.so 





全 图 8-6 NDK 提 供 的 头 文 件 和 库 资 源 





8.4 ”完成 同一 任务 的 “集合” 


Android 系 统 中 应 用 程序 的 一 大 特色 ， 就 是 它们 不 仅 可 以 “ 装 
载 ” 众 多 系统 组 件 ， 而 且 可 以 把 这 些 组 件 跨 进 程 地 组 成 Act ivi tyTask 。 
这 个 特性 使 得 每 个 应 用 都 不 是 孤立 的 ， 从 而 能 最 大 限度 地 实现 资源 复 
用 。 举 个 例子 ， 一 个 短信 应 用 程序 至 少 会 有 “已 收 短信 列表 ”、“ 阅 读 
短信 ”和 “编辑 短信 ”3 个 子 功能 在 Android 体 系 中 它们 分 别 对 应 3 
个 Activity。 


从 程序 包 (Package) 的 组 织 角度 来 说 ， 这 3 个 元 素 只 属于 “ 短 
信 ” 这 个 程序 。 但 事实 上 ， Activity 的 设计 意图 已 经 超越 了 单一 的 进程 
概念 。 换 句 话说 ， 这 几 个 Activity 不 仅 在 “短信 ”这 一 程序 可 以 非常 方 
便 地 互相 调用 〈 比 如 用 户 在 “已 收 短信 列表 ”中 点 击 任何 一 条 短信 和 就 可 
以 进入 “短信 和 阅读”) ， 其 他 需要 使 用 “短信 ”功能 的 进程 也 能 通过 
startActivity(lntent) 来 复 用 它们 。 比 如 我 们 在 浏览 电话 本 时 ， 可 以 
将 某 个 人 的 联系 方式 通过 短信 发 送出 去 。 电 话 本 程序 并 不 需要 专门 实现 
短信 的 编辑 和 发 送 ， 只 需 填 写 这 一 请 求 (Intent) , 然后 利用 
oe 告诉 系统 ， 余 下 的 事情 就 会 有 相应 的 “志愿 
者 ”去 帮 它 


在 这 一 过 程 中 ， 系 统 先 后 启动 了 “联系 人 详情 ”和 “短信 编辑 ”两 
个 不 同 进程 中 的 Activity， 来 共同 完成 “通过 短信 发 送 联系 人 信息 ” 的 
任务 ， 这 就 是 ActivityTask 概 念 的 直观 体现 。 从 数据 结构 的 角度 来 讲 ， 
Task 有 先后 之 分 ， 所 以 源码 实现 上 采用 了 Stack 栈 的 方式 。 在 本 例 
中 ， “联系 人 详情 这 个 Activity 是 首先 启动 并 被 压 栈 的 ， 随 后 “ 栈 
项” 的 位 置 被 “短信 编辑 ”所 取代 一 一 直到 短信 发 送 完成 后 被 销毁 ， 此 
时 就 又 会 “显示 ”出 原来 的 那个 “联系 人 详情 ”的 Activity 了 。 


可 以 看 到 ， 采 用 ActivityTask 的 处 理 过 程 不 但 符合 用 户 的 逻辑 思维 
和 使 用 习惯 ， 并 且 可 以 极 大 地 复 用 系统 中 的 资源 。 如 果 当 前 系统 中 已 经 
安装 了 多 种 同 功能 的 应 用 程序 〈 比 如 有 多 款 “ 短 信 ” 应 用 存在 ) ， 还 可 
以 丰富 用 户 的 选择 (当然 如 果 Contacts 应 用 中 自 带 了 短信 编辑 和 发 送 功 
能 ， 并 强制 用 户 使 用 ， 那 么 用 户 就 没有 其 他 选择 了 ) ， 如 图 8-7 所 示 。 


Activity Task 








Contacts 


全 图 8-7 ActivityTask £4 


ActivityTask 机 制 打破 了 应 用 程序 的 常规 使 用 宽 限 ， 从 而 增强 了 用 
户 体验 。 同 时 ， 也 给 程序 的 管理 和 实现 增加 了 一 定 难度 。 上 面 已 经 说 
过 ，Task 运 用 的 是 “ 栈 ” 管 理 方式 ， 那 么 在 AMS 中 具体 是 如 何 实现 的 
Ne? 当前 系统 应 该 不 仅 有 一 个 Task， 而 是 众多 Task 的 集合 ， 这 些 Task 间 
又 有 什么 联系 ? 用 户 是 否 可 以 控制 和 调整 这 些 Task 间 的 联系 呢 ? 


回答 是 肯定 的 。Android 系 统 提 供 了 一 系列 Flag 标 志 来 允许 用 户 对 
Task 进 行 实时 调整 ， 正确 理 解 和 使 用 这 些 flag 无 疑 会 让 应 用 程序 更 贴近 
用 户 的 使 用 习惯 。 接 下 来 我 们 将 做 统一 的 讲解 。 


8. 4. 1 “后 进 先 出 ”一 一 Last In, First Out 


传统 意义 上 “ 栈 ” 的 思想 就 是 “Last In, First 0ut”。 通 俗 地 
讲 ， 就 是 “后 进 先 出 ” 先入 栈 的 元 素 会 被 讨 在 栈 底 ， 而 后 续 元 素 不 
断 往 上 堆栈 。 因 而 出 栈 时 自然 是 最 后 的 那个 元 素 在 先 ， 然 后 才 是 下 面 的 
元 素 ， 直 到 栈 底 。 





从 上 述 “ 栈 ”的 概念 来 衡量 ，Act ivityTask 并 不 能 算是 严格 意义 的 
Stack 一 一 它 在 默认 情况 下 和 栈 是 一 致 的 ， 但 比 栈 提供 了 更 多 的 操作 方 
式 ， 因 而 可 以 理解 为 “ 栈 的 一 种 变异 ”。 


我 们 再 举 个 例子 来 描述 下 Android 系 统 中 ActivityTask“ 栈 ”的 演 


变 过 程 。 


假设 在 “短信 编辑 ”这 个 Activity 中 ， 用 户 又 局 动 了 另 一 
Activity“ 选 择 表情 ”， 那 么 Activity Task 的 变化 如 图 8-8 所 示 。 





a) See ha “a 


Activity 
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全 图 8-8 Activity Task 的 演变 


在 本 例 中 ， 当 分 别 启动 “短信 编辑 ”和 “选择 表情 ”这 两 个 
Activity 时 ，Activity Task 先 后 把 它们 压 入 栈 中 。 这 样 一 旦 用 户 选 择 
了 返回 (比如 按 了 BACK 键 ) ， 栈 顶 的 元 素 就 会 被 自动 销毁 ， 然 后 开始 显 
示 新 的 栈 项 元 素 。 在 “将 联系 人 信息 发 送出 去 ”这 一 任务 的 整个 执行 过 
a 用 户 并 不 会 明显 感觉 到 应 用 程序 间 的 切换 ， 而 会 认为 “短信 编 
辑 ” 和 “选择 表情 ”也 是 属于 第 一 个 应 用 程序 的 。 





8.4.2 管理 Activity Task 


前 一 小 节 所 述 的 Activity Task 已 经 能 满足 开发 者 的 一 般 需求 ， 但 
是 在 某 些 情况 下 我 们 还 希望 拥有 更 多 的 灵活 性 。 比 如 在 启动 一 个 新 的 
Activity 时 ， 我 们 可 能 不 希望 它 和 当前 的 Activity 处 于 同一 个 Task 中 ; 
或 者 我 们 希望 当 新 的 Activity 运 行 时 ， 系 统 可 以 先 清 空当 前 的 Task 等 。 
Android 系 统 提供 了 丰富 的 接口 方法 来 满足 程序 员 的 类 似 需 求 一 一 前 面 
讲解 startActivity 时 大 家 也 已 经 有 过 接触 ， 本 小 节 将 做 更 详尽 的 介 


绍 。 





应 用 程序 可 以 通过 两 种 方法 来 影响 Activity Task 的 默认 行为 。 
方法 1: 在 <activity> 标 签 中 指定 属性 
相关 的 标签 属性 如 下 所 示 。 

e android:taskA ffinity 


Affinity 即 “喜好 ， 倾 向 ”， 它 代表 这 个 Activity 所 希望 归属 的 
Task。 在 默认 情况 下 ， 同 一 个 应 用 程序 中 的 所 有 Activity 拥 有 共同 的 
Affinity， 即 <AndroidManifest. xm1> 中 声明 的 Package Name。 当 然 也 
可 以 主动 在 <application> 中 使 用 taskAffinity 标 签 属性 来 指定 整个 应 
用 程序 的 Affinity。 


一 个 Activity Task 的 Affinity 属 性 取决 于 它 的 根 Activity。 
那么 ，taskAffinity 在 什么 情况 下 产生 效果 ? 


(1) 当 启 动 Activity 的 Intent 中 带 有 FLAG_ACTIVITY_NEW_TASK 标 
志 时 。 


在 默认 情况 下 ， 目 标 Activity 将 与 startActivity 的 调用 者 处 于 同 
一 Task 中 。 但 如 果 用 户 特别 指定 了 FLAG_ACTIVITY_NEW_TASK， 表 明 它 希 
望 为 Activity 重 新 开设 一 个 Task。 这 时 就 有 两 种 情况 : 假如 当前 已 经 有 
一 个 Task， 它 的 affinity 与 新 Activity 是 一 样 的 ， 那 么 系统 会 直接 用 此 
Task 来 完成 操作 ， 而 不 是 另外 创建 一 个 Task; 否则 系统 需要 重启 一 个 
Tasks 


(2) 当 Activity 中 的 allowTaskReparenting 属 性 设置 为 true 时 。 


在 这 种 情况 下 ，Activity 具 有 “动态 转移 ”的 能 力 。 举 个 前 面 
的 “短信 ”例子 ， 在 默认 情况 下 该 应 用 程序 中 的 所 有 Activity 具 有 相同 
的 affinity。 当 另 一 个 程序 局 动 了 “短信 编辑 ”时 ， 一 开始 这 个 
Activity 和 局 动 它 的 Activity 处 于 同样 的 Task 中 。 但 如 果 “ 短 信 编 
辑 ”Activity 指 定 了 al lowTaskReparenting， 且 后 期 “短信 ”程序 的 
Task 转 为 前 台 ， 此 时 “短信 编辑 ”这 一 Activity 会 被 “ 挪 ” 到 与 它 更 杀 
近 的 “短信 ”Task 中 。 


e android:launchMode 


用 于 指定 Activity 被 启动 的 方式 。 主 要 包括 两 方面 的 内 容 : 即 
Activity 是 否 为 单 实例 以 及 Activity 归 属 的 Task。 根 据 经 验 ， 不 少 开发 
者 认为 launchMode 比 较 容 易 混 淆 ， 所 以 建议 大 家 牢记 一 点 一 一 不 论 是 何 
种 方式 ， 最 终 被 启动 的 Activity 通 常情 况 下 都 要 位 于 Activity Task 的 
栈 顶 (因为 只 有 在 栈 顶 的 Activity 才 是 可 以 直接 与 用 户 交 互 的 ) 。 一 共 
有 4 种 1aunchMode， 如 表 8-3 所 示 。 


表 8-3 | aunchMode#¥ SZ 


默认 状态 。 这 种 模式 下 Activity 是 多 实例 
的 ， 意 味 着 系统 总 是 启动 一 个 新 的 
Activity 来 满足 要 求 即便 之 前 已 经 存 
在 该 Activity 的 实例 ; 并 且 它 归属 于 调用 
startActivity 将 其 启动 的 那个 task( 除 非 
Intent 中 明确 指明 
FLAG_ACTIVITY_NEW_TASK， 下 面 我 
们 会 讲 到 ) 











这 个 模式 和 上 面 的 standard 非 常 类 似 ， 它 
也 表明 Activity 是 多 实例 〈 除 下 面 的 情 
况 ) 的 ， 且 task 的 归属 也 一 致 。 区 别 在 






Fa 

对 于 standard， 无 论 何 时 它 都 会 生成 一 个 
新 的 Activity 实 例 ; 而 singleTop 当 过 到 目 
标 Activity 已 经 存在 于 目标 task 的 栈 顶 时 ， 
会 将 Intent 通 过 onNewIntent 传 给 这 个 
Activity 而 不 是 生成 一 个 新 的 实例 










从 名 称 可 以 看 出 来 ， 它 表明 Activity 是 单 
实例 的 ，Intent 将 通过 onNewIntent 传 送 给 
己 有 的 实例 ; 而 且 它 总 是 在 一 个 新 的 task 
中 启动 。 换 句 话说 ， 这 种 类 型 的 Activity 
永远 在 task 的 根 位 置 。 男 外 ，singleTask 人 允 
许 其 他 Activity 进 驻 到 它 所 在 的 task 中 ， 这 


一 点 和 下 面 的 singleInstance 不 同 


和 singleTask 基 本 一 致 ， 不 过 它 不 允许 其 
他 Activity 进 驻 到 它 所 属 的 task 中 。 也 就 是 
说 ，singleInstance 永 远 都 是 在 一 个 孤立 的 
task 中 


singleInstance 


e android:allowTaskReparenting 


这 个 属性 前 面 讲解 过 。 如 果 Activity 没 有 单独 指定 这 个 值 ， 那 么 它 
们 将 继承 <application> 中 的 描述 。 


e android:clearTaskOnLaunch 


清除 Task 中 所 有 除 root activity 的 元 素 。 可 想 而 知 这 个 属性 只 对 
root activity 设置 有 效 ，task 中 其 他 activity 设 置 此 属性 是 无 效 的 。 


e android:alwaysRetainTaskState 


如 果 用 户 在 一 定时 间 内 不 再 访问 Task， 比 如 说 30 分 钟 ， 那 么 系统 就 
有 可 能 会 清除 task 中 的 状态 〈 只 保留 root activity) 。 设 置 此 属性 


为 “true” 可 以 避免 这 种 情况 。 
e android:finishOnTaskLaunch 


当 Task 被 再 次 启动 时 ，activity 是 否 需要 销毁 。 这 个 属性 比 
al lowTaskReparenting 优 先 级 高 。 也 就 是 说 ， 这 种 情况 下 activity 不 会 
被 重新 指定 task， 而 是 直接 销毁 。 

方法 2: 使 用 Intent 标 志 

除了 在 标签 中 声明 task 属 性 外 ， 我 们 也 可 以 在 启动 一 个 
Activity (startActivity) 时 通过 1ntent 来 动态 指定 所 需 的 task 属 性 
值 。 大 家 可 能 会 有 疑惑 ，Activity 中 静态 标注 的 属性 和 后 面 
startActivity 所 指定 的 Intent 不 是 会 有 冲突 吗 ?” 没 错 ， 确 实 会 发 生 这 
种 情况 。 不 过 就 像 交 通 规则 一 样 ， 交 警 的 实时 手势 永远 优先 于 路 面 标 
志 ， 因 而 如 果真 的 有 冲突 则 以 Intent 为 准 即 可 。 
我 们 来 看 看 Intent 中 可 以 指定 哪些 与 Task 相 关 的 控制 信息 。 
FLAG_ACTIVITY_NEW_TASK 
这 个 和 前 面 的 sing1eTask 启 动 模式 的 作用 是 一 样 的 。 
FLAG_ACTIVITY_SINGLE_TOP 
这 个 和 前 面 的 singleTop 局 动 模式 的 作用 是 一 样 的 。 


FLAG_ACTIVITY_CLEAR_TOP 


和 上 面 两 个 不 同 ，launchMode 中 没有 与 此 对 应 的 模式 。 它 所 代表 的 
SMe: 如 果 要 启动 的 Activity 已 经 在 当前 task 中 运行 ， 那 么 所 有 在 它 
之 上 的 Activity 都 将 被 销毁 ， 并 且 1Intent 通 过 onNewlntent 传 给 它 (这 
时 它 会 被 resumed) . 


另外 还 有 几 个 Intent 标 志 对 我 们 分 析 AMS 有 帮助 ， 一 并 列 出 如 下 。 


e FLAG_ACTIVITY_NO_HISTORY 


这 个 Activity 将 不 会 被 保存 在 Hi story Stack 中 。 同 样 的 效果 也 可 
以 通过 在 AndroidManifest. xm 中 添加 “android:noHistory” 来 实现 。 


e FLAG_ACTIVITY_MULTIPLE_TASK 


个 标志 需要 和 FLAG ACTIVITY_NEW_TASK 一 同 使 用 ， 否 则 没有 效 
ee 个 现 有 的 task (比如 我 们 要 启动 的 Activity 已 
经 在 这 个 Task 中 ) 。 换 句 话 说， 系统 总 是 启动 一 个 新 的 task 来 容纳 要 局 
动 的 Activity。 

e FLAG ACTIVITY EXCLUDE_ FROM_ RECENTS 


如 果 设 置 了 这 个 标志 ， 则 Act ivity 不 会 被 放 在 系统 “最 近 局 动 的 
Activity 列 表 ” 中 。 


e FLAG_ACTIVITY_BROUGHT_TO_FRONT 
Æ launchMode F{# FA T singleTaskā, AA 动 加 上 这 个 标志 。 


e FLAG_ACTIVITY_RESET_TASK_IF_NEEDED 


使 用 此 标志 ， 当 Activity 在 新 task 中 局 动 或 者 在 已 有 task 中 局 动 ， 
都 会 处 于 task 的 上 端 。 


e FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY 


系统 自动 设置 的 ， 说 明 这 个 Activity 是 从 历史 记录 中 局 动 的 《长 按 
HOME 键 可 以 调 出 ) 。 


e FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET 


一 般 情况 下 ， 当 从 Launcher 启 动 应 用 程序 Activity 时 都 带 有 
FLAG _ACTIVITY_RESET_TASK_IF_NEEDED， 这 样 Task 中 所 有 此 Activity 上 
面 的 Activity 都 将 被 finish。 这 个 标志 就 是 辅助 完成 这 个 功能 的 。 
e FLAG ACTIVITY NO USER ACTION 


Activity 中 的 onUserLeaveHi nt 回调 用 于 指示 用 户 将 要 离开 ， 它 会 


退出 前 台 。 某 些 情 况 下 这 并 不 是 用 户主 动 选择 造成 的 。 比 如 当 系 统 有 来 
FA (Incoming Call) 或 者 阅 钟 事件 ， 由 此 弹出 的 Activity 都 不 是 用 户 
主动 去 点 击 启 动 的 ， 因而 带 上 这 个 标志 可 以 使 前 述 的 回调 浮 数 不 得 到 执 
行 。 


e FLAG_ACTIVITY_REORDER_TO_FRONT 


设置 此 标志 后 ， 如 果 将 要 局 动 的 Activity 已 经 在 Hi story Stack 中 
运行 ， 那 么 我 们 只 是 调整 其 中 的 顺序 将 其 放 到 最 前 端 。 


e FLAG ACTIVITY NO_ANIMATION 
此 标志 表示 启动 的 Activity 不 需要 应 用 动画 效果 。 
e FLAG ACTIVITY CLEAR TASK 


此 标志 将 清除 与 启动 的 Activity 相 关 task 中 的 其 他 元 素 ， 只 能 与 
FLAG ACTIVITY NEW TASK 一 起 用 。 


e FLAG_ACTIVITY_TASK_ON_HOME 
新 启动 的 Activity 将 被 放 在 task 中 Launcher 的 上 面 〈 如 果 存 在 的 


W) ， 这 样 它 返回 时 就 会 是 Launcher 了 。 此 标志 只 能 与 
FLAG_ACTIVITY_NEW_TASK 一 起 用 。 


8.5 Instrumentation 机 制 | 


谈 及 “Instrumentation”， 读 者 的 第 一 印象 可 能 是 自动 化 测试 。 
这 确实 是 它 在 Android 开 发 中 的 一 个 典型 应 用 场景 ， 不 过 
Instrumentation 还 有 其 他 不 少 强 大 的 功能 。 合 理 利 用 Instrumentat ion 
有 时 可 以 产生 意 想 不 到 的 效果 一 一 譬如 迫使 两 个 APK 运 行 于 同一 个 进程 
中 ， 从 而 达到 资源 共享 的 目的 。 


我 们 先 从 用 户 的 角度 来 讲解 如 何 使 用 Instrumentation 所 提供 的 功 
能 。 我 们 知道 ，Android 系 统 在 /system/b in 下 提供 了 很 多 “中 介 ” 程序 
来 允许 外 部 用 户 间 接 使 用 System Service， 例 如 pm、am 等 。 
Instrumentation 是 其 中 ActivityManager 的 核心 子 功能 之 一 ， 它 的 语法 
规则 如 下 : 


am instrument [-r] [-e <NAME> <VALUE>] [-p <FILE>] [-w] [--user < 


Android 官 方 对 这 些 选项 的 释义 如 表 8-4 所 示 。 


表 8-4 Instrument 各 选项 官方 释义 





Description 


O 
gz 
E. 
© 
| 
n 


print raw results (otherwise decode 
REPORT_KEY_STREAMRESULT). Use with [-e perf 
true] to generate raw output for performance 
measurements. 


E 
set argument <NAME> to <VALUE>. For test runners 
a common form is [-e <testrunner flag> <value>[, 
<value>...]] 


write profiling data to <FILE> 








-W wait for instrumentation to finish before returning. 
Required for test runners 


Specify user instrumentation runs in current user if not 


Launch the instrumented process with the selected 
ABI.This assumes that the process supports the selected 
ABI 





其 中 “-e” 用 于 指定 额外 的 参数 ， 如 下 所 示 的 常用 范例 : 


adb shell am instrument -e class com.1xs.instrument.TestCase -w c 


另外 ， 在 作为 测试 工程 使 用 时 ，<COMPONENT> 对 应 的 是 
<TEST_PACKAGE>/<RUNNER_CLASS>。 下 面 我 们 重点 关注 “-e” 和 
《COMPONENT> 的 处 理 流程 。 


用 户 发 起 的 “am instrument” 调 用 命令 将 由 
runlnstrument@am. java 负 责 解 析 ， 其 中 与 COMPONENT> 相 关 的 语句 如 
T: 


String cnArg = nextArgRequired(); 
ComponentName cn = ComponentName.unflattenFromString(cnAr 


变量 cnArg 代 表 的 是 Component 字 符 串 ， 它 可 以 通过 
unflattenFromStr ing 转 化 为 一 个 ComponentName 对 
象 。“Unflatten” 的 规则 很 简单 ， 就 是 以 “/ ”为 分 隔 符 : 前 半 部 分 成 
为 Package， 剩 余 的 就 是 Class。 


“-e” 后 面 跟随 的 所 有 [Name，Value] 将 被 保存 到 一 个 Bundle 对 象 


中 ， 并 和 其 他 参数 一 起 最 终 传 递 给 ActivityManagerService。 后 者 会 在 
与 承载 进程 建立 关联 后 (请 参考 本 书 其 他 章节 的 分 析 ) ， 由 
BindApplication@ActivityThread 来 处 理 这 些 参 数 : 


/*frameworks/base/core/java/android/app/ActivityThread.java*/ 
private void handleBindApplication(AppBindData data) {... 


if (data.instrumentationName != null) {//instrumentationN 
InstrumentationInfo ii = null; 
try { 


ii = appContext.getPackageManager(). 
getInstrumentationInfo(data.instrumentationNa 
} catch (PackageManager .NameNotFoundException e) { 


} 


mInstrumentationPackageName = ii.packageName; 


LoadedApk pi = getPackageInfo(instrApp, data.compatIn 
appContext.getClassLoader(), false, true, fal 
ContextImpl instrContext = ContextImpl.createAppConte 


try { 
java.lang.ClassLoader cl = instrContext.getClassL 


mInstrumentation = (Instrumentation) 
cl.loadClass(data.instrumentationName.getClas 
} catch (Exception e) 4.. 
} 
mInstrumentation.init(this, instrContext, appContext, 
new ComponentName(ii.packageName, ii.name), da 
data.instrumentationUiAutomationConnection) ; 


} else { 
mInstrumentation = new Instrumentation(); 
} 


try { 
Application app = data.info.makeApplication(data.rest 


mInitialApplication = app; 


try { 
mInstrumentation.onCreate(data.instrumentationArg 


catch (Exception e) 4.. 


} 


try { 
mInstrumentation.callApplicationOnCreate(app) ; 


} catch (Exception e) 4.. 
} 


} finally { 
StrictMode.setThreadPolicy(savedPolicy); 
J 


t 
AppBindData 中 保存 了 与 应 用 程序 局 动 相关 的 所 有 关键 数据 ， 其 中 


data. instrumentationArgs 对 应 的 是 “am instrument” 命 令 中 “- 

e” 所 指定 的 额外 参数 ， 而 data. ee aE “om 
instrument” 命令 中 的 <COMPONENT>， 我 们 可 以 根据 这 个 参数 构造 出 用 
户 指定 的 Instrumentation 对 象 ( 例 如 

android. test. InstrumentationTestRunner) 。 当 然 ， 如 果 应 用 程序 并 
没有 Instrumentat ion 组 件 ， 那 么 系统 会 使 用 默认 的 Instrumentation 
类 。 


由 handleBindApplication 的 处 理 罗 辑 不 难 发 现 ， 一 个 
Instrumentation 对 象 的 生命 周期 包括 但 不 限于 : 


newInstance-> init-> onCreate->onStart-> callApplicationOnCreate- 
->callActivityXXX->onDestroy->... 


这 就 是 我 们 在 本 小 节 开 头 所 说 的 ，Instrumentation 并 不 是 单纯 作 
为 一 个 测试 框架 存在 的 。 事 实 上 ，Android 官 方 对 它 的 定义 是 : 


“Base class for implementing application instrumentation 
code. When running with instrumentation turned on, this class 
will be instantiated for you before any of the application 
code, allowing you to monitor all of the interaction the 
system has with the application. An Instrumentation 
implementation is described to the system through an 
AndroidManifest. xml's <instrumentation> tag. ” 


换 句 话说 ，lnstrumentation 提 供 了 一 种 允许 用 户 获取 《及 改变 ) 
应 用 程序 与 系统 之 间 的 交互 流程 的 机 制 。 自 动 化 测试 框架 可 以 看 成 是 这 
种 机 制 的 一 种 典型 的 应 用 形式 ， 但 绝 不 是 全 部 。 
Instrumentat ionTestRunner 的 原理 框架 如 图 8-? 所 示 。 


值得 一 提 的 是 ， 在 用 户 没 有 特别 指定 自己 的 Instrumentation 的 情 
况 下 ， 它 的 很 多 行为 都 是 “ 伪 实 现 ”或 者 是 “ 透 传 ”。“ 伪 实现 ”通常 
针对 的 是 那些 Instrumentat ion 自 身 的 行为 ， 璧 如 onCreate 就 


是 “ 空 ”的 ; 


/*frameworks/base/core/java/android/app/Instrumentation. java*/ 
public void onCreate(Bundle arguments) {// 空 实现 


} 
而 “ 透 传 ” 则 主要 面向 那些 对 应 用 程序 元 素 进行 控制 的 行为 ， 例 如 


cal lActivityOnPause: 





public void callActivityOnPause(Activity activity) { 
activity.performPause();// 默 认 情 况 下 ， 将 直接 调用 Activity 元 素 的 








它们 之 间 的 关系 可 以 用 图 8-10 来 表示 。 












Application package 


InstrumentationTestRunner ia 


Test package . 


Test case classes Mock objects 










MonkeyRunner 


Instrumentation 


A 8-9 InstrumentationTestRunnet 原 理 框架 





ActivityThread 


Instrumentation(super) 


Instrumentation(override) 





全 图 8-10 


Instrumentation 和 ActivityThread 显 然 是 运行 于 同一 进程 之 中 ， 
那么 它们 是 否 还 处 于 同一 个 线程 中 呢 ? 答案 是 看 情况 一 一 默认 情况 下 的 
确 如 此 ， 但 Instrumentation 还 同时 提供 了 一 个 start 函 数 来 将 自己 “上 腾 
挪 ” 到 新 线程 中 开展 工作 ， 以 免 给 应 用 程序 “造成 不 必要 的 麻烦 ”: 


/*frameworks/base/core/java/android/app/Instrumentation.java*/ 
public void start() { 
if (mRunner != null) { 
throw new RuntimeException("Instrumentation already s 
} 


mRunner = new InstrumentationThread("Instr: " + getClass( 
mRunner.start(); 





J 


从 上 述 代码 段 中 可 以 看 到 ， 我 们 需要 首先 调 用 start 也 数 来 生成 一 
个 名 为 InstrumentationThread 的 新 线程 。 因 为 这 个 线程 在 启动 后 还 会 
回调 onStart， 所 以 自 定义 的 Instrumentation 类 所 需 完 成 的 工作 可 以 放 
在 这 个 函数 中 实现 。 


除了 本 小 节 所 阐述 的 内 容 外 ，lnstrumentation 机 制 还 有 很 多 细节 
值得 我 们 去 推 恋 ， 建 议 大 家 可 以 结合 InstrumentationTestRunner 和 以 
下 各 类 TestCase 来 做 深入 挖掘 学 习 : 


e ActivityInstrumentationTestCase2 ; 
e ActivityUnitTestCase ; 

e AndroidTestCase ; 

e ApplicationTestCase ; 

e InstrumentationTestCase ; 

e ProviderTestCase ; 

e SetviceTestCase; 

e SingleLaunchActivityTestCase. 


. 
GUI 系统 





SurfaceF|inger 


GUI (Graphical User Interface) 即 “ 图 形 用 户 界 面 ”， 可 以 说 
在 任何 0perating System 中 都 占据 着 非常 重要 的 位 置 ， 因 为 它 是 用 户 对 
操作 系统 最 直接 的 “感官 ”体验 。 一 款 优秀 的 图 形 因 面 系 统 至 少 要 满足 
以 下 几 个 条 件 。 


。 流畅 性 


我 们 认为 评判 一 款 GU1 系 统 优 劣 的 重要 准则 之 一 ， 就 是 流畅 性 。 历 
史 经 验 表 明 ， 即 便 再 “ 炫 酷 ” 的 U1 界面， 一 旦 出 现 经 常 性 的 画面 “ 江 
后 ”， 最 终 都 会 被 用 户 所 抛弃 。Google 在 这 一 方面 既是 “ 饱 受 前 
AX” Android 系 统 的 流畅 性 长 期 以 来 就 是 媒体 诉 病 的 焦点 之 一 ; 同 
Nas “AORE” 后 续 小 节 讲 述 的 “Project Butter” 就 是 其 
众多 努力 的 成 果 之 一 。 


。 友好 性 
因为 GU1 是 直接 面向 终端 用 户 的 ， 可 以 认为 是 操作 系统 的 “ 脸 
面 ”。 所 以 一 张 “ 和 羡 ” 的 脸 ， 总 是 会 比 “ 凶 神 恶 艇 ”更 “ 讨 喜 ”。 友 
好 性 意味 着 用 户 操作 上 的 人 性 化 ， 图 形 的 一 致 性 以 及 视觉 元 素 上 的 合理 
搭配 等 一 系列 因素 ， 是 一 个 综合 的 评判 标准 。 
。 可 扩展 性 


仅 有 “流畅 性 ”和 “友好 性 ”显然 还 是 不 够 的 ，GU1 的 “可 扩展 
性 ”也 同样 重要 。 扩 展 意味 着 开发 者 或 用 户 可 以 在 系统 内 建 的 基础 上 无 








限 延 伸 自 己 的 “创意 ”， 如 添加 新 的 界面 和 交互 方式 、 实 现 更 复杂 的 图 
形 处 理 功 能 等 。 

在 进入 GU1 系 统 的 学 习 前 ， 建 议 大 家 先 阅 读本 书 应 用 篇 中 “Android 
和 0penGL ES” 章 节 的 介绍 ， 并 参阅 OpenGL ES 的 官方 指南 。 因 为 
Android 的 GU1 系 统 是 基于 0penGL/EGL 来 实现 的 ， 如 果 没 有 一 定 的 基础 知 
识 作为 支撑 ， 分 析 源 码 时 有 可 能 会 “事倍功半 ”。 


9.1 OpenGL ESSEGL 


SurfaceF | inger BIA GUI ARAL, {AMOpenGL ES 的 角度 来 
讲 ， 其 实 只 能 算是 一 个 “应 用 程序 ”。 


对 于 没有 做 过 0penGL ES 开发 的 人 来 讲 ， 理 解 SurfaceFlinger 的 内 
部 原理 还 是 有 一 定 难度 的 。 不 少 读 者 对 系统 中 既 有 EGL/0penGL ES, X 
有 DisplayHardware、Gralloc、FramebufferNativeWindow 等 一 系列 陌 
生 的 模块 感到 混乱 而 无 序 。 


的 确 如 此 ， 假 如 不 先 厘 清 这 些 模块 的 相互 关系 ， 对 于 我 们 深入 研究 
整个 Android 显 示 系 统 将 是 一 个 很 大 的 障碍 。 鉴 于 此 ， 我 们 希望 先 从 杠 
染 的 高 度 来 审视 一 下 它们 之 间 错 综 复 杂 、“ 勇 不 断 理 还 乱 ” 的 依赖 关 
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(1) Linux 内 核 提供 了 统一 的 framebuffer 显 示 驱 动 。 设 备 节 
点 /dev/graphics/fb* 或 者 /dev/fb*， 其 中 fb0 表 示 第 一 个 Monitor， 当 
前 系统 实现 中 只 用 到 了 一 个 显示 屏 。 
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全 图 9-1  SurfaceFlinger 5 OpenGL ES 等 模块 的 关系 





(2) Android 的 HAL 层 提供 了 Gralloc， 包 括 fb 和 gral loc 两 个 设 
备 。 前 者 负责 打开 内 核 中 的 framebuffer 、 初 始 化 配置 ， 并 提供 了 
post 、setSwaplnterval 等 操作 接口 ; 后 者 则 管理 帧 缓冲 区 的 分 配 和 释 
放 。 这 就 意味 着 上 层 元 素 只 能 通过 Gralloc 来 间接 访问 帧 缓冲 区 ， 从 而 
保证 了 系统 对 framebuffer 的 有 序 使 用 和 统一 管理 。 


另外 ，HAL 层 的 另 一 重要 模块 是 “Composer” 一 一 如 其 名 所 示 ， 它 
为 厂商 自 定制 “U1 合成 ”提供 了 接口 。Composer 的 直接 使 用 者 是 
SurfaceFlinger 中 的 HWComposer 《有 两 个 HWComposer， 后 面 我 们 会 详细 
讲解 ) 一 一 后 者 除了 管理 Composer 的 HAL 模 块 外 ， 还 负责 VSync 信 号 的 产 
生 和 控制 。VSync 则 是 “Project Butter” 工 程 中 加 入 的 一 种 同步 机 
制 ， 它 既 可 以 由 硬件 产生 ， 也 可 以 通过 软件 来 模拟 (VsyncThread) , 
后 续 有 专门 的 小 节 进 行 介绍 。 


(3) 由 于 0penGL ES 是 一 个 通用 的 池 数 库 ， 在 不 同 的 平台 系统 上 需 
要 被 “本 地 化 ”一 一 把 它 与 具体 平台 中 的 窗口 系统 建立 起 关联 ， 这 样 才 
能 保证 正常 工作 。 从 FramebufferNat iveWindow 这 个 名 称 就 能 判断 出 
来 ， 它 就 是 负责 0penGL ES 在 Android 平 台 上 本 地 化 的 中 介 之 一 。 后 面 我 
们 还 会 看 到 Android 应 用 程序 中 所 使 用 的 另 一 个 “本 地 窗口 ”。 


为 0penGL ES 配置 本 地 窗口 的 是 EGL。 


(4) 0penGL 或 者 0penGL ES 更 多 的 只 是 一 个 接口 协议 ， 具 体 实现 既 
可 以 采用 软件 ， 也 可 以 依托 于 硬件 。 一 方面 ， 这 给 产品 开发 带 来 了 灵活 
性 一 一 我 们 可 以 根据 成 本 与 市 场 定 位 来 决定 硬件 配置 ， 满 足 各 种 用 户 需 
K; 另 一 方面 ， 既 然 有 多 种 实现 的 可 能 ， 那 么 0penGL ES 在 动态 运行 时 
是 如 何 取舍 的 呢 ? 这 也 是 EGL 的 作用 之 一 。 它 会 去 读 取 eg1. cfg 这 个 配置 
文件 ， 然 后 根据 用 户 的 设 定 来 动态 加 载 1ibagl (软件 实现 ) 或 者 
libhgl “硬件 实现 ) 。 


(5) SurfaceFlinger 中 持 有 一 个 成 员 数 组 mDi splays 来 描述 系统 中 
支持 的 各 种 “显示 设备 ”一 一 具体 有 了 哪些 Display 是 由 SurfaceF|inger 
在 readyToRun 中 判断 并 赋值 的 ， 并 且 DisplayDevice 在 初始 化 时 还 将 调 
用 eglGetDisplay、eg1CreateWindowSurface 等 接口 ， 并 利用 EQL 来 完成 
对 OpenGL ES 环境 的 搭建 。 


(6) 很 多 模块 都 可 以 调用 0penGL ES 提供 的 AP1 〈 这 些 接口 
以 “g1” 为 前 缀 ， 如 gl1Viewport、gl1Clear、gl1MatrixMode、 


glLoadidentity=$) , @#4SurfaceFlinger, DisplayDevice=s. 
(7) 与 0penGL ES 相关 的 模块 可 以 分 为 如 下 几 类 。 
。 配置 类 


即 帮助 OpenGL ES 完成 配置 的 ， 包 括 EGL、DisplayHardware 都 可 以 
归 为 这 一 类 。 


。 依赖 类 


也 就 是 0penGL ES 要 正常 运行 起 来 所 依赖 的 “本 地 化 ”的 东西 ， 
9-1 中 是 指 Framebuffer NativeWindow。 
。 使 用 类 
使 用 者 也 可 能 是 配置 者 ， 如 DisplayDevice 既 扮演 了 构建 0penGL ES 
环境 的 角色 ， 同 时 也 是 它 的 用 户 。 


如 果 读者 对 EGL 的 使 用 流程 、 工 作 方式 还 不 太 清楚 ， 强 烈 建议 先 阅 
读 官方 文档 以 及 本 书 应 用 篇 中 的 相关 章节 ， 否 则 会 影响 后 面 的 学 习 和 理 


解 。 


9.2 Android 的 硬件 接口 一 一 HAL 
前 面 章节 讲解 Android 系 统 框架 时 曾 介 绍 过 HAL 的 作用 ， 但 还 没有 对 
其 原理 进行 深入 分 析 。 对 于 Android 中 很 多 子 系统 来 说 (如 显示 系统 、 
音频 系统 等 ) ，HAL 都 是 必 不 可 少 的 组 成 部 分 一 一 HAL 是 这 些 子 系统 与 
Linux Kerne1 驱 动 之 间 通 信 的 统一 接口 。 
HAL 需 要 解决 如 下 问题 点 。 
。 硬件 接口 抽象 


HAL 并 不 是 专门 针对 荣 个 特定 的 硬件 设备 来 设计 的 ， 因 而 如 何 从 众 
多 类 型 的 设备 中 提取 出 它们 的 共同 属性 并 付 诸 软件 实现 是 一 个 关键 。 


。 接口 的 稳定 性 
、 ”可 想 而 知 ，HAL 层 的 接口 是 不 允许 频繁 更 动 的 ， 否 则 丈 失 去 了 意 


。 灵活 的 使 用 方法 


除了 上 面 两 点 外 ，HAL 还 需要 提供 一 套 灵 活 的 使 用 方法 ， 以 供 硬件 
开发 商 及 上 层 使 用 者 定制 他 们 的 需求 。 


本 小 节 接 下 来 将 围绕 上 述 3 个 关键 点 展开 讨论 。 
1. 硬件 接口 抽象 


面向 对 象 的 设计 思想 告诉 我 们 ， 这 里 的 “抽象 ”涉及 了 继承 关系 
“抽象 的 硬件 ”是 父 类 ， 而 “具体 的 硬件 ” 则 是 子 类 。 这 在 C++ 中 
很 容易 实现 ， 但 是 HAL 多 数 是 由 C 语 言 实 现 的 ， 怎 么 办 了 呢 ? 
其 实 很 简单 ， 只 要 让 子 类 数据 结构 的 第 一 个 成 员 变量 是 父 类 结构 即 
可 。 举 个 Gralloc《〈 后 面 小 节 会 有 详细 分 析 ) 中 的 例子 ， 定 义 如 下 : 
/*hardware/libhardware/include/hardware/Gralloc.h*/ 


/* Every hardware module must have a data structure named HAL_MOD 
* and the fields of this data structure must begin with hw_modul 





* followed by module specific information. 
xe 

typedef struct gralloc_module_t { 

struct hw_module_t common;// 必 须 以 此 开头 

/* 后 续 部 分 是 此 模块 的 特有 数据 */ 


int (*registerBuffer)(struct gralloc_module_t const* module,buffe 





从 注释 中 可 以 看 出 : 


首先 ， 每 一 个 硬件 模块 都 必须 有 一 个 名 称 为 HAL_MODULE_INFO_SYM 
的 变量 。 比 如 GPS 中 的 实现 : 


struct hw module _t HAL MODULE INFO SYM = { 
.tag = HARDWARE_MODULE_TAG, // 必 须 以 此 作为 tag 
.version_major = 1, 
.version_minor = 0, 
.1d = GPS_HARDWARE_MODULE_ID, 
.name = "Goldfish GPS Module", 
.author = "The Android Open Source Project", 
.methods = &gps_module_methods, 


y 


其 次 ， 此 变量 的 数据 结构 要 以 hw_module 七 〈 即 前 面 所 说 的 父 类 ) 
开头 ， 其 后 的 内 容 才 是 各 硬件 模块 特有 的 部 分 〈 即 子 类 ) 。 


从 效果 来 看 ， 上 面 的 实现 就 体现 了 继承 关系 ， 如 图 9-2 所 示 。 






hw module t 


eralloc module t 


全 图 9-2 继承 关系 


2. 接口 的 稳定 性 

对 于 某 一 类 硬件 设备 来 说 ， 它 所 提供 的 HAL 接 口 必须 是 稳定 不 变 的 
Android 系 统 已 经 预先 定义 好 了 这 些 接口 ， 硬 件 设备 商 只 需要 按照 
要 求 来 “填空 ” 即 可 。HAL 各 硬件 接口 的 定义 统一 放置 在 工程 源码 中 : 


hardware/libhardware/include/hardware 


包括 如 下 几 个 头 文件 ， 如 图 ?-3 所 示 。 





audioh audio effe audio pol bluetooth, btavh btgatth btgatcl btgattse bt. gattty bthfh 
dh oh h enth merh pesh 


bthhh = bt hh  btpanh  btrch bt sockh 


camerah camera.co cameraah camera3h fbh gpsh graloch hardware, hwcompo hwcompo keymaster lghtsh localtime. nfch powerh 


mmonh h serh serdefsh 


qemu pip gemudh sensorsih 
eh 


全 图 9-3 几 个 头 文件 


对 于 Gralloc 来 说 ， 它 的 硬件 接口 定义 如 下 : 


typedef struct gralloc_module_t { 
struct hw_module_t common; 


halh 


int (*registerBuffer)(struct gralloc_module_t const* module,b 
int (*unregisterBuffer)(struct gralloc_module_t const* module 
buffer_handle_t handle); 

int (*lock)(struct gralloc_module_t const* module, buffer_hand 
int usage, int 1, int t, int w, int h,void** vadd 

int (*unlock)(struct gralloc_module_t const* module, buffer_ha 
int (*perform)(struct gralloc_module_t const* module, int oper 
int (*lock_ycbcr)(struct gralloc_module_t const* module, buffe 
int usage, int 1, int t, int w, int h,struct androi 


/* reserved for future use */ 
void* reserved_proc[6]; 
} gralloc_module_t; 


后 续 小 节 会 对 上 述 的 一 些 重要 接口 分 别 进行 讨论 。 


3. 灵活 的 使 用 方法 


举 个 例子 ， 两 款 不 同 的 Android 手 机 设备 A 与 B， 它 们 分 别 采 用 了 
GPS1 和 GPS2 两 家 厂商 的 GPS 模块 。 那 么 需要 思考 如 下 几 个 问题 。 


。 对 于 GPS 硬件 厂商 来 说 
GPS 硬件 厂商 事先 并 不 知道 有 哪些 Android 产 


它 的 模块 ， 也 


不 可 能 为 它们 分 别 维护 一 套 代 码 ; 另外 ， 它 希望 模块 的 驱动 可 以 同时 适 
配 各 种 不 同 的 Android 版 本 〈 比 如 Android4.1、Android4. 2, 
Android4.3 和 Android4.4) 。 


此 时 HAL 的 优势 就 体现 出 来 了 一 一 GPS 厂商 〈 比 如 GPS1 和 GPS2) R= 
要 按照 Android 的 要 求 来 实现 HAL 接 口 ， 剩 下 的 事情 就 迎刃而解 了 。 


。 对 于 Android 手 机 开发 商 来 说 


通常 情况 下 ， 手 机 开发 商 只 需要 移植 GPS 硬件 厂商 提供 的 HAL 库 即 可 
(比如 GPS1 和 GPS2 的 HAL 库 ) ， 其 余 的 事情 Android 系 统 会 自动 完成 。 


。 对 于 Android 操 作 系 统 的 开发 团队 来 说 


Android 系 统 必 须 提供 完整 、 可 靠 并 且 稳 定 的 HAL 机 制 ， 来 协助 上 述 
硬件 厂商 与 手机 开发 商 的 工作 。 


综 上 所 述 ， 当 一 款 GPS 模 块 面 向 Android 市 场 时 ， 其 硬件 设计 厂商 需 
要 按照 系统 的 要 求实 现 HAL 接 口 ; 后 期 有 手机 开发 商 采用 了 此 模块 后 ， 
便 将 此 HAL 库 移植 到 自己 的 工程 项 目 中 《实际 上 就 是 把 对 应 的 库 文件 放 
置 到 系统 指定 的 路 径 中 ， 后 面 我 们 还 会 讲解 ) ; 完成 上 述 两 个 操作 后 ， 
在 设备 运行 过 程 中 Android 的 HAL 机 制 将 起 作用 ， 并 主动 到 指定 位 置 加 载 
此 GPS 的 HAL 库 。 因 为 HAL 的 接口 是 统一 的 ， 上 层 体 系 并 不 需要 做 任何 更 
改 就 可 以 成 功 控制 这 款 GPS 模 块 。 


下 一 小 节 讲 解 Gral 1oc 时 还 会 涉及 HAL， 读 者 可 以 结合 起 来 阅读 。 





9.3 Android 终 端 显示 设备 的 “化 喘 ” 


Framebuffer 


相信 做 过 Linux 开 发 的 人 对 Framebuffer 都 不 会 太 陌生 ， 它 是 内 核 系 
统 提供 的 图 形 硬件 的 抽象 描述 。 之 所 以 称 为 buffer， 是 因为 它 也 占用 了 
系统 存储 空间 的 一 部 分 ， 是 一 块 包含 屏幕 显示 信息 的 缓冲 区 。 由 此 可 
见 ， 在 “一 切 都 是 文件 ”的 Linux 系 统 中 ，Framebuffer 被 看 成 了 终端 显 
示 设 备 的 “化 身 ”。 


另外 ，Framebuffer 借 助 于 Linux 文 件 系统 癌 上 层 应 用 提供 了 统一 而 
高 效 的 操作 接口 ， 从 而 让 用 户 空 间 中 运行 的 程序 可 以 在 不 做 太 多 修改 的 
情况 下 去 适 配 多 种 显示 设备 一 一 无 论 它 们 属于 哪 家 厂商 、 什 么 型 号 ， 都 
由 Framebuffer 内 部 来 兼容 。 


在 Android 系 统 中 ，Framebuffer 提 供 的 设备 文件 节点 
是 /dev/graphics/fb*。 因 为 理论 上 支持 多 个 屏幕 显示 ， 所 以 fb 按 数字 
序号 进行 排列 ， 即 fb0、fb1 等 。 其 中 第 一 个 fb0 是 主 显示 屏幕 ， 必 须 存 
在 。 某 Android 设 备 的 fb 节点 截图 如 图 9-4 所 示 。 


GrallocS 
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Android 的 各 子 系统 通常 不 会 直接 使 用 内 核 驱动 ， 而 是 由 HAL 层 来 间 





接 引 用 底层 架构 。 显 示 系 统 中 也 同样 如 此 一 一 它 借 助 于 HAL 层 来 操作 帧 
缓冲 区 ， 而 完成 这 一 中 介 任 务 的 就 是 ral loc。 下 面 我 们 分 几 个 方面 进 
行 介绍 。 


1. Gralloc 模 块 的 加 载 


Gral 1oc 对 应 的 模块 是 由 FramebufferNativeWindow (OpenGL ES 的 
本 地 窗口 之 一 ， 后 面 小 节 有 详细 介绍 ) Aww PMA. Bl: 


hw_get_module(GRALLOC_HARDWARE_MODULE_ID, &module); 


ey {hw_get_modul ew LE (# AA 4 MAHLA O—_ixX Baha 
论 是 哪个 硬件 广 商 提 供 的 HAL 库 〈 比 如 Gralloc 库 ) ， 我 们 都 只 需要 通过 
这 个 函数 来 加 载 它 们 。 

可 以 看 到 ， 针 对 Gralloc 传 入 的 硬件 模块 1D 名 为 : 


#define GRALLOC_HARDWARE_MODULE_ID "gralloc" 


按照 hw_get_module 的 做 法 ， 它 会 在 如 下 路 径 中 查找 与 1D 值 匹配 的 
库 。 


#define HAL_LIBRARY_PATH1 "/system/lib/hw" 
#define HAL_LIBRARY_PATH2 "/vendor/1lib/hw" 


lib 库 名 有 如 下 几 种 形式 : 


gralloc.[ro.hardware].so 
gralloc.[ro.product.board].so 
gralloc.[ro.board.platform].so 
gralloc.[ro.arch].so 


或 者 当 上 述 系统 属性 组 成 的 文件 名 都 不 存在 时 ， 融 使 用 默认 的 : 


gralloc.default.so 


最 后 这 个 default 库 是 Android 原 生态 的 实现 ， 源 码 位 置 在 
hardware/1ibhardware/modules/gralloc/ 中 ， 它 由 gralloc. cpp, 
framebuffer. cpp 和 mapper. cpp 三 个 主要 源 文件 编译 生成 。 


2. Gralloc 提 供 的 接口 


Gral loc 对 应 的 HAL 库 被 成 功 加 载 后 ， 我 们 来 具体 看 看 它 所 提供 的 一 
些 重 要 接口 。 


根据 前 一 小 节 的 分 析 ，Gral loc 是 hw_module_ t 的 “ 子 类 ”。 后 者 定 
xaT: 
/*hardware/libhardware/include/hardware/Hardware.h*/ 


typedef struct hw module t { 
struct hw_module_methods_t* methods;// 一 个 HAL 库 必须 提供 的 方法 








} hw_module_t; 


typedef struct hw module methods t { 
int (*open)(const struct hw_module_t* module, const char* id, 
struct hw_device_t** device); 
} hw_module_methods_t; 


也 就 是 说 ， 任 何 硬件 设备 的 HAL 库 都 必须 实现 
hw_module_methods_t。 目 前 这 个 数据 结构 中 只 有 一 人 个 函数 指针 变量 ， 
即 open。 当 上 层 使 用 者 调用 hw_ get _module 时 ， 系 统 首 先 在 指定 目录 中 
查找 并 加 载 正 确 的 HAL 库 ， 然 后 通过 open 方 法 来 打开 指定 的 设备 。 


四 oE 文 个 例子 中 ，open 接 口 可 以 帮助 上 层 使 用 者 打开 两 种 设 
别 是 


#define GRALLOC_HARDWARE_FBO "fbg" 
LA R#def ine GRALLOC_HARDWARE_GPUO "gpu0" 


“fb0” 就 是 我 们 前 面 所 说 的 “主屏 幕 ”，gpu0 负 责 图 形 缓冲 区 的 
分 配 和 释放 。 这 两 个 设备 分 别 由 FramebufferNativeWindow 中 的 fbDev 和 
grDev 成 员 变 量 来 管理 : 


/*frameworks/native/libs/ui/FramebufferNativeWwindow.cpp*/ 
FramebufferNativeWindow: :FramebufferNativewindow( ) 

: BASE(), fbDev(0), grDev(0), mUpdateOnDemand( false) 

{... 


err 
err 


上 述 代 码 段 中 的 两 个 open 函 数 由 
hardware/| ibhardware/inc|lude/hardwareH = FAYFb. h 和 Gralloc.h 头 
文件 提供 ， 是 打开 fb 及 gral1oc 设 备 的 便捷 实现 。 可 想 而 知 ， 
framebuffer_open#lgral loc open 最 终 调 用 的 肯定 还 是 
hw_module_methods t 中 的 open 方 法 ， 只 是 函数 参数 有 所 差异 一 一 fb 对 
应 的 设备 名 为 GRALLOC_HARDWARE_FB0; gral loc 则 是 
GRALLOC_HARDWARE_GPUO. 


framebuffer_open(module, &fbDev); // 打 开 fb 设 备 
gralloc_open(module，&grDev);// 打 开 gralloc 设 备 


Android 原 生态 的 Gral loc 实 现在 
hardware/1ibhardware/modules/gralloc 中 。 读 者 会 发 现 ， 除 了 
hw_module_t#gralloc_module t 外 ， 各 硬件 厂商 还 定义 了 另 一 个 “ 私 


密 ” 的 数据 结构 ， 即 private_module t。 比 如 Gral loc 中 : 


struct private_module_t { 
gralloc_module_t base;//gralloc_module_t 中 的 第 一 个 元 素 是 hw_modul 
struct private_handle_t* framebuffer; 
uint32_t flags; 


private_module t 从 名 称 上 可 以 看 出 来 ， 它 是 该 硬件 厂商 私密 的 数 
据 部 分 。 因 而 整个 “继承 ”关系 如 图 9-5 所 示 。 





hw module 






eralloc module t 


private module t 





全 图 9-5 继承 关系 


原生 态 的 Gral loc 实 现 中 ，open 方 法 接口 对 应 的 是 
gralloc_device_open@Gral loc. cpp。 这 个 函数 会 根据 设备 名 来 判断 是 


打开 fb 还 是 gralloc 设 备 。 


/*hardware/libhardware/modules/gralloc/Gralloc.cpp*/ 
int gralloc_device_open(const hw_module_t* module, const char* na 


{ 
int status = -EINVAL; 


if (!strcmp(name, GRALLOC_HARDWARE_GPUO)) {// 打 开 gralloc 设 备 


} else { 


status = fb_device_open(module, name, device);//AW##fbi 


return status; 


先 来 大 概 看 看 framebuffer 设 备 的 打开 过 程 : 


/*hardware/libhardware/modules/gralloc/Framebuffer.cpp*/ 
int fb_device_open(hw_module_t const* module, const char* name, 
{ 
int status = -EINVAL; 
if (!strcmp(name, GRALLOC_HARDWARE_FBO)) {// 设 备 名 是 否 正 确 
fb_context_t *dev = (fb_context_t*)malloc(sizeof(*dev));/^ 
这 是 一 个 “ 索 ”*/ 
memset (dev，0,，sizeof(*dev));// 初 始 化 ， 良 好 的 编程 习惯 














dev->device.common.close = fb close ;// 这 几 个 接口 是 fb 设备 的 核心 
dev->device.setSwapInterval = fb_setSwapInterval; 
dev->device.post = fb_post; 


private_module_t* m = (private_module_t*)module; 
status = mapFrameBuffer(m);// 内 存 映 射 ， 以 及 参数 配置 
if (status >= 0) { 
*device = &dev->device.common;//“ 壳 ”和 “核心 ”的 关系 
} 
} 


return status; 


其 中 fb_context t 是 framebuffer 内 部 使 用 的 一 个 类 ， 它 包含 了 众 
多 信息 ， 而 函数 参数 devi ce 的 内 容 只 是 其 内 部 的 device. commons X 
种 “通用 和 特殊 属性 ”并 存 的 编码 风格 在 HAL 库 中 很 常见 ， 大 家 要 习 
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AHA fb context_t BAYME—mM mitzframebuffer_device_t, 


这 是 对 frambuffer 设 备 的 统一 描述 。 一 个 标准 的 fb 设备 通常 要 提供 如 下 
接口 实现 。 


o int (*post)(struct framebuffer_device_t* dev, buffer_handle_t buffer); 


将 buffer 数 据 post 到 显示 屏 上 。 要 求 buffer 必 须 与 屏幕 尺寸 一 致 ， 
并 且 没 有 被 locked。 这 样 buffer 内 容 将 在 下 一 次 VSYNC 中 被 显示 出 来 。 


o int (*setSwaplnterval)(struct framebuffer_device_t* window, int interval); 
设置 两 个 缓冲 区 交换 的 时 间 间 隔 。 


e int (*setUpdateRect)(struct framebuffer_device_t* window, int left, int top, 
int width, int height); 


设置 刷新 区 域 ， 需 要 framebuffer 驱 动 支持 “update-on- 
demand”。 也 就 是 说 ， 在 这 个 区 域外 的 数据 很 可 能 被 认为 无 效 。 


我 们 再 来 解释 下 framebuffer_device_t 中 一 些 重 要 的 成 员 变 量 ， 如 
表 9-1 所 示 。 


表 9-1 framebuffer_device t 中 的 重要 成 员 变量 





标志 位 ， 指 示 framebuffer 的 属性 配置 


framebuffer 的 宽 和 高 ， 以 像素 为 单位 





framebuffer 的 像素 格式 ， 比 如 : 


int format HAL _ PIXEL FORMAT RGBA 8888HAL _ PL 





loat xdpi;float x 和 和 y 轴 的 密度 (dot per inch) 
ydpi; 


屏幕 的 每 秒 刷新 频率 。 假 如 无 法 从 设备 获取 六 


minSwapInterval;int 1% framebuffer x FF AY se 7) A ae KAY ee HS 
maxSwapInterval; 





到 目前 为 止 ， 我 们 还 没 看 到 系统 是 如 何 打开 Kerne1 层 的 fb 设备 以 及 
如 何 对 fb 进行 配置 的 。 这 些 工 作 都 是 在 napFrameBuffer () 中 完成 的 。 这 
E EE A E 
设备 : 


"/dev/graphics/fb%u" 或 者 "/dev/fb%u" 


其 中 %u 当 前 的 实现 中 只 用 到 了 “0”， 即 当前 的 系统 实现 中 只 会 打 
开 一 个 fb 设备 (虽然 从 趋势 上 看 Android 是 要 支持 多 屏幕 显示 的 ) 。 成 
功 打 开 fb 后 ， 我 们 可 以 通过 : 


ioctl(fd, FBIOGET_FSCREENINFO, &finfo); 
ioctl(fd, FBIOGET_VSCREENINFO, &info) 


来 得 到 显示 屏 的 一 系列 参数 ， 同 时 通过 : 
ioctl (fd, FBIOPUT VSCREENINF0，&info) 来 对 底层 fb 进行 配置 。 


另外 ， 电 数 mapFrameBuffer 的 男 一 重要 任务 就 是 为 fb 设备 做 内 存 映 
主要 源码 语句 如 下 : 
void* vaddr = mmap(0, fbSize, PROT_READ|PROT_WRITE, MAP_SHARE 


module->framebuffer->base = intptr_t(vaddr); 
memset(vaddr, 0, fbSize); 


由 上 述 代码 段 可 知 ， 映 射 地 址 保存 在 module->framebuffer- 
>base。 变 量 module 对 应 的 是 前 面 


By 


o 


hw_get module (GRALLOC HARDWARE MODULE ID, &module) 得 到 的 
hw module t (被 强制 类 型 转化 为 private module t) 。 


接 下 来 再 看 看 系统 打开 gral loc 设 备 的 过 程 ， 它 相对 于 fb 简单 些 。 
如 下 所 示 : 


/*hardware/libhardware/modules/gralloc/Gralloc.cpp*/ 
int gralloc_device_open(const hw_module_t* module, const char* na 


int status = -EINVAL; 

if (!strcmp(name, GRALLOC_HARDWARE_GPUO)) { 
gralloc_context_t *dev;// 做 法 和 fb 类 似 
dev = (gralloc_ context_t*)malloc(sizeof(*dev));// 分 配 空间 
/* initialize our state here */ 
memset(dev, ©, sizeof(*dev)); 








dev->device.alloc = gralloc_alloc; // 从 提供 的 接口 来 看 ，grall 
dev->device.free = gralloc_free; 


上 述 代 码 段 中 与 fb 相似 的 部 分 我 们 就 不 多 做 介绍 了 。 因 为 gralloc 
担负 着 图 形 缓冲 区 的 分 配 与 释放 ， 所 以 它 提供 的 两 个 最 重要 的 接口 是 
alloc 和 free。 这 里 暂时 先 不 深入 分 析 ， 后 续 会 有 讲解 。 


我 们 以 图 9-6 来 对 Gral1oc 做 下 小 结 。 


oralloc.detault.so 


post 


setSwaplnterval 
sotUpdateRect 





idev/graphics/thl) 
idev/th0 


全 图 9-6 ”Gralloc 模 块 简 


9.4 Android 中 的 本 地 窗口 

在 0penGL 的 学 习 过 程 中 ， 我 们 不 断 提 及 “本 地 窗口 ” (Native 
Window) 这 一 概念 。 简 单 而 言 ，Native Window 为 0penGL 与 本 地 窗口 系 
统 之 间 搭 建 了 “桥梁 ”， 所 以 成 为 0penGL 能 否 兼 容 多 种 系统 〈 如 
Windows, Android) 的 关键 。 那 么 对 于 Android 系 统 来 说 ， 它 是 如 何 将 
OpenGL ES 本 地 化 的 呢 ? 或 者 说 ， 它 提供 了 什么 样 的 本 地 窗口 ? 


根据 整个 Android 系 统 的 GU1 设 计 理念 ， 我 们 不 难 猜 想到 至 少 需要 两 
种 本 地 窗口 。 


。 面向 管理 者 (SurfaceFlinger) 
既然 SurfaceFlinger 扮 演 了 系统 中 所 有 U1 珊 面 的 管理 者 ， 那 么 它 无 
可 厚 非 需要 直接 或 间接 地 持 有 “本 地 窗口 ”。 我 们 知道 ， 这 个 窗口 就 是 


FramebufferNativeWindow。 
。 面向 应 用 程序 
这 类 本 地 窗口 是 Surface。 


可 能 有 的 读者 会 感到 困惑 ， 一 个 系统 设计 一 种 本 地 窗口 不 就 可 以 了 
B? 为 什么 需要 两 个 甚至 更 多 呢 ? 理论 上 我 们 的 确 可 以 只 


通过 一 个 本 地 窗口 来 实现 ， 如 图 9-7 所 示 。 





Native Window 






Framebutter 





全 图 9-7 理想 的 窗口 系统 


上 面 这 个 窗口 系统 中 ， 由 Native Window 来 管理 Framebuffer 。 打 个 
比方 ，0penGL 就 像 一 台 通 用 的 打印 机 一 样 ， Peo as 就 能 
按照 要 求 输出 结果 ; 而 Native Window 则 是 “ 纸 ”， 它 是 用 来 承载 
0penQL 的 输出 结果 的 。0penGQL 并 不 介意 Native ti doy oa 
甚至 是 塑料 纸 也 没有 关系 ， 这 些 对 它 来 说 都 只 是 “本 地 窗口 ”。 


我 们 再 来 思考 下 ， 这 种 理想 模型 能 否 符合 Android 的 要 求 。 假 如 整 
个 系统 仅 有 一 个 需要 显示 U1 的 程序 ， 我 们 有 理由 相信 它 可 以 胜任 。 但 是 
如 果 有 N 个 Ul 程序 的 情况 会 怎样 呢 ? 


一 个 系统 设备 中 显然 只 会 有 一 个 帧 缓冲 区 Framebuffer， 而 按 
照 “ 理 想 窗 口 系 统 ” 的 设计 ， 每 个 应 用 程序 都 需要 各 自 使 用 和 管理 
Framebuffer 其 结果 就 会 像 “ 幼 儿 园 ”的 几 个 小 朋友 共用 一 块 画 板 
来 涂鸦 一 样 ， 可 谓 “ 五 彩 斑 澜 ”“ 创 意 无 限 ”。 


那么 该 如 何 改进 呢 ? 如 图 9-8 所 示 。 





OpenGL ES OpenGL ES OpenGL ES 


NativeWindow-2 ativeWindow-2 
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全 图 09-8 改进 的 窗口 系统 





在 这 个 改进 的 窗口 系统 中 ， 我 们 有 了 两 类 本 地 窗口 ， 即 
NativeWindow-1 和 NativeWindow-2。 第 一 类 窗口 是 能 直接 显示 在 终端 屏 
幕 上 的 一 一 它 使 用 了 帧 缓冲 区 ; 而 后 一 类 本 地 窗口 实际 上 是 从 内 存 缓冲 
区 中 分 配 的 空间 。 


当 系 统 中 存在 多 个 需要 显示 U1 的 应 用 程序 时 ， 一 方面 这 种 改进 设计 
保证 了 它们 都 能 获得 一 个 “本 地 窗口 ”; 另 一 方面 这 些 “ 本 地 窗口 ”也 
都 可 以 被 有 序 地 显示 到 终端 屏幕 上 一 一 因为 SurfaceF1linger 会 收集 所 有 
程序 的 显示 需求 ， 对 它们 进行 统一 的 图 像 混 合 操 作 ， 然 后 输出 到 自己 的 
NativeWindow-1 上 。 


当然 ， 这 个 改进 的 窗口 系统 有 一 个 前 提 ， 即 应 用 程序 与 
SurfaceFlinger 都 是 基于 0penGL ES 来 实现 的 。 有 没有 其 他 选择 呢 ? = 
案 是 肯定 的 。 比 如 应 用 程序 完全 可 以 采用 Skia 等 第 三 方 的 图 形 库 ， 只 
它们 与 SurfaceFlinger 间 的 “协议 ”保持 不 变 即 可 ， 如 图 9-9 所 示 。 
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全 图 9-9 另 一 类 改进 的 窗口 系统 


从 理论 上 来 说 ， 上 述 两 类 改进 的 窗口 系统 都 是 可 行 的 。 不 过 对 于 开 
发 人 员 ， 特 别 是 没有 0penGL ES 项 目 经 验 的 人 而 言 ， 前 一 类 改进 方案 的 
门槛 相对 较 高 。 而 事实 上 ，Android 系 统 同时 提供 了 这 两 种 方案 来 供 上 
层 选择 。 正 常情 况 下 我 们 按照 SDK 向 导 生成 的 APK 应 用 程序 ， 属 于 后 面 的 
情况 ; 而 对 于 希望 使 用 0penGL ES 来 完成 复杂 表面 浑 染 的 应 用 开发 者 来 


说 ， 也 可 以 使 用 Android 系 统 封 装 的 GLSurfaceView (或 其 他 方式 ) 来 达 
到 目标 。 


在 接 下 来 的 源码 分 析 中 ， 我 们 将 对 本 小 节 提 及 的 “改进 系统 ”做 进 


一 步 验 证 。 
9.4.1 FramebufferNativeWindow 

我 们 知道 ，EGL 需 要 通过 本 地 窗口 来 为 OopenGL/0penGL ES 创造 环 
境 。 其 函数 原型 如 下 : 


EGLSurface eglCreateWindowSurface( EGLDisplay dpy, EGLConfig con 
NativeWindowTypewindow, const EGLint *attrib_list); 


显然 不 论 是 哪 一 类 本 地 窗口 ， 都 必须 要 与 Nati veWindowType 保 持 一 
致 ， 否 则 就 无 法 正常 使 用 EGL 了 。 先 从 数据 类 型 的 定义 来 看 看 这 个 
window 人 参数 有 什么 特别 之 处 : 


/*frameworks/native/opengl/include/egl/Eglplatform.h*/ 
typedef EGLNativeWindowType NativewindowType;// 注 意 这 两 种 数据 类 型 其 : 


#if defined(_WIN32) || defined(__VC32__) && !defined(__CYGWIN__ ) 
/* Win32 和 WinCE 系 统 下 的 定义 */ 





typedef HWND EGLNativeWindowType; 
#elif defined(__WINSCW__) || defined(__SYMBIAN32__) /* Symbian 系 : 


typedef void *EGLNativeWindowType; 
#elif defined(__ANDROID__) || defined(ANDROID)/* Android 系 统 */ 
struct ANativeWindow; 


typedef struct ANativeWindow* EGLNativeWindowType; 
#elif defined(__unix__)/* UNIX 系 统 */ 

typedef Window EGLNativeWindowType; 

#else 


#error "Platform not recognized" 
#endif 


我 们 以 表 9-2 来 概括 在 不 同 的 操作 系统 平台 下 EGLNativeWindowType 
所 对 应 的 具体 数据 类 型 。 


9-2 不 同 操作 系统 平台 下 的 EGLNat i veWindowType 


操作 系统 数据 类 型 


Win32, WinCE HWND， 即 句柄 
pee ee 


FHF OpenGL ES 并 不 是 只 针对 某 一 个 特定 的 操作 系统 平台 设计 的 ， 
因而 需要 考虑 兼容 性 和 可 移植 性 。 这 个 EGLNat iveWindowType 就 是 一 个 
例子 ， 它 在 不 同 的 系统 中 对 应 的 是 不 同 的 数据 类 型 ， dae ce 
的 是 ANativeWindow 指 针 。 





ANativeWindow 的 定义 在 Window. h 头 文件 中 : 


/*system/core/include/system/Window.h*/ 
struct ANativeWindow 
{... 
const uint32_t flags; // 与 Surface 或 updater 有 关 的 属性 
const int minSwapInterval;// 所 支持 的 最 小 交换 间隔 时 间 
const int maxSwapInterval;// 所 支持 的 最 大 交换 间隔 时 间 
const float xdpi; // 水 平方 向 的 密度 ， 以 dpi 为 单位 
const float ydpi;// 垂 直方 向 的 密度 ， 以 dpi 为 单位 
intptr_t oem[4];// 为 OEM 定 制 驱 动 所 保留 的 空间 
int (*setSwapInterval)(struct ANativeWindow* window, int inte 
int (*dequeueBuffer)(struct ANativeWindow* window, 
struct ANativeWindowBuffer** buffer, int* fenceFd 
int (*queueBuffer)(struct ANativeWindow* window, 











struct ANativeWindowBuffer* buffer, int fenceFd); 
int (*cancelBuffer)(struct ANativeWindow* window, 

struct ANativeWindowBuffer* buffer, int fenceFd); 
int (*query)(const struct ANativeWindow* window,int what, int 
int (*perform)(struct ANativeWindow* window, int operation, 
void* reserved_proc[2]; 


P 我 们 在 表 9-3 中 详细 解释 ANativeWindow 这 个 数据 结构 中 的 几 个 重要 
RAR 


表 9-3 ANat iveWindow 成 员 函 数 解析 


Member 
Function 








EGL 通 过 这 个 接口 来 申请 一 个 buffer。 从 前 面 我 们 所 举世 
含 的 buffer 很 可 能 不 止 一 份 


当 EGL 对 一 块 buffer 演 染 完 成 后 ， 它 调用 这 个 接口 来 unlo 





这 个 接口 可 以 用 来 取消 一 个 已 经 dequeued 的 buffer， 但 要 


用 于 向 本 地 窗口 咨询 相关 信息 


用 于 执行 本 地 窗口 文 持 的 各 种 操作 ， 比 如 : 


NATIVE_WINDOW_SET_USAGENATIVE_WINDOW_S 


F 





从 上 面 对 ANativeWindow 的 描述 可 以 看 出 ， 它 更 像 一 份 “ 协 议 ”， 


规定 了 一 个 本 地 窗口 的 形态 和 功能 。 这 对 于 支持 多 种 本 地 窗口 的 系统 是 
必需 的 ， 因 为 只 有 这 样 我 们 才能 针对 某 种 特定 的 平台 窗口 来 填充 具体 的 
实现 。 


这 个 小 节 中 我 们 需要 分 析 FramebufferNat iveWindow 是 如 何 履 行 这 
份 “协议 ”的 。 


FramebufferNativeWindow 本 身 代码 并 不 多 ， 下 面 分 别 选 取 其 构造 
函数 及 dequeue 也 数 来 分 析 。 其 他 部 分 的 实现 都 类 似 ， 大 家 可 以 参考 阅 
读 。 


1. FramebufferNativeWindow74 7% f žk 


根据 FramebufferNativeWindow 所 完成 的 功能 ， 可 以 大 概 推测 出 它 
的 构造 函数 里 应 该 至 少 完成 如 下 初始 化 操作 。 


° 加 载 GRALLOC_HARDWARE_MODULE_1D 模 块 ， 详 细 流 程 在 Gral loc 
小 节 已 经 解释 过 了 。 


° 分 别 打 开 fb 和 gral loc 设 备 。 我 们 在 Gral loc 小 节 也 已 经 分 析 
过 ， 打 开 后 的 设备 由 全 局 变量 fbDev 和 grDev 管 理 。 


根据 设备 的 属性 来 给 FramebufferNat iveWindow 赋 初 值 。 


e 根据 FramebufferNativeWindow 的 实现 来 填充 ANat i veWi ndow 中 
的 “协议 ”。 


° 其 他 一 些 必 要 的 初始 化 。 
下 面 从 源码 的 角度 来 分 析 上 述 每 个 步骤 具体 是 怎么 实现 的 : 


/*frameworks/native/libs/ui/FramebufferNativewindow.cpp*/ 
FramebufferNativeWindow: :FramebufferNativewindow( ) 
: BASE(), fbDev(0), grDev(0), mUpdateOnDemand( false) 


hw_module_t const* module; 

if (hw_get_module(GRALLOC_HARDWARE_MODULE_ID, &module) == 0) 
int stride; 
int err; 
int 1; 


err framebuffer_open(module, &fbDev); 
err = gralloc open(module，&grDev);// 分 别 打开 fb 和 gral1oc 
/* 上 面 这 部 分 内 容 我 们 在 前 几 个 小 节 已 经 分 析 过 了 ， 不 清楚 的 可 以 回头 看 一 下 


if(fbDev->numFramebuffers >= MIN_NUM_FRAME_BUFFERS && 
fbDev->numFramebuffers <= MAX_NUM_FRAME_BUFFERS) {//tRd# 
mNumBuffers = fbDev->numFramebuffers; 

} else { 
mNumBuffers = MIN _NUM_FRAME_BUFFERS; ,;// 和 否则 就 采用 最 少 的 bu 

} 


mNumFreeBuffers = mNumBuffers;// 可 用 的 buffer 个 数 ， 初 始 时 是 所 和 
mBufferHead = mNumBuffers-1; 











for (i = 0; i < mNumBuffers; i++) // 给 每 个 buffer 初 始 化 





buffers[i] = new NativeBuffer(fbDev->width, fbDev->he 
GRALLOC_USAGE _HW_FB); 
}//NativeBuffer 是 什么 ? 

















for (i = ©; i < mNumBuffers; i++) // 给 每 个 buffer 分 配 空间 


err = grDev->alloc(grDev, fbDev->width, fbDev->height 
GRALLOC USAGE HW_ FB, &buffers[i]->handle, 


/* 为 本 地 窗口 赋 属 性 值 */ 
const_cast<uint32_t&>(ANativeWindow::flags) = fbDev->flag 
const_cast<float&>(ANativewindow: :xdpi) = fbDev->xdpi; 
const_cast<float&>(ANativewindow: :ydpi) = fbDev->ydpi; 
const_cast<int&>(ANativeWindow: :minSwapInterval) =fbDev-> 
const_cast<int&>(ANativeWindow: :maxSwapInterval) = fbDev- 

} else { 
ALOGE("Couldn't get gralloc module"); 








} 

/* 以 下 代码 段 开 始 履行 窗口 “协议 ”*/ 

ANativeWindow: :setSwapInterval = setSwapInterval; 
ANativeWindow: :dequeueBuffer = dequeueBuffer; 

ANativeWindow: :queueBuffer = queueBuffer; 

ANativeWindow: :query = query; 

ANativewindow: :perform = perform; 

/* 下 面 这 几 个 接口 已 经 被 废弃 了 ， 不 过 为 了 保持 兼容 性 ， 暂 时 还 是 保留 的 */ 
ANativeWindow: :dequeueBuffer_DEPRECATED = dequeueBuffer_DEPRE 
ANativeWindow: :lockBuffer_DEPRECATED = lockBuffer_DEPRECATED; 
ANativeWindow: :queueBuffer_DEPRECATED = queueBuffer_DEPRECATE 























a 


这 个 浮 数 逻辑 上 很 简单 ， 开 头 一 部 分 我 们 已 经 分 析 过 ， 此 处 不 再 效 


述 。 需 要 重点 关注 的 是 FramebufferNativeWindow 是 如 何 分 配 buffer 
的 。 换 句 话说 ， 其 dequeue 方 法 所 获得 的 缓冲 区 是 从 何 而 来 的 。 


成 员 变 量 mNumBuffers 代 表 了 FramebufferNativeWindow 所 管理 的 


buffer 总 数 。 它 取决 于 两 个 方面 : 首先 从 fb 设备 中 取 值 ， 即 
numFramebuffers; 否则 就 默认 定义 为 MIN_NUM_FRAME_BUFFERS。 如 下 所 


7R: 


#define MIN_NUM_FRAME_BUFFERS 2 
#define MAX_NUM_FRAME_BUFFERS 3 


可 见 Android 系 统 认 为 最 少 的 buffer 数 为 2， 最 大 为 3。 


有 人 可 能 会 党 得 奇怪 ， 既 然 FramebufferNativeWindow 对 应 的 是 真 
实 的 物理 屏幕 ， 那 么 为 什么 EEA ur or NE? 


假设 我 们 需要 绘制 这 样 一 个 UI 画面 ， 包 括 两 个 三 角形 和 3 个 圆 形 ， 
cae 10 所 示 。 


全 图 9-10 希望 在 屏幕 上 显示 的 完整 结果 


接 下 来 大 家 可 以 思考 下 只 采用 一 个 buffer 时 的 情况 。 这 意味 着 我 们 
是 直接 以 屏幕 为 画板 来 实时 做 画 一 一 我 们 画 什么 ， 屏 幕 上 就 显示 什么 。 
以 图 9-10 为 例 ， 如 果 每 一 个 三 角形 或 圆 形 都 需要 0. 5s 的 绘图 时 间 ， 那 么 
总 计 耗 时 应 该 是 0. 5*5=2. 5s。 换 名 话说， 不同 时间 点 时 用 户 在 屏幕 上 所 
看 到 的 画面 如 图 9-11 所 示 。 
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全 图 9-11 只 采用 一 个 buffet 的 情况 


对 于 用 户 来 说 ， 将 看 到 一 个 不 断 刷 新 的 画面 。 遂 俗 地 讲 ， 就 是 画面 
很 “ 卡 ”。 特 别 是 对 于 图 像 刷新 很 频繁 的 场景 “比如 大 型 游戏 ) ， 用 户 
的 体验 就 会 更 差 。 那 么 ， 有 什么 解决 的 办 法 呢 ? 我 们 知道 ， 出 现 这 种 现 
象 的 原因 就 是 程序 直接 以 屏幕 为 绘图 板 ， 把 还 没有 准备 就 绪 的 图 像 直 接 
呈现 给 了 用 户 。 换 名 话说 ， 如 果 可 以 等 到 整 幅 图 像 绘制 完成 以 后 再 刷新 
到 屏幕 上 ， 那 么 用 户 在 任何 时 候 看 到 的 都 是 正确 而 完整 的 画面 ， 问 题 也 
就 解决 了 。 图 9-12 解 释 了 采用 两 个 缓冲 区 时 的 情况 。 





ARDA 





全 图 9-12 采用 两 个 缓冲 区 的 情况 


图 9-12 中 所 阐述 的 就 是 通常 所 称 的 “ 双 缓 冲 ” (Double- 
Buffering) 技术 。 除 此 之 外 ， 其 实 还 有 三 缓冲 (Triple 
Buffering) 、 四 缓冲 (Quad Buffering) 等 ， 我 们 将 它们 统称 为 “多 
缓冲 ” (Multiple Buffering) 机 制 |。 


理解 了 为 什么 需要 双 缓 冲 以 后 ， 我 们 再 回 过 头 来 看 
FramebufferNativeWindow 的 构造 国 数 。 接 下 来 要 解决 的 另 一 个 问题 
E: 多 个 缓冲 区 空间 是 从 哪里 分 配 的 ? 通过 前 几 个 小 节 的 知识 可 知 ， 应 
该 是 要 向 HAL 层 的 Gralloc 申 请 。 


FramebufferNativeWindow 构 造 国 数 中 的 第 一 个 for 循 环 里 先 给 各 
buffer 创 建 相应 的 实例 (new NativeBuffer) ， 其 中 的 属性 值 都 来 源 于 
fbDev， 如 宽 、 高 、 格 式 等 。 紧 随 其 后 的 就 是 调用 Gralloc 设 备 的 


alloc() 方 法 : 


err = grDev->alloc(grDev, fbDev->width, fbDev->height, fbDev->for 
GRALLOC_USAGE_HW_FB, &buffers[i]->handle, &buffers[i]->stride); 


注意 第 5 个 参数 ， 它 代表 所 要 申请 的 缓冲 区 的 用 途 ， 定 义 在 
hardware/|ibhardware/include/ hardware/Gralloc.h 中 ， 目 前 已 经 支 
持 几 十 种 。 比 如 : 

e GRALLOC_USAGE_HW_TEXTURE 
缓冲 区 将 用 于 0penGL ES Texture. 

e GRALLOC_USAGE_HW_RENDER 
缓冲 区 将 用 于 0penGL ES 的 泻 染 。 

e GRALLOC_USAGE_HW_2D 
缓冲 区 会 提供 给 2D 硬件 图 形 设备 。 

e GRALLOC_USAGE_HW_COMPOSER 
缓冲 区 用 于 HWComposer HAL 模 块 。 

e GRALLOC_USAGE_HW_FB 

缓冲 区 用 于 framebuffer 设 备 。 

e GRALLOC_USAGE_HW_VIDEO_ENCODER 
缓冲 区 用 于 硬件 视频 编码 器 。 


这 里 申请 的 缓冲 区 是 要 在 终端 屏幕 上 显示 的 ， 所 以 申请 的 usage 类 
型 是 GRALLOC_USAGE_HW_FB， 对 应 的 Gralloc 中 的 实现 是 
gralloc alloc framebuffer@Gralloc. cpp: 假如 是 其 他 用 途 的 缓冲 区 
申请 ， 则 对 应 gral loc alloc buffer@Gralloc. cpp。 不 过 ， 如 果 底 层 只 


允许 一 个 buffer 〈 不 支持 page-flipping 的 情况 ) , AA 
gralloc alloc framebuffer 也 同样 可 能 只 返回 一 个 ashmem 中 申请 
的 “内 存 空 间 ”， 真 正 的 “ 帧 缓冲 区 ” 则 要 在 post 时 才 会 被 用 到 。 


所 有 申请 到 的 缓冲 区 都 需要 由 FramebufferNativeWindow 中 的 全 局 
变量 buffers [MAX_NUM_FRAME_BUFFERS] 来 记录 ， 每 个 数据 元 素 是 一 个 
NativeBuffer 。 这 个 类 的 定义 如 下 : 


class NativeBuffer : public ANativeObjectBase<ANativewindowBuf fer 
NativeBuffer, LightRefBase<NativeBuffer>> 
{... 


可 见 这 个 “本 地 缓冲 区 ”继承 了 ANat iveWindowBuffer 的 特性 ， 后 
者 的 定义 在 /system/core/ include/system/Window. h: 


typedef struct ANativeWindowBuf fer 


int width; // 
int height;//im 


buffer_handle_t handle;/* 代 表 内 存 块 的 句柄 ， 比 如 ashmem 机 制 。 可 以 参考 


} ANativewindowBuffer_t; 


另外 ， 当 前 可 用 〈free) 的 buffer 数 量 由 mNumFreeBuffers 管 理 ， 
这 个 变量 的 初始 值 也 是 mNumBuffers， 即 总 共有 2 或 3 个 可 用 缓冲 区 。 在 
程序 后 续 的 运行 过 程 中 ， 始 终 由 mBufferHead 来 指向 下 一 个 将 被 申请 的 
buffer 〈 注 意 : 不 是 下 一 个 可 用 buffer) 。 也 就 是 说 ， 每 当 用 户 向 
FramebufferNativeWindow 申 请 一 个 buffer 时 〈dequeueBuffer) ， 这 个 
mBufferHead 就 会 增加 1; 一 旦 它 的 值 超过 最 大 值 ， 则 还 会 变 成 0， 如 此 
就 实现 了 循环 管理 。 后 面 在 讲解 dequeueBuffer 时 绸 详细 解释 。 


一 个 本 地 窗口 包含 了 很 多 属性 值 ， 如 各 种 标志 (flags) 、 横 纵 坐 
标的 密度 值 等 。 这 些 数值 都 可 以 从 fb 设备 中 查询 到 ， 我 们 需要 将 它们 赋 
子 刚 生成 的 FramebufferNativeWindow 实 例 的 属性 。 


最 后 ， 就 应 该 履行 ANativeWindow 的 接口 协议 了 。 
FramebufferNativeWindow 会 将 其 对 应 的 成 员 函 数 逐 个 填充 到 
ANat iveWindow 的 函数 指针 中 。 上 比如: 


ANativeWindow: :setSwapInterval = setSwapInterval; 


ANativeWindow: :dequeueBuffer = dequeueBuffer ; 


这 样子 0penGL ES 才能 通过 一 个 ANat iveWi ndow 来 与 本 地 窗口 系统 建 
立正 确 的 连接 。 下 面 我 们 详细 分 析 其 中 dequeueBuffer 的 实现 。 


2. dequeueBuffer 


这 个 函数 虽然 很 得 《只 有 二 十 几 行 ) ， 却 是 
FramebufferNativeWindow 中 的 核心 。0penGL ES 就 是 通过 它 来 分 配 一 个 
可 用 于 浑 染 的 缓冲 区 的 : 


int FramebufferNativeWindow: :dequeueBuffer (ANativeWindow* window, 


{ 
FramebufferNativewindow* self = getSelf(window); /*Step1*/ 


Mutex::Autolock _1(self->mutex);/*Step2*/ 


/*Step3. 计算 mBufferHead */ 

int index = self->mBufferHead++; 

if (self->mBufferHead >= self->mNumBuffers ) 
self->mBufferHead = 0;// 循 环 


/*Step4. 如 果 当 前 没有 可 用 缓冲 区 */ 
while (!self->mNumFreeBuffers) { 
self->mCondition.wait(self->mutex); 


} 

/*Step5. 如 果 有 人 释放 了 缓冲 区 */ 

self ->mNumFreeBuffers- -; 

self ->mCurrentBufferIndex = index; 
*buffer = self->buffers[index].get(); 
*fenceFd = -1; 

return 0; 


Step1@FramebufferNat i veWindow: :dequeueBuffer， 这 里 先 将 入 参 
中 ANativeWindow 类 型 的 变量 window 强 制 转化 为 
FramebufferNativeWindow。 因 为 前 者 是 后 者 的 父 类 ， 所 以 这 样 的 转化 
当然 是 有 效 的 。 不 过 细心 的 读者 可 能 会 发 现 ， 为 什么 函数 入 参 中 还 要 特 
别传 入 一 个 ANat iveWindow 对 象 的 内 存 地 址 ， 直 接 使 用 
FramebufferNativeWindow 的 thi s 指 针 不 行 吗 ? 这 么 做 很 可 能 是 为 了 兼 
容 各 种 平台 。 大 家 应 该 注意 到 ANativeWindow 是 一 个 Struct 数 据 类 型 ， 
而 在 C 语 言 中 Struct 是 没有 成 员 函 数 的 ， 所 以 我 们 通常 是 用 函数 指针 的 


形式 来 模拟 一 个 成 员 上 函数 ， 如 这 个 dequeueBuffer 在 ANativeWindow 的 定 
义 就 是 一 个 函数 指针 ， 而 且 系统 并 没有 办 法 预先 知道 最 终 填 充 到 
ANativeWindow 中 的 函数 指针 实现 如 

FramebufferNativeWindow: :dequeueBuffer) 里 是 否 可 以 使 用 this 指 
针 ， 所 以 在 参数 中 带 入 一 个 window 变 量 就 是 必要 的 。 


Step2@ FramebufferNativeWindow: :dequeueBuffer， 获 得 一 
Mutex 锁 。 因 为 接 下 来 的 操作 涉及 资源 互 扩 区， 自然 需要 有 一 个 保护 措 
施 。 这 里 采用 的 是 Autolock， 意 味 着 dequeueBuffer 函数 结束 后 会 自动 
释放 Mutex。 


Step3@ FramebufferNativeWindow: :dequeueBuffer， 前 面 我 们 介 
绍 过 mBufferHead 变 量 ， 这 里 来 看 看 它 的 实际 使 用 。 首 先 index 得 到 的 是 
mBufferHead 所 代表 的 当前 位 置 ， 然后 mBufferHead 增 加 1。 由 于 我 们 是 
循环 利用 多 个 缓冲 区 的 ， 所 以 如 果 这 个 变量 的 值 大 于 或 等 于 
mNumBuffers， 那么 就 需要 把 它 置 为 0(。 也 就 是 说 ，mBufferHead 的 值 永 
远 只 能 是 [0- 2] 中 的 一 i 


Step4@ FramebufferNativeWindow: :dequeueBuffer, mBufferHead 
并 不 代表 它 所 指向 的 缓冲 区 是 可 用 的 。 假 如 当前 的 mNumFreeBuffers 表 
明 已 经 没有 多 余 的 缓冲 区 空间 ， 那 么 我 们 就 需要 等 待 有 8 人 释放 buffer 后 
才能 继续 操作 。 这 里 使 用 到 Condition 这 一 同步 机 制 ， 如 果 读 者 感觉 不 
熟悉 请 参考 本 书 进 程 章 节 的 详细 描述 。 可 以 肯定 的 是 ， 这 里 调用 了 
mCondition. wait， 那 么 必然 有 其 他 地 方 要 唤醒 它 一 一 具体 的 就 是 在 
queueBuffer () 中 ， 大 家 可 以 验证 下 是 否 如 此 。 


Step5@ FramebufferNativeWindow: :dequeueBuffer， 一 旦 成 功 获 
取 到 一 个 buffer 后 ， 程 序 要 把 可 用 的 buffer 计 数值 减 
1 (mNumFreeBuffers--) 。 另 外 mBufferHead 前 面 已 经 做 过 自 增 (++) 
处 理 ， 这 里 就 不 用 再 做 特别 工作 。 


这 样 我 们 就 完成 了 Android 系 统 中 FramebufferNativeWindow 本 地 窗 
口 的 分 析 。 接 下 来 的 小 节 将 继续 讲解 男 一 个 重要 的 Native Window。 


9.4.2 应 用 程序 端的 本 地 窗口 一 一 Surface 


针对 应 用 程序 端的 本 地 窗口 是 Surface， 和 
FramebufferNativeWindow 一 样 ， 它 必须 继承 Anati i veWindow: 


class Surface 
: public ANativeObjectBase<ANativeWindow, Surface, RefBase> 


这 个 本 地 窗口 当然 也 需要 实现 ANativeWindow 所 制定 的 “协议 ”， 
我 们 关注 的 重点 是 它 与 前 面 的 FramebufferNativeWindow 有 什么 不 同 。 
Surface 的 构造 函数 只 是 简单 地 给 ANative Window: :dequeueBuf fer = rA 
数 指 针 及 内 部 变量 赋 了 初 值 。 由 于 整个 函数 的 功能 很 简单 ， 我 们 只 摘录 
部 分 核心 内 容 : 


/*frameworks/native/libs/gui/Surface.cpp*/ 

Surface: :Surface(const sp<IGraphicBufferProducer>& bufferProducer 

{/* 给 ANativeWwindow 中 的 函数 指针 赋值 */ 
ANativeWindow: :setSwapInterval 
ANativeWindow: :dequeueBuf fer 





hook_setSwapInterval; 
hook_dequeueBuf fer ; 


/* 为 各 内 部 变量 赋值 ， 因 为 此 时 用 户 还 没有 发 起 申请 ， 所 以 大 部 分 变量 的 初始 值 是 6 
mReqwidth = 0; 
mReqHeight = 0; 


mDefaultwWidth = 0; 
mDefaultHeight = 0; 
mUserWidth = 0; 
mUserHeight = 0;... 


Surface 是 面向 Android 系 统 中 所 有 UI 应 用 程序 的 ， 即 它 承 担 着 应 用 
进程 中 的 U1 显示 需求 。 基于 这 点 ， 可 以 推测 出 其 内 部 实现 至 少 要 考虑 以 
BILE 

。 面向 上 层 实现 (主要 是 Java 层 ) 提供 绘制 图 像 的 “画板 


前 面 说 过 ， 这 个 本 地 窗口 分 配 的 内 存 空间 不 属于 帧 缓冲 区 ， 那 么 具 
体 是 由 谁 来 分 配 的 ， 又 是 如 何 管 理 的 呢 ? 


e 它 与 SurfaceFlinger 间 是 如 何 分 工 的 
显然 SurfaceFlinger 需 要 收集 系统 中 所 有 应 用 程序 绘制 的 图 像 数 
据 ， 然 后 集中 显示 到 物理 屏幕 上 。 在 这 个 过 程 中 ，Surface 扮 演 了 什么 
样 的 角色 呢 ? 


我 们 先 来 解释 下 这 个 类 中 一 些 重要 的 成 员 变 量 ， 如 表 9-4 所 示 。 


表 9-4 


sp<IGraphicBufferProducer> 
mGraphicBufferProducer 


BufferSlot 
mSlots[NUM_BUFFER_SLOTS] 


uint32_t mReqWidth 


这 个 变量 是 Surface 的 核心 ， 很 
多 “协议 ”就 是 通过 它 实 现 的 ， 
后 面 会 有 详细 讲解 。 值 得 一 提 
的 是 ， 它 已 经 多 次 改名 ，4.1 的 
版 本 中 叫 作 mSurfaceTexture， 
后 更 名 为 mBufferProducer， 而 
目前 最 新 版 本 则 是 
mGraphicBufferProducer。 从 中 
也 可 以 看 出 ，Google 开 发 人 员 
希望 为 它 取 一 个 更 容易 理解 的 
名 称 。“Producer” 很 好 地 解释 了 
这 个 变量 的 作用 








从 名 称 上 不 难看 出 ， 
Surface 内 部 用 Lae 的 地 


NUM_BUFFER_SLOTS 最 多 可 
达 32 个 。BufferSlot 类 的 内 部 又 
由 一 个 GraphicBuffer 和 一 个 
dirtyRegion 组 成 ， 当 用 户 
dequeueBuffer 时 才 会 分 配 真正 


Surface 中 有 多 组 相似 的 - 
量 它们 之 间 是 有 区 别 的。 











pms mReqHeight | | 


和 上 面 两 个 变量 类 似 ， 这 是 指 
下 次 dequeue 时 将 会 申请 的 
buffer 的 像素 格式 ， 初 始 值 是 
PIXEL FORMAT RGBA 8888 


uint32_t mReqFormat 






指 下 次 dequeue 时 将 会 指定 的 
usage 类 型 


Crop 表 示 “ 修 剪 ”， 这 个 变量 将 
在 下 次 queue 时 用 于 修剪 缓冲 

Rect mGrop 区 ， 可 以 调用 setCrop 来 设置 具 
体 的 值 


同样 ， 这 个 变量 将 用 于 下 次 
queue 时 对 缓冲 区 进行 scale， 可 
以 调用 setScalingMode 来 设置 具 
体 的 值 


int mScalingMode 


用 于 下 次 queue 时 的 图 形 翻转 等 
操作 (Transform ) 


uint32_t mDefaultWidth BRU Ta BA Sere DX Be ea EL 


uint32_t mTransform 





MRAA a LEM AL 





l 


THERE, MHRA mAy HK 


uint32_t mUserWidth mDefaultWidth/ mDefaultHeight 


uint32_t mUserHeight 





sp<GraphicBuffer> 访问 这 3 个 变量 需要 资源 锁 的 保 
mLockedBuffer 护 ， 接 下 来 还 会 有 分 析 





sp<GraphicBuffer> 
mPostedBuffer 


Region mDirtyRegion 


从 这 些 内 部 变量 的 摘 述 中 ， 大 家 可 以 了 解 到 两 点 : Surface 将 通过 
mGraphicBufferProducer 来 获取 buffer， 而 且 这 些 缓冲 区 会 被 记录 在 
mSlots 数 组 中 。 接 下 来 我 们 分 析 其 中 的 实现 细节 。 


前 面 Surface 构 造 浮 数 里 大 家 看 到 ANativeWindow 中 的 函数 指针 赋 子 
的 是 各 种 以 hook 开 头 的 函数 ， 而 这 些 hook_XX 内 部 又 直接 “ 钩 住 ”了 
Surface 中 真正 的 实现 。 比 如 hook_ dequeueBuffer 对 应 的 是 
dequeueBuffer 这 就 好 像 “ 钧 子 ” 的 功能 一 样 ， 所 以 得 名 为 hook: 


int Surface: :dequeueBuffer(android_native_buffer_t** buffer,int * 
Mutex::Autolock lock(mMutex); 
int buf = -1; 
/*Step1. 宽 高 计算 */ 
int reqw = mReqwidth ? mReqwidth : mUserWidth; 
int reqH = mReqHeight ? mReqHeight : mUserHeight; 
/*Step2. dequeueBuffer 得 到 一 个 缓冲 区 */ 
sp<Fence> fence; 
status_t result = mGraphicBufferProducer ->dequeueBuf fer (&buf, 
reqw, reqH, mReqFormat, mReqUsage) ;/*4 








sp<GraphicBuffer>&gbuf (mSlots[buf] .buffer);/* 注 意 buf 是 一 个 int 值 ， 
代表 的 是 mSlots 数 组 序号 */ 


if ((result & IGraphicBufferProducer : :BUFFER_NEEDS_REALLOCATI 
result = mGraphicBufferProducer ->requestBuffer(buf, &gbuf 


} 
*buffer = gbuf.get(); 


Step1@Surface: :dequeueBuffer 。 图 形 缓 冲 区 一 定 有 宽 高 属性 ， 具 
体 的 值 由 mReqWidth/ mReqHeight 或 者 mUserWidth/mUserHeight 决 定 ， 
其 中 前 者 的 优先 级 比 后 者 高 。 


Step2@Surface: :dequeueBuffer 。 如 前 面 所 述 ， 真 正 执行 
dequeueBuffer 操 作 的 确实 是 
mGraphicBufferProducer (1GraphicBufferProducer) 。Surface 中 的 这 
个 核心 成 员 变 量 的 来 源 可 以 有 两 个 : 作为 Surface 的 构造 溺 数 参数 传 
A; 或 者 Surface 的 子 类 通过 直接 调用 set1GraphicBufferProducer 来 生 
成 。 


在 应 用 进程 环境 中 ， 属 于 后 者 。 


大 致 流程 是 : ViewRoot Imp1 持 有 一 个 Java 层 的 Surface 对 象 (Ei) 
mSur face) ， 初 始 时 是 空 的 。 后 续 ViewRoot1lmp1 将 向 
WindowManagerService 发 起 relayout 请 求 ， 此 时 mSurface 才 被 赋 子 真正 
有 效 的 值 。WindowManagerServi ce 会 先 让 WindowStateAnimator 生 成 一 
个 SurfaceContro1， 然 后 通过 Surface. copyFrom () 国 数 将 其 复制 到 
mSurface 中 。 这 个 复制 男 数 会 通过 nat ive 接 口 nativeCreateFrom 
SurfaceControl 来 生成 本 地 Surface (C++) WR, BABE 
android view Surface. cpp 文 件 中 。JNI 范 数 
nativeCreateFromSurfaceControl 将 从 SurfaceControl 中 提取 出 
Surface (C++) ， 最 终 记录 到 Surface (Java) 的 成 员 变 量 中 。 这 样 ， 后 期 
我 们 就 可 以 从 此 变量 中 还 原 出 底层 的 Surface 对 象 了 。 


Android 源 码 工程 中 有 很 多 类 的 名 称 都 市 有 “Surface”， 取 名 极其 
混乱 。 下 面 通过 图 9-13 来 帮助 大 家 理 顺 它们 的 关系 。 





5 | | WindowMana | | WindowState | loon on android view SutlaceComp 
ViewRoctnpl) | purer Animator | SECOL | SuriceCont oserClient 
| | 


| 
rclayout | 
| 








nativeCreate createSurface 





| | 

| | 

copy rom | | 
(surlaceControl} | | 
| | 
| | 
| | 
| | 
| | 


全 图 9-13 Sutrface 创 建 流程 


从 图 9-13 中 可 以 看 到 ，Surface 由 SurfaceControl 管 理 ， 而 后 者 又 
由 SurfaceComposerClient 创 建 。 我 们 可 以 感 沉 到， 程序 应 该 越 来 越 接 
WtSurfaceF linger J: 


/*frameworks/native/libs/gui/SurfaceComposerClient.cpp*/ 
sp<SurfaceControl> SurfaceComposerClient::createSurface(const Str 

uint32_t h,PixelFormat for 
{ 


sp<SurfaceControl> sur; 
if (mStatus == NO_ERROR) { 
sp<IBinder> handle; 
sp<IGraphicBufferProducer> gbp; 
status_t err = mClient->createSurface(name, w, h, format, 
// 生 成 一 个 Surface 


if (err == NO_ERROR) { 
sur = new SurfaceControl(this, handle, gbp);//Surface 


} 
$ 


return sur; 


上 述 代 码 段 中 ，mclient 是 一 个 1ISurfaceComposerClient 的 sp 指 
针 ， 程 序 通 过 它 来 生成 一 个 Surface。 值 得 注意 的 是 ，SurfaceControl 
对 象 并 不 是 由 1SurfaceComposerClient 的 createSurface 直 接生 成 的 
一 一 些 函数 的 参数 中 包括 了 gbp， 即 前 面 所 说 的 “buffer 生 产 者 ”。 从 
中 我 们 可 以 了 解 到 ， 真 正 与 SurfaceF1inger 间 有 联系 的 应 该 就 是 gbp。 


1SurfaceComposerClient 的 服务 器 端 实现 是 谁 ? 


void SurfaceComposerClient::onFirstRef() { 
sp<ISurfaceComposer> sm(ComposerService: :getComposerService( ) 
if (sm != 0) { 
sp<ISurfaceComposerClient> conn = sm->createConnection(); 
if (conn != 0) { 
mClient = conn; 
mStatus = NO_ERROR; 


Fak Ay DL, |SurfaceComposerC! ient 是 由 1SurfaceComposer : 
createConnection 生 成 的 。 在 这 一 过 程 中 ， 总 共 涉 及 了 3 个 匿名 的 
Binder Server， 它 们 所 提供 的 接口 如 表 9-5 所 示 。 


表 9-5 与 Surface 相 关 的 3 个 匿名 Binder 服 务 


匿名 Binder 提供 的 接口 
ISurfaceComposer createConnection 


virtual 
status_tcreateSurface(...,sp<IGraphicBufferProduce 
gbp)=0;virtual status_t destroySurface(const 
sp<IBinder>& handle) = 0; 


ISurfaceComposerClient 








status_t requestBuffer(int slot, sp<GraphicBuffer>* 
buf);status_t setBufferCount(int bufferCount);status 
dequeueBuffer(...);status_t queueBuffer(...);void 
IGraphicBufferProducer jcancelBuffer(int slot);int query(int what, int* 
value);status_t setSynchronousMode(bool 
enabled);status_t connect(int api, QueueBufferOutp 
output);status_t disconnect(int api); 






表 中 的 3 个 匿名 Binder 是 环 环 紧 扣 的 ， 即 我 们 访问 的 顺序 只 能 是 
|SurfaceComposer Isurface 
ComposerClient1GraphicBufferProducer。 当 然 ， 匿 名 Binder 一 定 是 需 
要 由 一 个 实名 Binder 来 提供 的 ， 它 就 是 SurfaceFlinger 这 个 系统 服 
务 是 在 ServiceManager 中 “注册 在 案 ” 的 。 具体 是 在 
SurfaceComposerCl ient: :onFirstRef () 1k TA: 数 中 ， 过 回 
ServiceManager 查询 名 称 为 “SurfaceFlinger” Re Server KJ 
得 的 。 不 过 和 其 他 常见 Binder Server fA, SurfaceFl inger BIA 
在 ServiceManager 中 注册 的 名 称 为 “SurfaceFlinger”， 但 它 在 服务 器 
端 实现 的 Binder 接 口 却 是 1SurfaceComposer ， 因 而 
Sur faceComposerCl ient 得 到 的 其 实 是 1ISurfaceComposer 。 大 家 要 特别 
注意 这 点 ， 否 则 可 能 会 引起 混乱 : 


// 我 们 可 以 从 SurfaceFlinger 的 继承 关系 中 看 出 这 一 区 别 ， 如 下 代码 片断 

class SurfaceFlinger : 
public BinderService<SurfaceFlinger>，// 在 ServiceManager 中 注 
public BnSurfaceComposer，// 实 现 的 接口 却 叫 ISurfaceComposer, 不 


绕 了 一 大 圈 ， 我 们 接着 分 析 前 面 Surface: : dequeueBuffer ey WAI 
现 。 目前 读者 应 该 已 经 清楚 mGraphicBufferProducer 的 由 来 了 。 接 下 来 
程序 利用 这 个 变量 来 dequeueBuffer。 





那么 ，1GraphicBufferProducer 在 服务 器 端 又 是 由 谁 来 实现 的 呢 ? 


因为 这 里 面 奉 扯 到 很 多 新 的 类 ， 我 们 先 不 做 过 多 解释 ， 到 后 
BufferQueue 小 节 再 详细 分 析 其 中 的 依赖 关系 。 


当 mGraphicBufferProducer- >dequeueBuffer 返 回 后 ， buf 变 量 就 是 
mSlots[] 数 组 中 可 用 的 成 员 序 号 。 接 下 来 就 要 通过 这 个 序号 来 获取 真正 


的 buffer 地 址 ， 即 mSlots [buf]. buffer. 


Step3@Surface: :dequeueBuffer 。 假 如 返回 值 result 中 的 标志 包含 
了 BUFFER_NEEDS_REALLOCATION， 说 明 BufferQueue 需 要 为 这 个 Slot 重新 
分 配 空间 ， 上 有 具体 细 节 请 参见 下 一 个 小 节 。 此 时 还 需要 另外 调用 
requestBuffer 来 确定 gbuf 的 值 ， 其 中 又 牵涉 到 很 多 东西 ， 也 放 在 下 一 
小 节 统 一 解释 。 


通过 这 两 个 小 节 的 学 习 ， 大 家 已 经 掌握 了 显示 系统 中 两 个 重要 的 本 
地 窗口 ， 即 Framebuffer Nativewindow 和 Surface。 第 一 个 窗口 是 专门 
为 SurfaceF1inger 服 务 的 ， 它 由 Gralloc 提 供 支 持 ， 远 辑 上 相对 好 理 
解 ; 而 Surface 虽 然 是 为 应 用 程序 服务 的 ， 但 本 质 上 还 是 由 
SurfaceF 1inger 服 务 统一 管理 的 ， 因 而 涉及 很 多 跨 进 程 的 通信 细节 。 这 
个 小 节 我 们 只 是 简单 地 勾勒 出 其 中 的 框架 ， 接 下 来 就 要 分 几 个 方面 来 做 


完整 的 分 析 了 。 
e BufferQueue 


为 应 用 程序 服务 的 本 地 窗口 Surface， 其 依赖 的 
1IGraphicBufferProducer 对 象 在 Server 端 的 实现 是 BufferQueue。 我 们 
将 详细 解析 BufferQueue 的 内 部 实现 ， 并 结合 应 用 程序 端的 使 用 流程 来 
理解 它们 之 间 的 关系 。 


e Buffetr，Consumetr，Producer 是 “生产 者 -消费 者 ”模型 中 的 3 个 参与 
对 象 ， 如 何 协 调 好 它们 的 工作 是 应 用 程序 能 否 正常 显示 UI 的 关键 。 
HERR, RN i MH Buffer(BufferQueue) 4 Producer (应 用 程序 ) 间 
的 交互 ， 然 后 转 而 切入 Consumer(SurfaceFlinger) 做 详细 分 析 。 


9.5 BufferQueue 详 解 


上 一 小 节 我 们 已 经 看 到 了 BufferQueue， 它 是 Surface 实 现 本 地 窗口 
的 关键 。 从 逻辑 上 来 推断 ，BufferQueue 应 该 是 驻 留 在 SurfaceFlinger 
这 边 的 进程 中 。 我 们 需要 进一步 解决 的 疑惑 是 : 


° 每 个 应 用 程序 可 以 有 几 个 BufferQueue， 即 它们 的 关系 是 一 对 
= 多 对 一 ， 还 是 一 对 多 :? 


° 应 用 程序 绘制 U1 所 需 的 内 存 空间 是 由 谁 来 分 配 的 ? 
° 应 用 程序 与 SurfaceF1inger 如 何 互 斥 共 享 数据 区 ? 


我 们 这 里 面临 的 是 经 典 的 “生产 者 -消费 者 ”模型 。Android 显 示 系 
统 是 如 何 协调 好 这 两 者 对 缓冲 区 的 互 斥 访问 的 呢 ? 


9.5.1 BufferQueue 的 内 部 原理 
先 来 解析 下 BufferQueue 的 内 部 构造 ， 如 图 9-14 所 示 。 






Butferucuc 
-DutferSlot mSlots[NUM BUTTER STOTS] 


BullerSlot —nt32_tmDetaultWidth 


“ain? : 
-sp<GraphicButfer>mGraphieBufter unib. mDelauleighi 


s j -uinl32 1 mPixelFormal 
-uterstats mButerStat uit t mFrameCouner, 


-Uno _ mF rame Number -bool mBuffer lasBeen ueued. 
-sp<OraphicButterAlloc>mOraphicBufterAlloc 


+setButferCount() 
+requestlsuiter(} 
+dequeueBuller(} 
+queueButter( 
tcancelButler() 


全 图 9-14 BuffetQueue 内 部 变量 


因为 BufferQueue 是 1GraphicBufferProducer 服 务 器 端的 实现 ， 所 
以 它 必 须 重 载 接口 中 的 各 种 虚 函 数 ， 如 queueBuffer 、requestBuffer、 
dequeueBuffer 等 。 另 外 ， 这 个 类 的 内 部 有 一 个 非常 重要 的 成 员 数组 ， 
即 mSlots[NUM_BUFFER_SLOTS] 。 大 家 是 否 还 记得 前 面 Surface 类 中 也 有 
一 个 一 模 一 样 的 数组 : 


class Surface...{ 
BufferSlot mSlots[NUM_BUFFER_SLOTS]; 


虽然 两 个 数组 从 形式 上 看 一 模 一 样 ， 但 要 特别 注意 其 中 的 
BufferSlot 定 义 并 不 相同 : 


Surface: 
struct BufferSlot { 
sp<GraphicBuffer> buffer; 
Region dirtyRegion; 


}; 
而 BufferQueue 中 : 


struct BufferSlot 4.. 
sp<GraphicBuffer> mGraphicBuffer ; 
BufferState mBufferState; 


后 面 一 个 BufferSlot 中 的 GraphicBuffer 变 量 
用 于 记录 这 个 Slot 所 涉及 的 缓冲 区 ; 另 一 个 BufferState 变 
(mBufferState) 用 于 跟踪 每 个 缓冲 区 的 状态 。 比 如 : 


enum BufferState { 
FREE = 0，/*Buffer 当 前 可 用 ， 也 就 是 说 可 以 被 dequeued。 此 时 Bu 
可 认为 是 BufferQueue*/ 
DEQUEUED = 1，V*Buffer 已 经 被 dequeued， 还 未 被 queued 或 canc 
Buffer 的 owner 可 认为 是 producer 〈 应 用 程序 ) ， 
和 SurfaceFlinger (consumer ) 此 时 都 不 可 以 操 人 
QUEUED = 2，/*Buffer 已 经 被 客户 端 queued， 不 过 还 不 能 对 它 进行 ( 
可 以 acquired。 此 时 的 owner 是 BufferQueue*/ 
ACQUIRED = 3/*Buffer 的 owner 改 为 consumer， 可 以 被 released， 
然后 状态 又 返回 FREE*/ 
J}; 


从 上 面 的 状态 描述 可 以 看 出 ， 一 块 Buffer 在 处 理 过 程 中 经 历 的 生命 
周期 依次 是 FREE-> DEQUEUED->QUEUED->ACQUIRED->FREE。 


图 ?-15 所 示 是 从 Owner 的 角度 给 出 的 Buffer 状 态 迁 移 图 。 
我 们 来 简单 分 析 一 下 这 张 Buffer 状 态 迁 移 图 。 


从 图 9- 15 中 可 以 清楚 地 了 解 Buffer 的 各 个 状态 、 引起 状态 迁 FH 的 条 
件 以 及 各 状态 下 的 Owner 。 参 与 Buffer 管 理 的 0wner 对 象 有 3 个 。 


e BufferQueue 


我 们 可 以 认为 BufferQueue 是 一 个 服务 中 心 ， 其 他 两 个 0wner 必 须要 
通过 它 来 管理 Buffer。 比 如 当 Producer 想 要 获取 一 个 Buffer 时 ， 它 不 能 
越过 BufferQueue 直 接 与 Consumer 进 行 联系 ， 反 之 亦 然 。 这 有 点 像 房 产 
中 介 ， 房 主 与 买方 的 任何 交易 都 需要 经 过 中 介 的 同意 ， 私 自 达 成 的 协议 
都 是 违反 规定 的 。 


e Producer 


生产 者 就 是 “填充 ”Buffer 数 据 的 人 ， 通 常情 况 下 当然 就 是 应 用 程 
序 。 因 为 应 用 程序 不 断 地 刷新 U1， 从 而 将 产生 的 显示 数据 源源 不 绝地 写 
到 Buffer 中 。 当 Producer 需 要 使 用 一 块 Buffer 时 ， 它 首先 会 向 中 介 
BufferQueue 发 起 dequeue 申 请 ， 然 后 才能 对 指定 的 缓冲 区 进行 操作 。 经 
过 dequeue 后 Buffer 就 属于 producer 的 了 ， 它 可 以 对 Buffer 进 行 任 何必 
要 的 操作 ， 而 其 他 0wner 此 刻 绝 不 能 擅自 插手 。 


当 生 产 者 认为 一 块 Buffer 已 经 写 入 完成 后 ， 将 进一步 调用 
BufferQueue 的 queue 接 口 。 从 字面 上 看 这 个 函数 是 “入 列 ” 的 意思 ， 形 
象 地 表达 了 Buffer 此 时 的 操作 一 一 把 Buffer 归 还 到 BufferQueue 的 队列 
中 。 一 旦 queue 成 功 ，0wner 也 就 随 之 改变 为 BufferQueue 了 。 
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的 BUFFER 












QUFUFD 状态 下 
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acquire 成 功 


ACQUIRED 状态 下 


的 BUFFER 





对 buller 进行 若干 操作 


release 


FREE 状态 下 的 BUFFER 


全 图 9-15 Buffet 的 状态 迁移 图 
e Consumer 


消费 者 是 与 生产 者 相对 应 的 ， 它 的 操作 同样 受到 BufferQueue 的 管 
控 。 当 一 块 Buffer 已 经 就 绪 后 ，Consumer 就 可 以 开始 工作 了 ， 细 节 我 们 
会 在 后 续 SurfaceF1inger 中 描述 。 这 里 需要 特别 留意 的 是 ， 从 各 个 对 象 
所 扮演 的 角色 来 看 ，BufferQueue 是 中 介 机 构 ， 属 于 服务 提供 方 
Producer 属 于 Buffer 内 容 的 产 出 方 ， 它 对 缓冲 区 的 操作 是 一 个 “ 主 
动 ” 的 过 程 ; 反之 ，Consumer 对 Buffer 的 处 理 则 是 “被 动 ” 的 、 “等 待 
式 ” 的 一 一 它 必须 要 等 到 一 块 Buffer 填 充 完成 后 才能 工作 。 在 这 样 的 模 
型 下 ， 我 们 怎么 保证 Consumer 可 以 及 时 处 理 Buffer 呢 ? 换 句 话说 ， 当 一 
块 Buffer 数 据 ready 后 ， 应 该 怎么 告知 Consumer 来 操作 呢 ? 


仔细 观察 ， 可 以 看 到 BufferQueue 里 同时 还 提供 了 一 个 特别 的 类 ， 
名 称 为 ConsumerLi stener。 其 中 的 国 数 接口 包括 : 


struct ConsumerListener : public virtual RefBase { 
virtual void onFrameAvailable() = 0;/* 当 一 块 buffer 可 以 被 消费 
特别 注意 此 时 没有 共享 锁 的 人 
virtual void onBuffersReleased() = 0;/*BufferQueue 通 知 cons 
中 的 一 个 或 多 个 GraphicBul 











}; 


这 样 就 很 清楚 了 ， 当 有 一 帧 数据 准备 就 绪 后 ，BufferQueue 就 会 调 
用 onFrameAvai1able 0 来 通知 Consumer 进 行 消费 。 


9.5.2 BufferQueue 中 的 缓冲 区 分 配 


我 们 知道 ，BufferQueue 中 有 一 个 mSlots 数 组 用 于 管理 其 内 的 各 组 
冲 区 ， 最 大 容量 为 32。 从 它 的 声明 方式 来 看 ， 这 个 mSlots 在 程序 一 开始 
就 静态 分 配 了 32 个 BufferSlot 大 小 的 空间 。 不 过 这 并 不 代表 其 中 的 数据 
缓冲 区 也 是 一 次 性 静态 分 配 的 ， 恰 恰 相 反 ， 从 BufferSlot 的 内 部 变量 指 
针 mGraphicBuffer 可 以 看 出 ， 缓 冲 区 的 空间 分 配 应 当 是 动态 的 〈 从 下 面 
的 注释 也 能 看 出 一 些 端倪 ) : 


// mGraphicBuffer points to the buffer allocated for this slot or 
sp<GraphicBuffer> mGraphicBuf fer; 


现在 的 问题 就 转化 为 : 在 什么 情况 下 会 给 一 个 Slot 分 配 实际 的 空间 
呢 ? 


首先 能 想到 的 就 是 dequeueBuffer 。 理 由 如 下 : 


° 缓冲 区 的 空间 分 配 应 该 既 要 满足 使 用 者 的 需求 ， 又 要 防止 浪 
费 。 后 面 这 一 点 mSlots 已 经 满足 了 ， 因 为 它 并 没有 采取 一 开始 融 静 
态 预 分 配 的 方式 。 


° 既然 Producer 对 buffer 的 操作 是 “主动 ”的 ， 那 么 就 意味 着 它 
是 整个 需求 的 发 起 者 。 换 名 话说， 只 要 它 没有 dequeueBuffer ， 或 
者 dequeueBuffer 时 能 获取 到 可 用 的 缓冲 区 ， 那 当然 就 没有 必要 再 
重新 分 配 空间 了 。 


下 面 详 细 分 析 这 个 函数 ， 并 验证 我 们 上 面 的 猜测 : 


/*frameworks/native/libs/gui/BufferQueue.cpp*/ 
status_t BufferQueue: :dequeueBuffer(int *outBuf, sp<Fence>* outFe 
uint32_t h,uint32_t format, uint32_t 
status_t returnFlags(OK); 


{ // Scope for the lock 
Mutex::Autolock lock(mMutex); /* 这 里 采用 了 自动 锁 ， 所 以 上 面 需要 
生命 周期 结束 后 锁 也 就 自动 释放 了 。 这 种 写法 











int found = -1; 

int dequeuedCount = 0; 

bool tryAgain = true; 

while (tryAgain) {/*Step1. 循环 查找 符合 要 求 的 Slot*/ 





found = INVALID_BUFFER_SLOT;// 初 始 值 

foundSync = INVALID_BUFFER_SLOT ; 

dequeuedCount = 0; 

for (int 1 = 0; i < maxBufferCount; i++) { 
const int state = mSlots[i].mBufferState; 
/*Step2 .统计 dequeued buffer 数 量 ， 后 面 会 用 到 */ 
if (state == BufferSlot::DEQUEUED) { 








dequeuedCount++; 
} 
if (state == BufferSlot::FREE) { /*Step3. 和 寻找 符合 要 
if (found < © || mSlots[i].mFrameNumber < mSlots 





found = 工 ，// 找 到 符合 要 求 的 SLot 
} 





}// if (state == BufferSlot: :FREE) 结 束 
}// for 循 环 结束 


/*Step4. 如 果 Client 没 有 设置 buffer _ count 的话 ， 就 不 允许 dedueuk 
if (!mOverrideMaxBufferCount&& dequeuedCount) { 
ST_LOGE("dequeueBuffer: can't dequeue multiple bu 
setting the buffer count"); 
return -EINVAL; 





i 


/*Step5. 判断 是 否 要 重 试 */ 

tryAgain = found == INVALID_BUFFER_SLOT; 

if (tryAgain) { 
mDequeueCondition.wait(mMutex) ; 








} 
}//while 循 环 结束 


if (found == INVALID_BUFFER_SLOT) { 
/* 因 为 前 面 while 循 环 如 果 没 找到 的 话 是 不 会 退出 的 ， 所 以 理论 上 不 会 出 
ST_LOGE("dequeueBuffer: no available buffer slots"); 
return -EBUSY; 























J 


const int buf = found; 
*outBuf = found; // 返 回 值 
/* 成 功 找到 可 用 的 Slot 序 号 ， 接 下 来 就 开始 对 这 个 指定 的 Slot 进 行 初始 操作 ， 





mSlots[buf].mBufferState = BufferSlot: :DEQUEUED; /*Step6. 
const sp<GraphicBuffer>& buffer(mSlots[buf].mGraphicBuffe 
if ((buffer == NULL) || (uint32_t(buffer->width) != w) | 
(uint32_t(buffer->height) != h) || (uint32_t(buffer-> 
|| ((uint32_t(buffer->usage) & usage) != usage) ) 
{ /*Step7. 为 BufferSlot 对 象 做 初始 化 */ 
mSlots[buf].mAcquireCalled = false; 
mSlots[buf].mGraphicBuffer = NULL; 
mSlots[buf].mRequestBufferCalled = false; 
mSlots[buf].mEglFence = EGL_NO_SYNC_KHR; 
mSlots[buf].mFence = Fence: :NO_FENCE; 
mSlots[buf].mEglDisplay = EGL_NO_ DISPLAY; 


returnFlags |= IGraphicBufferProducer: : BUFFER_NEEDS_R 
} 


} // 自动 锁 lock 结 束 的 地 方 
/xstep8。， 如 果 上 述 判断 结果 是 需要 重新 分 配 空间 的 话 */ 


if (returnFlags & IGraphicBufferProducer: :BUFFER_NEEDS_REALLO 
status_t error; 




















sp<GraphicBuffer> graphicBuffer(mGraphicBufferAlloc->crea 
w, h, format, usage, &error));/*#&F 4 wea li 


í // Scope for the lock 
Mutex: :Autolock lock(mMutex) ; 


mSlots[*outBuf].mGraphicBuffer = graphicBuffer; 


J 
J 


return returnFlags; 


因为 这 个 函数 很 长 ， 我 们 只 保留 最 核心 的 部 分 。 从 整体 框架 来 看 ， 
Step1~-Step5 是 在 查找 一 个 可 用 的 Slot 序号 。 从 Step6 开 始 ， 就 针对 这 
一 特定 的 Slot 进行 操作 了 。 下 面 我 们 分 步 进行 解 析 。 


Step1@ BufferQueue: :dequeueBuffer 。 进 入 whi le 循环 ， 退 出 的 条 
件 是 tryAgain 为 false。 这 个 变量 默认 值 是 true， 如 果 一 轮 循环 结束 后 
found 不 再 是 INVAL1D_BUFFER_SLOT， 就 会 变 成 false， 从 而 结束 整个 
whi le 循环 。 


循环 的 主要 功能 就 是 查找 符合 要 求 的 Slot， 其 中 found 变 量 是 一 个 
int 值 ， 指 的 是 这 个 BufferSlot 在 mSlots 数 组 中 的 序号 。 


Step2@ BufferQueue: :dequeueBuffer 。 统 计 当 前 已 经 被 dequeued 
的 buffer 数 量 ， 这 将 用 于 后 面 的 判断 ， 即 假如 Client 没 有 设置 buffer 
count， 那 么 它 会 被 禁止 dequeue 一 个 以 上 的 buffer 。 


Step3@ BufferQueue: :dequeueBuffer 。 假 如 当前 的 buffer 状 态 是 
FREE， 那 么 这 个 Slot 就 可 以 进入 备 选 了 。 为 什么 只 是 备 选 而 不 是 直接 返 
回 这 二 结果 呢 ? 因为 nslots 中 很 可 能 有 多 个 符合 条 件 的 Slot， 当 然 需要 
挑选 其 中 最 匹配 的 。 判 断 的 依据 是 当前 符合 要 求 的 Slot 的 mFrameNumber 
是 否 比 上 一 次 选中 的 最 优 S1ot 的 mFrameNumber 小 。 具 体 代码 如 下 : 


mSlots[i].mFrameNumber <mSlots[found] .mFrameNumber ; 


Step4@ BufferQueue: :dequeueBuffer 。 这 里 的 判断 来 源 于 第 二 步 
的 计算 结果 ， 一 旦 发 现 dequeue 的 数量 “超标 ”， 就 直接 出 错 返 回 。 


Step5@ BufferQueue: :dequeueBuffer 。 经 过 上 述 几 个 步骤 ， 我 们 


已 经 扫描 了 一 遍 mslots 中 的 所 有 成 员 ， 这 时 就 要 判断 是 否 可 以 退出 循 
环 。 前 面 已 经 说 过 ， 如 果 成 功 找到 有 效 的 Slot 就 可 以 不 用 再 循环 查找 
了 ， 否 则 tryAgain 仍 然 是 true。 假 如 是 后 一 种 情况 ， 证 明 当 前 已 经 没 
FREE 的 Slot 。 这 时 如 果 直 接 进 入 下 一 轮 循环 ， 结 果 通 常 也 是 一 样 的 ， 反 
而 浪费 了 CPU 资源 。 所 以 ， 就 需要 使 用 条 件 锁 来 等 待 。 代 码 如 下 : 


mDequeueCondition.wait(mMutex); 


当 有 Buffer 被 释放 时 ， 这 个 锁 的 条 件 就 会 满足 ， 然 后 程序 才 继 续 查 
找 可 用 的 Slot。 


Step6@ BufferQueue: :dequeueBuffer 。 根 据 前 面 的 Buffer 状 态 迁 
移 图 ， 当 处 于 FREE 状态 的 Buffer 被 dequeue 成 功 后 ， 它 将 进入 
DEQUEUED， 所 以 这 里 我 们 需要 改变 其 mBufferState。 


Step7@ BufferQueue: :dequeueBuffer 。 通 过 上 述 几 个 步骤 的 努 
力 ， 现 在 我 们 已 经 成 功 地 寻找 到 有 效 的 Slot 序号 了 。 但 是 这 并 不 代表 这 
个 Slot 可 以 直接 使 用 ， 为 什么 ? 最 直接 的 一 个 原因 就 是 这 个 Slot 可 能 还 
没有 分 配 空 间 。 


因为 BufferSlot:: mGraphicBuffer 初 始 值 是 NULL， 假 如 我 们 是 第 
一 次 使 用 它 ， 必 然 是 需要 为 它 分 配 空间 的 。 另 外 ， 即 便 mGraphicBuffer 
不 为 空 ， 但 如 果 用 户 所 需要 的 Buffer 属 性 〈 比 如 width，height， 
format 等 ) 和 当前 这 个 不 符 ， 那 么 还 是 要 进行 重新 分 配 。 


Step8@ BufferQueue: :dequeueBuffer 。 如 果 上 一 步 的 判断 结果 是 
BUFFER_NEEDS_REALLOCATI0N， 说 明 此 Slot 还 未 分 配 到 有 效 的 buffer 空 
间 一 一 具体 分 配 操 作 使 用 的 是 mGraphicBufferAlloc 这 个 Allocator， 这 
里 暂 不 深究 其 中 的 实现 了 ， 后 续 还 会 有 详细 分 析 。 


如 果 重 新 分 配 了 空间 ， 那 么 最 后 的 返回 值 中 需要 加 上 
BUFFER_NEEDS_REALLOCATION 标 志 。 客 户 端 在 发 现 这 个 标志 后 ， 还 应 
用 requestBuffer () 来 取得 最 新 的 buffer 地 址 。 前 一 小 节 
Surface: :dequeueBuffer () 的 Step3 就 是 一 个 例子 ， 这 里 结合 起 来 分 
析 。 为 了 方便 阅读 ， 再 把 这 部 分 代码 简单 地 列 出 来 : 
int Surface: :dequeueBuffer(android_native_buffer_t** buffer,int * 


Mutex::Autolock lock(mMutex); 
int buf = -1; 


Fa 
o 


W 


/*Stepl. 宽 高 计算 */ 

int reqw = mReqwidth ? mReqwidth : mUserWidth; 

int reqH = mReqHeight ? mReqHeight : mUserHeight; 

/*Step2. dequeueBuffer 得 到 一 个 缓冲 区 */ 

sp<Fence> fence; 

status_t result = mGraphicBufferProducer ->dequeueBuf fer (&buf, 
reqw, reqH, mReqFormat, mReqUsage) ;/* 这 一 小 节 讲 解 的 就 是 这 - 


sp<GraphicBuffer>&gbuf(mSlots[buf] .buffer);/* 注 意 buf 是 一 个 int 值 ， 
代表 的 是 mSLots 数 组 序号 * 


if ((result & IGraphicBufferProducer: :BUFFER_NEEDS_REALLOCATI 
result = mGraphicBufferProducer ->requestBuffer(buf, &gbuf 
要 重新 分 配 得 到 的 ， 所 以 还 需要 进一步 调用 redquestBl 




















} 
*buffer = gbuf.get(); 


当 mGraphicBufferProducer->dedqueueBuffer 成 功 返回 后 ，buf 得 到 
了 mSlots 中 可 用 数组 成 员 的 序号 “对 应 这 一 小 节 的 found 变 量 ) 。 但 一 
个 很 明显 的 问题 是 : 既然 客户 端 和 BufferQueue 运 行 于 两 个 不 同 的 进程 
中 ， 那 么 它们 的 mslots [buf] 会 指向 同一 块 物理 内 存 吗 ? 这 就 是 
requestBuffer 存 在 的 意义 。 


先 来 看 看 BpGraphicBufferProducer 中 是 如 何 发 起 Binder 申 请 的 : 


/*frameworks/native/libs/gui/IGraphicBufferProducer.cpp*/ 
class BpGraphicBufferProducer: public BpInterface<IGraphicBufferP 


virtual status_t requestBuffer(int bufferIdx, sp<GraphicBuf 

Parcel data, reply; 

data.writeInterfaceToken(IGraphicBufferProducer::getInterfa 

data.writeInt32(bufferIdx);/* 只 写 入 了 bufferIdx 值 ， 也 就 是 说 BnGr: 
中 实际 上 是 看 不 到 buf 变 量 的 */ 

status_t result =remote()->transact(REQUEST_BUFFER, data, & 





bool nonNull = reply.readInt32();/* 这 里 读 取 的 是 什么 ?我 们 稍 后 可 上 
Producer 中 确认 下 */ 














if (nonNull) { 
*buf = new GraphicBuffer(); // 生 成 一 个 GraphicBuffer， 看 到 ; 
reply.read(**buf);/*buf 是 一 个 sp 指针 , 那么 **sp 实 际 上 得 到 的 就 是 
象 。 在 这 个 例子 中 指 的 是 mSlots[buf] ,buffer 


} 
result = reply.readInt32();/* 读 取 结 果 */ 





return result; 


Native 层 的 BpXXX/BnXXX 与 Java 层 的 不 同 之 处 在 于 ， 后 者 通常 都 是 
依赖 于 aidl 来 自动 生成 这 两 个 类 ， 而 前 者 则 是 手工 完成 的 。 也 正 因 为 是 
手工 书写 的 ， 使 用 起 来 才 更 具 灵 活性 。 比 如 在 1GraphicBufferProducer 
这 个 例子 中 ， 开 发 者 “可 ”了 点 技巧 一 一 Surface 中 调用 了 
lgraphicBuffer Producer: :requestBuffer (int slot, 
sp<GraphicBuffer>* buf) ， 这 个 函数 虽然 形式 上 有 两 个 参数 ， 但 只 
第 一 个 是 入 参 ， 后 一 个 则 是 出 参 。 在 实际 的 Binder 通 信 中 ， 只 有 Slot 序 
号 这 个 int 值 〈 即 buffer1dx) 传递 给 了 对 方 进程 ， 而 buf 则 自始至终 都 
是 Surface 所 在 的 本 地 进程 在 处 理 。 不 过 从 调用 者 的 角度 来 讲 ， 好 像 是 
由 1GraphicBufferProducer 的 Server 冰 完 成 了 对 buf 的 赋值 。 





MBpGraphicBufferProducer : :requestBuffer 这 个 国 数 实现 中 可 以 
看 到 ，Client 端 向 Server 端 请 求 了 一 个 REQUEST_BUFFER 服 务 ， 然 后 通过 
读 取 返 回 值 来 获得 缓冲 区 信息 。 为 了 让 大 家 能 看 清楚 这 其 中 的 细节 ， 有 
必要 再 分 析 一 下 BnGraphicBufferProducer 具 体 是 如 何 啊 应 这 个 服务 请 
求 的 。 如 下 所 示 : 


/*frameworks/native/libs/gui/IGraphicBufferProducer.cpp*/ 
status_t BnGraphicBufferProducer: :onTransact(uint32_t code, const 


Sswitch(code) { 

Case REQUEST _BUFFER: { 
CHECK_INTERFACE(IGraphicBufferProducer, data, reply); 
int bufferIdx = data.readInt32();// 首 先 读 取 要 处 理 的 Slc 
sp<GraphicBuffer> buffer; // 生 成 一 个 G6raphicBuffer 智 能 指 1 
int result = requestBuffer(bufferIdx，&buffer ) ;// 调 用 2z 
reply->writeInt32(buffer != 0);// 注 意 ， 第 一 个 写 入 的 值 是 判 

// 也 就 是 一 个 poo1 值 








if (buffer != 0) { 
reply->write(*buffer); // 好 ， 真 正 的 内 容 在 这 里 ， 后 面 我 人 





} 
reply->writeInt32(result);// 写 入 结果 值 
return NO_ERROR; 

} break; 


BnGraphicBufferProducer 首 先 读 取 Slot 序 号 ， 即 buffer1dx; 然后 
通过 BufferQueue 的 接口 requestBuffer 来 获取 与 之 对 应 的 正确 的 
GraphicBuffer 这 里 是 指 mSlots[slot]. mGraphicBuffer 。 要 特别 注 
意 的 是 ，BnGraphicBufferProducer 在 reply 中 第 一 个 写 入 的 是 boo1 值 





(buffer!=0) ， 紧 随 其 后 的 才 是 GraphicBuffer， 最 后 写 入 结果 值 ， 大 
功 告 成 。 


显然 BpGraphicBufferProducer 必 须要 按照 与 
BnGraphicBufferProducer 同 样 的 写 入 顺序 来 读 取 数据 。 


(1) 因而 它 首 先 获取 一 个 int32 值 ， 赋 予 nonNul1 变 量 。 这 个 值 对 
应 的 是 buffer != 0 的 远 辑 判断 。 假 如 确实 不 为 空 ， 那 说 明 我 们 可 以 接 
着 读 取 GraphicBuffer 了 。 


(2) 客户 端 与 服务 器 端 对 GraphicBuffer 变量 的 “ 写 入 和 读 取 ” 操 
作 分 别 是 : 


reply->write(*buffer);// 写 入 
reply .read(**buf);// 读 取 


(3) 读 取 result 结 果 值 。 


在 第 二 步 中 ，Server 端 写 入 的 GraphicBuffer 对 象 需 要 在 Client 中 
完整 地 复 现 出 来 。 根 据 我 们 在 Binder 章 节 的 学 习 ， 具 备 这 种 能 力 的 
Binder 对 象 应 该 是 继承 了 Flattenable。 实 际 上 呢 ? 


class GraphicBuffer: public ANativeObjectBase<ANativewindowBuffer 
LightRefBase<GraphicBuffer>>, public Flattenable 


从 GraphicBuffer 的 声明 中 就 可 以 验证 我 们 的 猜测 了 。 


人 latten 和 unflatten 接 口 的 ， 相 信 
就 能 揭晓 谜底 了 : 


/*frameworks/native/libs/ui/GraphicBuffer.cpp*/ 
status_t GraphicBuffer::flatten(void* buffer, size_t size, int fd 


la 


int* buf = static_cast<int*>(buffer); 


if (handle) { 
buf[6] = handle->numFds; 
buf[7] = handle->numInts; 
native_handle_t const* const h = handle; 
memcpy(fds, h->data, h->numFds*sizeof(int)); 
memcpy(&buf[8], h->data + h->numFds, h->numInts*sizeof(in 


return NO_ERROR; 


在 这 个 函数 中 ， 我 们 最 关心 的 是 handle 这 个 变量 的 flatten， 它 实 
际 上 是 GraphicBuffer 中 打开 的 一 个 ashmem 句 柄 一 一 这 是 两 边 进程 实现 
共享 缓冲 区 的 关键 。 与 handle 相 关 的 变量 分 别 是 buf[6]-buf [8] 以 及 
fds， 大 家 可 以 深入 理解 下 它们 的 作用 。 


再 来 看 看 C1ient 端 是 如 何 还 原 出 一 个 GraphicBuffer 的 : 
status_t GraphicBuffer::unflatten(void const* buffer, size_t size 
Li 


int const* buf = static_cast<int const*>(buffer); 


const size_t numFds 


= buf[6]; 
const size_t numInts = buf[7]; 
if (numFds || numInts) 4... 


native_handle* h = native_handle_create(numFds, numInts); 
memcpy(h->data, fds, numFds*sizeof(int)); 
memcpy(h->data + numFds, &buf[8], numInts*sizeof(int)); 
handle = h; 

} else { ... 


F 
if (handle != 0) { 
mBufferMapper .registerBuffer (handle); 


} 
return NO_ERROR; 


同样 ，unflatten 中 的 操作 也 是 依据 flatten 时 写 入 的 格式 。 其 中 最 
重要 的 两 个 痕 数 是 native handle create() 和 registerBuffer () 。 前 一 
个 函数 生成 native_handle 实 例 ， 并 将 相关 数据 复制 到 其 内 部 。 另 一 个 
registerBuffer 则 属于 GraphicBufferMapper 类 中 的 实现 ， 成 员 变 量 
mBufferMapper 是 在 GraphicBuffer 构 造 消 数 中 生成 的 ， 它 所 承担 的 任务 
是 和 Gralloc 打 交道 。 核 心 代 码 如 下 : 


GraphicBufferMapper: :GraphicBufferMapper ( ) 
{ 


hw_module_t const* module; 
int err = hw_get_module(GRALLOC_HARDWARE_MODULE_ID, &module); 


这 里 出 现 了 我 们 熟悉 的 Gralloc 的 module id， 不 清楚 的 读者 可 以 回 


头 看 看 Gralloc 这 个 小 节 的 介绍 。 

GraphicBufferMapper : :registerBuffer () 只 是 起 到 了 中 介 作 用 ， 它 会 
直接 调用 gralloc module t::registerBuffer () ， 那 么 后 者 究竟 完成 了 
什么 功能 呢 ? 因为 这 个 函数 的 实现 与 具体 平台 有 关 ， 我 们 以 msm7k 为 例 
来 大 概 分 析 下 : 


/*hardware/msm7k/libgralloc/Mapper.cpp*/ 
int gralloc_register_buffer(gralloc_module_t const* module, buffe 


private_handle_t* hnd = (private_handle_t*)handle; 


err = gralloc_map(module, handle, &vaddr); 
return err; 


可 以 看 到 ， 通 过 handle 句 柄 Client 端 可 以 将 指定 的 内 存 区 域 映 射 到 
自己 的 进程 空间 中 ， 而 这 块 区 域 与 BufferQueue 中 所 指向 的 物理 空间 是 
一 致 的 ， 从 而 成 功 地 实现 了 两 者 的 缓冲 区 共享 。 


这 样 在 Surface: :dequeueBuffer () 函数 的 处 理 过 程 中 ， 一 旦 遇 到 
mGraphicBufferProducer-> requestBuffer 结 果 中 包含 有 
BUFFER_NEEDS_REALLOCATION 的 情况 ， 融 需要 通过 requestBuffer ( 得 到 
的 结果 来 “刷新 ”Client 这 端 mSlots[] 所 管辖 的 缓冲 区 信息 ， 以 保证 
Surface 与 BufferQueue 在 任何 情况 下 都 能 在 32 个 BufferSlot 中 保持 数据 
缓冲 区 上 的 高 度 一 致 。 这 也 是 后 面 它们 能 正确 实施 “生产 者 -消费 
者 ”模型 的 基础 。 


9.5.3 应 用 程序 的 典型 绘图 流程 


我 们 知道 ，BufferQueue 可 以 有 多 达 32 个 的 BufferSlot， 为 什么 这 
样 设计 ? 


一 个 可 能 的 原因 就 是 提高 图 形 泻 染 速度 。 因 为 假如 只 有 两 个 
buffer， 可 以 想象 一 下 ， 当 应 用 程序 这 个 生产 者 的 产 出 效率 大 于 消费 者 
的 处 理 速度 时 ， 很 快 就 会 dequeue 完 所 有 缓冲 区 而 处 于 等 竺 状态， 从 而 
导致 不 必要 的 麻烦 。 当 然 ， 实 际 上 32 只 是 最 大 的 容量 ， 具 体 值 是 可 以 设 
置 的 ， 大 家 可 以 结合 后 面 的 Project Butter 来 进一步 理解 。 


前 面 小 节 读 者 已 经 学 习 了 BufferQueue 的 内 部 原理 ， 那 么 应 用 程序 
又 是 如 何 与 之 配合 的 呢 ? 


解决 这 个 疑惑 的 关键 就 是 了 解 应 用 程序 是 如 何 执 行 绘图 流程 的 ， 这 
也 是 本 节 内 容 的 重点 。 不 过 大 家 应 该 有 个 心理 准备 应 用 程序 并 不 会 
直接 使 用 BufferQueue (或 者 Surface) 。 和 Android 系 统 中 很 多 其 他 地 
方 一 样 ，“ 层 层 封 装 ” 在 这 里 同样 是 存在 的 。 因 而 我 们 一 方面 要 尽量 抓 
住 核 心 ， 另 一 方面 也 要 辅 以 有 效 的 分 析 手 段 ， 才 能 更 快 更 好 地 从 诸多 错 
综 复 杂 的 类 关系 中 找 出 问题 的 答案 。 


基于 以 上 原因 ， 我 们 特别 选取 “系统 开机 动画 ”这 一 应 用 程序 为 
例 ， 来 分 析 应 用 程序 图 形 绘制 的 流程 。 值 得 一 提 的 是 ， 这 个 开机 动画 的 
实现 符合 前 面 提 到 的 两 个 改进 图 形 系统 中 的 第 一 个 ， 即 应 用 程序 与 
SurfaceFlinger 都 是 使 用 0penGL ES 来 完成 U1 显示 的 。 不 过 因为 它 是 一 
个 C++ 程 序 ， 所 以 不 需要 上 层 GLSurfaceView 的 支持 。 


当 一 个 Android 设 备 上 电 后 ， 正 常情 况 下 它 会 先后 显示 最 多 4 个 不 同 
的 开机 画面 。 分 别 是 ; 





e BootLoader 


这 显然 是 第 一 个 出 现 的 了 画面。 因为 boot-loader 只 是 负责 系统 后 续 
模块 的 加 载 与 启动 ， 所 以 一 般 我 们 只 让 它 显 示 一 张 静 态 的 图 片 。 


e Kernel 


内 核 也 有 自己 的 显示 画面 。 和 boot-loader 一 样 ， 默 认 情 况 下 它 也 
只 是 一 张 静 态 图 片 。 


e Android (最 多 2 个 ) 


Android 是 系统 启动 的 最 后 一 个 阶段 ， 也 是 最 耗 时 间 的 一 个 。 它 的 
开机 画面 既 可 以 是 静态 的 文字 、 图 片 ， 也 可 以 是 动态 的 画面 。 男 外 ， 这 
一 阶段 可 以 包含 最 多 两 个 开机 画面 一 一 通常 前 一 个 是 文字 或 者 静态 图 片 
GES: 默认 是 图 片 ， 但 如 果 图 片 不 存在 的 话 ， 就 显示 文字 。 关 于 这 方 
面 的 参考 资料 很 多 ， 大 家 可 以 自行 查阅 ， 这 里 不 作 过 多 叙述 ) ; 另外 一 
个 则 是 动画 ， 如 图 9?-16 所 示 。 


CINDROID 





全 图 9-16 原生 态 Andtoid 系 统 中 的 开机 动画 


这 个 开机 动画 的 实现 类 是 BootAnimation， 它 的 内 部 就 是 借助 于 
SurfaceFlinger 来 完成 的 。 另 外 ， 由 于 它 并 不 是 传统 意义 上 的 Java 层 应 
用 程序 ， 从 而 使 得 我 们 可 以 抛 离 很 多 上 层 的 奉 绊 〈 比 如 一 大 堆 JN1 调 
用 ) ， 进 而 以 最 直观 的 方式 来 审视 BufferQueue 的 使 用 细节 ， 这 是 分 析 
本 节 问 题 的 最 佳 选 择 。 


BootAnimation 是 一 个 C++ 程序 ， 其 工程 源码 路 径 
是 /frameworks/base/cmds/bootanimation。 和 很 多 native 应 用 一 样 ， 
它 也 是 在 init 脚 本 中 被 启动 的 。 如 下 : 


service bootanim /system/bin/bootanimation 
class main 
user graphics 
group graphics 
disabled 
oneshot 


以 上 内 容 是 从 init. rc 脚本 中 摘录 出 来 的 ， 完 整地 描述 了 
bootanimation 这 个 程序 的 启动 属性 。 如 果 大 家 对 其 中 的 语法 不 清楚 ， 
可 以 参见 本 书 的 系统 启动 章节 。 


当 bootanimation 被 启动 后 ， 它 首先 会 进入 main 函 数 〈 即 
main@Bootanimation_main. cpp) 生成 一 个 BootAnimation 对 象 ， 并 开启 
线程 池 (因为 它 需 要 与 SurfaceFlinger 等 系统 服务 进行 跨 进 程 的 通 
45) 。 在 BootAnimation 的 构造 函数 中 ， 同 时 会 生成 一 个 


SurfaceComposerClient: 


BootAnimation::BootAnimation() : Thread(false) 


{ 


mSession = new SurfaceComposerClient(); 


SurfaceComposerClient 是 每 个 UI 应 用 程序 与 SurfaceFlinger 间 的 
独立 纽带 ， 后 续 很 多 操作 都 是 通过 它 来 完成 的 。 不 过 
SurfaceComposerClient 更 多 的 只 是 一 个 封装 ， 真 正 起 作用 的 还 是 其 内 
部 的 1SurfaceComposerClient。 前 面 小 节 中 我 们 已 经 讲解 了 
|GraphicBufferProducer 5|Surface Composer Client 在 应 用 程序 中 的 
获取 顺序 ， 那 么 两 者 有 什么 区 别 呢 ? 


简单 来 说 ，1SurfaceComposerClient 是 应 用 程序 与 SurfaceF|inger 


间 的 桥梁 ， 而 lgraphicBuffer Producer 则 是 应 用 程序 与 BufferQueue 间 
的 传输 通道 。 这 样 的 设计 是 合理 的 ， 体 现 了 模块 化 的 思想 一 一 
SurfaceF1inger 的 职责 是 “Flinger”， 即 把 系统 中 所 有 应 用 程序 最 终 
的 “绘图 结果 ”进行 “混合 ”， 然 后 统一 显示 到 物理 屏幕 上 。 它 不 应 该 
也 没有 办 法 分 出 太 多 的 精力 去 逐一 关注 各 个 应 用 程序 的 “绘画 过 程 ”。 
这 个 光荣 的 任务 自然 而 然 地 落 在 了 BufferQueue 的 肩膀 上 ， 它 是 
SurfaceFlinger 派 出 的 代表 ， 也 是 每 个 应 用 程序 “一 对 一 ”的 辅导 老 
师 ， 指 导 着 U1 程 序 的 “画板 申请 ”、“ 作 男 流 程 ”等 一 系列 烦琐 细节 。 
图 9-17 描 述 了 它们 三 者 的 关系 。 
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[SurfaceComposerClient 


ButferQueuel | | Burfer()ueue2 SurfaceF linger 





全 图 9-17 应 用 程序 、BufferQueue 及 SurfaceFlinger 间 的 关系 


所 以 BootAnimation 在 其 构造 咀 数 中 就 建立 了 与 SurfaceFlinger 的 
连接 通道 。 那 么 ， 它 在 什么 时 候 会 再 去 建立 与 BufferQueue 的 连接 呢 ? 
因为 BootAnimation 继 承 自 RefBase， 当 main 电 数 中 通过 sp 指针 引用 它 
时 ， 会 触发 如 下 函数 : 


void BootAnimation: :onFirstRef() {// 第 一 次 被 引用 时 
status_t err = mSession->linkToComposerDeath(this);// 监 听 死 亡 导 
if (err == NO_ERROR) { 
run("BootAnimation"，PRIORITY_DISPLAY);// 开 启 线程 


TOUT 





当 一 个 Client 与 远程 Server 建 六 了 Binder 通 信和 后 ， 它 就 可 以 使 用 这 
个 Server 的 服务 了 ， 但 前 提 是 服务 器 运行 正常 。 换 句 话 说 ， 假 如 出 现 了 
Server 异 常 的 情况 ，Client 又 如 何 知道 呢 ? 这 就 是 
| inkToComposerDeath 要 解决 的 问题 ， 它 的 第 一 个 参数 指明 了 接收 
Binder Server 死 亡 事件 的 人 ， 在 本 例 中 就 是 BootAnimation 自 身 。 所 以 
BootAnimation 继 承 了 1Binder: :DeathRecipient， 并 实现 了 其 中 的 
binderDied 接 口 。 


如 果 上 一 步 没 有 出 错 的 话 (err == NO_ERROR) ， 接 下 来 就 要 启动 
一 个 新 线程 来 承载 业务 了 。 为 什么 需要 独立 创建 一 个 新 的 线程 呢 ? 前 面 
main 芳 数 中 ， 大 家 应 该 发 现 了 BootAnimation 启 动 了 Binder 线 程 池 。 可 
以 想象 在 只 有 一 个 线程 的 情况 下 ， 它 是 不 可 能 既 监 听 Binder 请 求 ， 又 去 
ee 当 一 个 新 的 线程 被 run 起 来 后 ， 又 触发 了 下 列 函 数 
调用: 


status_t BootAnimation::readyToRun() {... 
/* 第 一 部 分 ， 向 server 端 获取 buffer 空 间 ， 从 而 得 到 EGL 需 要 的 本 地 窗口 */ 
sp<SurfaceControl> control = session()->createSurface(String8 
dinfo.h, PIXEL_FORMAT_RGB_565); 
SurfaceComposerClient: :openGlobalTransaction(); 
control->setLayer (0x40000000) ; 
SurfaceComposerClient: :closeGlobalTransaction(); 
sp<Surface> s = control->getSurface(); 





/* 以 下 为 第 三 部 分 ， 即 EGL 的 配置 流程 */ 

const EGLint attribs[] = {.../* 属 性 值 较 多 ， 为 了 节约 篇 幅 ， 我 们 省 略 具 体 | 

EGLint w, h, dummy; 

EGLint numConfigs;// 总 共有 多 少 个 config 

EGLConfig config; 

EGLSurface surface; 

EGLContext context; 

EGLDisplay display = eglGetDisplay(EGL_DEFAULT_DISPLAY) ;// 第 一 

eglInitialize(display，0，0);// 第 二 步 ， 初 始 化 

eglChooseConfig(display, attribs, &config, 1, &numConfigs);// 

surface = eglCreateWindowSurface(display, config, s.get(), NU 
// 第 四 步 ， 通 

context = eglCcreateCcontext(display，config，NULL，NULL) ;// 第 五 








if (eglMakeCurrent(display, surface, surface, context) == EGL 
return NO_INIT; 


return NO_ERROR; 


这 个 遂 数 不 但 向 我 们 展示 了 应 用 程序 与 BufferQueue 的 通信 过 程 ， 
而 且 还 有 另外 一 个 重要 的 学 习 点 ， 即 0pengl ek ri AA 
的 应 用 篇 章 已 经 给 出 了 EGL 的 详细 使 用 范例 ， 这 里 则 可 以 作为 第 二 个 例 


pk HW readyToRun& iii session () aden ts aol 
SurfaceControl. #Hsession() 得 到 的 是 mSession 变 也 就 是 前 面 
构造 水 数 中 生成 的 SurfaceComposerClient 对 象 ， Br) Gr see uraos 0 
最 终 就 是 由 SurfaceFlinger 相 关联 的 服务 来 实现 的 。 具 体 而 言 ， 
SurfaceComposerClient 对 应 的 Server 端 的 实现 是 Client (C++) : 


/*frameworks/native/services/surfaceflinger/Client.cpp*/ 
status_t Client::createSurface (...) 


sp<MessageBase> msg = new MessageCreateLayer(mFlinger.get(), 
name, this, w, h, format, flags, handle, gbp); 

mF linger ->postMessageSync(msg) ;// 发 送 给 SurfaceF1Linger 进 行 处 理 

return static_cast<MessageCreateLayer*>( msg.get() )->getResu 














显然 这 个 函数 只 是 SurfaceF1inger 的 “秘书 ”， 它 将 用 户 的 请 求 通 
过 消息 推送 到 前 者 的 处 理 队列 中 ， 等 到 有 结果 后 才 返 回 〈 从 
postMessageSync 名 称 可 以 看 出 ， 这 是 一 个 同步 洱 数 ) 。 关 于 Client 与 
SurfaceFlinger 间 的 这 种 工作 方式 ， 我 们 会 放 在 后 续 SurfaceF | inger 小 
节 作 详细 解释 。 


因而 最 ee 只 不 过 “操作 的 内 
容 ” 又 是 由 Message 本 身 提供 自 


class MessageCreateLayer : public MessageBase 4... 
public: 


virtual bool handler() { 
result = flinger->createLayer(name, client, w, h, form 
return true; 


} 
Ja 


上 述 的 处 理 过 程 在 本 书 进 程 章节 分 析 Hand ler，Looper 等 元 素 的 关 
系 时 也 有 详细 讲解 ， 读 者 应 该 要 习惯 这 种 写法 。 现 在 的 问题 就 转换 为 : 
createLayer 生 成 了 什么 对 象 呢 ? 


没 错 ， 就 是 1GraphicBufferProducer。 


我 们 省 略 了 中 间 一 大 段 过程 ， 只 保留 与 问题 相关 的 部 分 ， 更 详细 的 
分 析 可 以 参见 后 续 小 节 


status_t SurfaceFlinger::createLayer(..sp<IBinder>* handle, sp<IGr 
status_t result = NO_ERROR; 


sp<Layer> layer; 
switch (flags & ISurfaceComposerClient::eFXSurfaceMask) { 
case ISurfaceComposerClient: :eFxSurfaceNormalL: //7#/i8Surfac 
result = createNormalLayer(client,name, w, h, flags, 
break; 
case ISurfaceComposerClient: :eFXSurfaceDim: 
result = createDimLayer(client,name, w, h, flags,hand 
break; 
default: 
result = BAD_VALUE; 
break; 


} 


return result; 


通过 上 面 的 代码 段 可 以 清楚 地 看 到 ，SurfaceFlinger 不 但 生成 了 
1GraphicBufferProducer 对 象 ， 而 且 引 入 了 新 的 概念 一 一 Layer。Layer 
类 在 SurfaceF linger 中 表示 “ 层 ”， 通 俗 地 讲 束 是 代表 了 一 个 “ 男 
m”, 最 终 物理 屏幕 上 的 显示 结果 就 是 通过 对 系统 中 同时 存在 的 所 
有 “画面 ”进行 处 理 而 得 到 的 。 这 就 好 比 一 排 人 列队 )〉 各 举 着 一 张 绘 
画作 品 ， 那 么 观察 者 从 最 前 面 往 后 看 时 ， 他 首先 看 到 的 束 是 第 一 张 男 ; 
而 假如 第 一 张 画 恰好 比 第 二 张 小 ， 又 或 者 第 一 张 是 透明 / 半 透 明 的 〈 这 
并 非 不 可 能 ， 如 作者 是 在 玻璃 上 创作 的 ) ， 那 么 他 就 能 看 到 第 二 张 画 。 
依 此 类 推 ， 最 终 看 到 的 惑 是 这 些 “ 男 ” (Layer) 的 混合 (Flinger) 结 


o 


这 个 类 比 告诉 我 们 ，layer 是 有 层级 的 ， 越 靠近 用 户 的 那 
Sie” RHA. 


AAR Six StB, ek e{BootAnimation: :readyToRun 接 下 来 调用 
setLayer 就 不 难 理解 了 。 不 过 参数 中 传 入 了 一 个 数值 0x40000000， 这 又 
是 什么 意思 ? 其 实 这 个 值 就 是 layer 的 层级 ， 在 显示 系统 中 通常 被 称 为 
Z-0rder， 而 且 数 字 越 大 就 越 靠 近 用 户 。 后 续 在 WindowManagerService 
章节 的 分 析 中 ， 我 们 还 会 看 到 对 setLayer 的 调用 。BootAnimation 显 示 
时 因为 整个 系统 中 还 只 有 开机 画面 一 个 应 用 程序 ， 所 以 并 不 需要 担心 Z- 
0rder 的 问题 。 换 句 话说 ，0x40000000 这 个 值 足 矣 。 


设置 完 层 级 后 ，readyToRun 接 着 调用 contro1->getSurface (来 得 
到 一 个 Surface 对 象 。 这 就 是 我 们 前 两 个 小 节 介 绍 的 两 个 本 地 窗口 中 的 
其 中 一 个 ， 不 清楚 的 读者 可 以 回头 复习 一 下 。 


涉及 的 相关 类 越 来 越 多 ， 相 信人 不 少 人 的 “大 脑 堆栈 ”已 经 有 点 混乱 
了 ， 因 此 我 们 有 必要 先 来 整理 下 目前 已 经 出 现 的 容易 混淆 的 各 个 类 的 关 
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ISurfaceComposerClient: 应 用 程序 与 SurfaceFlinger 间 的 通道 ， 
在 应 用 进程 中 则 被 封装 在 SurfaceComposerClient 这 个 类 中 。 这 是 一 个 
匿名 的 Binder Server， 由 应 用 程序 〈 具 体位 置 在 
SurfaceComposerClient: :onFirstRef 中 ) 调用 SurfaceFlinger 这 个 实 
名 Binder 的 createConnection 方 法 来 获取 到 ， 服 务 端的 实现 是 
SurfaceFlinger::Client。 


1GraphicBufferProducer: 由 应 用 程序 调用 
1SurfaceComposerClient: :createSurface( 得到， 同时 在 
SurfaceF1inger 这 一 进程 中 将 会 有 一 个 Layer 被 创建 代表 了 一 个 “ 男 
面 ”。1Surface 就 是 控制 这 一 画面 的 hand1e， 它 将 保存 在 应 用 程序 端的 
SurfaceControl 中 。 


Surface: 从 逻辑 关系 上 看 ， 它 是 上 述 1Surface 的 使 用 者 。 从 继承 
关系 上 看 ， 它 是 一 个 本 地 窗口 。Surface 内 部 持 有 
1IGraphicBufferProducer， 即 BufferQueue 的 实现 接口 。 换 个 角度 来 思 
考 ， 当 EGL 想 通过 Surface 这 个 Native Window 完 成 某 些 功 能 时 ， 后 者 实 
际 上 又 利用 1Surface 和 1GraphicBufferProducer 来 取得 远程 服务 端的 对 
应 服务 ， 以 完成 EGL 的 请 求 。 


回 到 BootAnimation: :readyToRun() 中 来 。 因 为 本 地 窗口 Surface 已 
经 成 功 创建 ， 接 下 来 就 该 E6L 上 场 了 。 具 体 流程 我 们 在 代码 中 都 加 了 注 
释 ， 这 里 就 不 再 蒙 述 。 


当 EGL 准 备 好 环境 后 ， 意 味 着 程序 可 以 正常 使 用 0penGL ES 提供 的 各 
种 AP1 了 水 数 进行 绘图 了 。 这 部 分 实现 就 集中 在 er (0) 以 及 
android()/movieQO 中 。 因 为 不 属于 本 小 节 的 讨论 范围 ， 有 兴趣 的 读者 
可 以 自行 参阅 学 习 。 


后 来 做 下 小 结 ， 一 个 典型 的 应 用 程序 使 用 SurfaceF1inger 进 行 绘 
ae 18 所 示 CE 
Surface、SurfaceControl、Layer 等 太 多 元 素 ， 只 选取 部 分 重点 类 进行 
Fem) o 
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1 EGL 根据 这 个 本 地 窗口 进 行 初始 化 ， 建 立 OpenGL 
| 环境 ， 然 后 应 用 程序 就 可 以 调用 API 进行 绘图 了 


全 图 9-18 应 用 程序 通过 SurfaceFlinger 进 行 绘图 的 典型 流程 


图 9-18 是 从 时 序 纵向 ) 角度 总 结 出 来 的 流程 ， 我 们 再 从 横向 的 角 
度 来 分 析 下 ， 相 信 大 家 应 该 会 更 清楚 ， 如 图 9-19 所 示 。 


从 图 9-19 中 可 以 看 到 ， 涉 及 的 类 还 是 比较 多 的 ， 而 且 多 数 都 涉及 跨 
进程 通信 。 和 希望 大 家 能 熟 记 这 两 张 图 一 一 在 后 几 个 小 节 的 学 习 中 ， 感 党 
HALA BATA ABA, LAMAR. 
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全 图 9-19 从 横向 角度 考查 Surface 相 关 类 的 关系 


9.5.4 应 用 程序 与 BufferQueue 的 关系 
接着 上 一 小 节 未 解决 完 的 问题 继续 讲解 。 


现在 我 们 已 经 明白 了 应 用 程序 利用 SurfaceFlinger 进 行 绘制 工作 的 
大 致 流程 ， 只 不 过 在 这 个 过 程 中 直到 最 后 才 出 现 了 BufferQueue。 那 
应 用 程序 具体 是 如 何 借助 BufferQueue 来 完成 工作 的 呢 ? 


仔细 观察 不 难 发 现 ， 当 应 用 程序 端 通 过 
|SurfaceComposerCl ient: :createSurface (来 发 起 创建 Surface 的 请 求 
时 ，SurfaceFlinger 服 务 进 程 这 边 会 创建 一 个 Layer 。 既 然 Layer 代 表 了 
一 个 画面 图 层 ， 那 么 它 肯定 需要 存储 “图 层 数据 ”的 地 方 ， 因 而 我 们 选 
择 以 这 里 作为 入 口 : 


/*frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp*/ 

status_t SurfaceFlinger::createLayer(const String8& name, const s 
uint32_t w, uint32_t h, PixelFormat format, uint32_t flag 
sp<IBinder>* handle, sp<IGraphicBufferProducer>* gbp) 


status_t result = NO_ERROR; 
sp<Layer> layer; 


switch (flags & ISurfaceComposerClient: :eFXSurfaceMask) {//La 

case ISurfaceComposerClient: :eFXSurfaceNormal: //7#iiiLayer 
result = createNormalLayer(client, name, w, h, flags, 
break; 

case ISurfaceComposerClient: :eFXSurfaceDim: //DimaRijLaye 
result = createDimLayer(client, name, w, h, flags, ha 
break; 

default: 
result = BAD_VALUE; 
break; 


} 

if (result == NO_ERROR) { 
addClientLayer(client, *handle, *gbp, layer) ;//i#®m2le ah 
setTransactionFlags(eTransactionNeeded) ;//i HWS 


return result; 


这 个 函数 用 于 生成 一 个 Layer 。 从 enum 值 定义 来 看 ， 当 前 系统 中 有 
多 达 十 几 种 Layer 类 型 ， 只 不 过 多 数 还 没有 真正 实现 。 目 前 能 用 的 只 
两 个 ， 即 eFXSurfaceNorma1 和 eFXSurfaceDim。 第 一 种 就 是 正常 情况 下 
的 图 层 ; 第 二 种 是 指 带 有 Dim 效 果 的 “图 层 ”。 顺 便 提 一 下 ， 早 前 版 本 
中 还 有 一 种 Blur 效 果 的 Layer。 可 能 出 于 效率 的 考虑 ， 当 前 系统 中 已 经 
纺 一 将 它 用 Dim 替 代 了 。 


相信 在 后 续 的 Android 版 本 中 还 会 把 它们 再 区 分 开 来 。 


最 终 返 回 给 调用 者 的 有 两 个 : 即 handle 和 gbp。 前 者 是 一 个 1Binder 
对 象 ， 后 者 则 是 大 家 熟悉 的 1GraphicBufferProducer 。 


Layer 和 handle 及 gbp 有 什么 联系 呢 ? 我 们 选取 eFXSurfaceNormal 类 
型 的 图 层 来 深入 分 析 : 


status_t SurfaceFlinger::createNormalLayer(const sp<Client>& clie 
const String8& name, uint32_t w, uint32_t h, uint32_t fla 
sp<IBinder>* handle, sp<IGraphicBufferProducer>* gbp, sp< 
{...//format 的 赋值 过 程 省 上 略 
*outLayer = new Layer(this, client, name, w, h, flags);// 生 成 L 
status_t err = (*outLayer)->setBuffers(w, h, format, flags);/ 
if (err == NO_ERROR) { 
*handle = (*outLayer )->getHandle();//handleihiwix + H BGR 
*gbp = (*outLayer)->getBufferQueue();//gbp 是 从 Layer 中 取出 来 


ALOGE_IF(err, "createNormalLayer() failed (%s)", strerror(-er 
return err; 


上 面 这 个 函数 的 逻辑 很 简单 : 新 建 Layer 对 象 ， 设 置 Buffers 的 属性 
(setBuffers) ， 然 后 分 别 通过 getHandle 和 getBufferQueue 获 得 
handle 及 gbp。 


先 来 看 看 hand1e 到 底 是 何方 “神圣 ” 


sp<IBinder> Layer::getHandle() { 
Mutex::Autolock _1(mLock); 


Class Handle : public BBinder, public LayerCleaner {//Handle” 
wp<const Layer> mOwner,; 
public: 
Handle(const sp<SurfaceFlinger>& flinger, const sp<Layer> 
LayerCleaner(flinger, layer), mOwner(layer) {// 空 的 ， 


; } 
return new Handle(mFlinger,，this);// 新 建 一 个 Handle 对 象 





Android 4. 1 系统 中 有 一 个 1Surface， 功 能 和 Handle 有 点 类 似 。 不 
过 4. 1 版 本 中 有 很 多 宛 余 的 类 定义 ， 使 得 整个 Surface 机 制 显得 条 重 而 难 
以 理解 一 一 可 能 是 为 了 改善 这 个 问题 ，4. 3 系统 中 已 经 对 这 些 类 进行 了 
整合 及 移 除 。 


由 这 段 代 码 可 以 看 出 ，Handle 几 乎 没有 任何 有 用 的 内 容 。 那 么 ， 其 
设计 初衷 是 什么 ? 


仔细 观察 可 以 发 现 ，Handle 继 承 了 LayerCleaner。 从 字面 意思 来 
看 ， 它 是 “图 层 清理 者 ”， 清 理 时 机 如 下 所 示 : 


Layer::LayerCleaner::~LayerCleaner() { 
// destroy client resources 
mFlinger->onLayerDestroyed(mLayer); 


也 就 是 说 ， 当 LayerCleaner (或 者 Handle〉 进行 析 构 操作 时 ， 会 
主动 调用 SurfaceF1linger 的 onLayerDestroyed 来 收拾 “图 层 残局 ”。 
句 话说 ， 一 旦 没有 人 引用 此 Hand1e 对 象 ， 系 统 就 会 开始 清理 工作 ， 是 不 
是 很 方便 ? 


了 解 了 Handle 后 ， 我 们 再 来 分 析 Layer 中 的 另 一 个 重要 元 素 ， 即 


BufferQueue : 


H Se DH 


/*frameworks/native/services/surfaceflinger/Layer .cpp*/ 
sp<BufferQueue> Layer: :getBufferQueue() const { 
return mSurfaceFlingerConsumer ->getBufferQueue(); 


SurfaceFlinger 自 认为 是 “Consumer” 还 是 比较 贴切 的 。 而 这 个 消 
费 者 的 另 一 个 职责 居然 是 提供 Buffer 空间 ， 真 是 “一 条 龙 服 务 ”。 我 们 
可 以 来 看 看 SurfaceF1inger 是 如 何 提 供 的 BufferQueue， 其 中 又 涉及 多 
个 类 的 继承 ， 如 图 9-20 所 示 。 


RefBase BufferQueue::ConsumerListener 


+onFrameAvailable() 
+onButfersReleased() 
À 


—sp<BulferQueue>mBufferQueue; 
—wp<FrameAvailableListener>mFrameAvailableL istener; 


+o9etBufferQueue() 


/\ 
N 
SurfaceFlingerConsumer 


+updateTexImage() 
+bindTexturelmage() 


A 9-20 ”SurfaceFlingerConsumer 的 继承 关系 


从 图 中 可 以 看 到 ，SurfaceFlingerConsumer 中 真正 持 有 
BufferQueue 对 象 的 是 成 员 变 量 ConsumerBase: :mBufferQueue， 那 么 这 
个 变量 又 是 怎么 赋值 的 呢 ? 


其 实 还 是 在 Layer 中 ， 即 当 有 人 第 一 次 引用 Layer 时 触发 了 它 的 
onFirstRef。 此 时 : 


void Layer::onFirstRef() 


sp<BufferQueue> bq = new SurfaceTextureLayer (mFlinger );// 这 是 人 
mSurfaceFlingerConsumer = new SurfaceFlingerConsumer (mTexture 
GL_TEXTURE_EXTERN. 


又 有 一 个 新 面孔 出 现 了 ， 即 SurfaceTextureLayer， 人 很 显然 它 应 该 
是 BufferQueue 的 子 类 。 有 兴趣 的 读者 可 以 自行 研究 下 其 在 BufferQueue 
的 基础 上 提供 了 哪些 新 功能 。 


这 样 就 基本 清楚 了 ，Layer 中 直接 或 者 间接 地 提供 了 Handle 和 
BufferQueue， 而 且 两 者 都 是 匿名 的 Binder Server。 当 客户 端 应 用 程序 
调用 createSurface 时 ， 它 可 以 同时 获取 到 这 两 个 重要 对 象 。 大 家 一 定 
要 记 住 ，1GraphicBufferProducer 的 Server 端 的 实现 是 BufferQueue。 
由 于 命名 上 的 差异 ， 这 点 很 容易 搞 错 。 


因而 应 用 程序 与 BufferQueue 的 关系 就 比较 明朗 了 。 虽 然 中 间 经 历 
了 多 次 跨 进 程 通信 ， 但 对 于 应 用 程序 来 说 最 终 只 使 用 到 了 
BufferQueue 〈 通 过 1GraphicBufferProducer ) 。 


本 小 节 可 以 从 侧面 证 明 如 下 几 个 关键 点 。 


(1) 应 用 程序 可 以 调用 createSurface 来 建立 多 个 Layer， 它 们 是 
一 对 多 的 关系 。 理 由 就 是 createSurface 中 没有 任何 机 制 来 限制 应 用 程 
序 的 多 次 调用 ; 相反 ， 它 会 对 一 个 应 用 程序 多 次 申请 而 产生 的 Layer 进 
行 统一 管理 。 如 下 所 示 : 


status_t SurfaceFlinger::createLayer (...) 


if (result == NO_ERROR) { 





addClientLayer(client, *handle, *gbp, layer) ;//i#sn#i4WLayer3 
setTransactionFlags(eTransactionNeeded ) ; 


J 


为 应 用 程序 申请 的 Layer， 一 方面 需要 告知 SurfaceF1inger， 另 一 
方面 要 记录 到 各 Client 内 部 中 。 这 两 个 步骤 是 由 addClientLayer () 分 别 
调用 Client: :attachLayer () 和 SurfaceFlinger::addLayer_1 0 来 完成 
的 : 


void SurfaceFlinger: :addClientLayer(const sp<Client>& client,cons 
const sp<IGraphicBufferProducer>& gbc,const sp<Layer>& lb 
{ 


// attach this layer to the client 
client->attachLayer(handle，1bc);// 让 此 Layer 与 CLient 相 关联 


// add this layer to the current state list 

Mutex: :Autolock _1(mStateLock); 

mCurrentState. layersSortedByZ.add(lbc) ;//#Layer sai FSAI 
mGraphicBufferProducerList.add(gbc->asBinder());//#gbcty syn 21 


对 于 SurfaceF1inger， 它 需要 对 系统 中 当前 所 有 的 Layer 进 行 Z- 
Order 排 序 ， 以 决定 用 户 所 能 看 到 的 “画面 ”是 什么 样 的 ; 对 于 
Client， 它 则 利用 内 部 的 mLayers 成 员 变 量 来 逐一 记录 新 增 

(attachLayer) 和 移 除 (detachLayer) 的 图 层 。 从 中 不 难看 出 ， 一 个 
Client 是 可 以 包含 多 个 Layer 的 。 


(2) 每 个 Layer 对 应 一 个 BufferQueue。 换 名 话说， 一 个 应 用 程序 
可 能 对 应 多 个 BufferQueue。 另 外 ，Layer 没 有 直接 持 有 BufferQueue 对 
象 ， 而 是 由 其 内 部 的 mSurfaceFlingerConsumer 来 管理 。 


我 们 以 图 9-21 来 结束 本 小 节 的 学 习 。 
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全 图 9-21 应 用 程序 与 BufferQueue 的 对 应 关系 


9.6 SurfaceFl inger 


从 本 小 节 开 始 ， 我 们 正式 切入 SurfaceFlinger 的 分 析 。 为 了 保持 讲 
解 的 连贯 性 ， 部 分 内 容 可 能 在 前 面 的 章节 中 已 经 有 所 涉及 ， 接 下 来 将 会 
对 其 中 的 细节 做 更 多 的 扩展 讲解 。 


内 容 组 织 如 下 。 


首先 介绍 从 Android 4.1 版 本 起 引入 的 一 个 新 特性 (Project Butter) 。 

理解 这 个 项 目 是 必要 的 ， 可 以 说 SurfaceFlingetr 有 很 大 一 部 分 内 容 就 
是 围绕 它 展 开 的 。 

SutfaceFlinget 的 尼 动 过 程 及 工作 方式 。 

SurfaceFlinger 与 BufferQueue 及 应 用 程序 间 的 关系 。 

SurfaceFlinger 对 VSYNC 信 号 的 处 理 过 程 (重点 ) 。 


9.6.1 “黄油 计划 ”一 一 Project Butter 

为 什么 会 叫 这 个 名 字 呢 ?一 个 可 能 的 原因 就 是 这 个 Project 的 目的 
是 改善 用 户 抱 怨 最 多 的 Android 几 大 缺陷 之 一 ， 即 U1 响应 速度 
Goog1e 希 望 这 一 新 计划 可 以 让 Android 系 统 摆 脱 “U1 交 互 ” 上 的 “ 灌 
后 ” 感 ， 而 能 像 加 了 黄油 一 般 “ 顺 滑 ”。Goog1le 在 2012 年 的 1/0 大 会 上 
宣布 了 这 一 计划 ， 并 在 Android 4. 1 中 正式 搭载 了 具体 的 实现 机 制 |。 


Butter 中 有 两 个 重要 的 组 成 部 分 ， 即 VSync 和 Triple Buffering. 
下 面 先 分 别 介绍 引入 它们 的 原因 。 


喜欢 玩 游戏 或 者 看 电影 的 读者 可 能 经 常 遇 到 以 下 情 天 
汞 些 游 戏 场面 好 像 由 几 个 场景 “拼凑 ”而 成 。 
电影 画面 不 连贯 ， 好 像 被 “割裂 ”了 。 


这 样 描述 有 点 抽象 ， 我 们 引用 wikipedia 上 的 一 张 图 来 看 下 实际 效 
果 ， 如 图 9-22 所 示 。 


我 们 把 这 种 显示 错误 称 为 “Screen Tearing”， 那 么 为 什么 会 出 现 





这 样 的 情况 呢 ? 
相信 大 家 都 能 得 出 结论 ， 那 就 是 屏幕 上 显示 的 画面 实际 上 来 产 于 多 


个 “ml” 5 


在 一 个 典型 的 显示 系统 中 ，Frame Buffer 代 表 了 屏幕 即将 要 显示 的 
一 帧 画面 。 假 如 CPU/GPU 绘 图 过 程 与 屏幕 刷新 所 使 用 的 buffer 是 同一 
块 ， 那 么 当 它们 的 速度 不 同步 的 时 候 ， 则 很 可 能 出 现 类 似 的 画面 “ 割 
有 裂 ”。 举 个 具体 的 例子 ， 假 设 显 示 器 的 刷新 率 为 66Hz， 而 CPU/XGPU 的 绘 
人 也 就 是 它们 处 理 完 成 一 帧 数据 分 别 需要 0. 015 秒 和 
0. 01 秒 。 
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全 图 9-22 Screen Teating 实 例 {-:-} 注 : 引 自 
http://en.wikipedia.org/ wiki/ File:Tearing_%28simulated%29.jpgo 


以 时 间 为 横 坐 标 来 描述 接 下 来 会 发 生 的 事情 ， 如 图 9?-23 所 示 。 





全 图 9-23 Screen Tearing * # it FED 


上 半 部 分 的 方 框 表 示 在 不 同 的 时 间 点 时 显示 屏 的 内 容 〈 加 深 的 部 
分 ) ， 下 半 部 分 则 是 同一 时 间 点 时 Frame Buffer 中 的 数据 状态 ， 编 号 表 
示 第 几 个 frame 帧 ， 不 考虑 清 屏 。 

e 0.01 秒 


由 于 两 者 速率 相差 不 少 ， 此 时 buffer 中 已 经 准备 好 了 第 1 帧 数据 ， 
而 显示 器 只 显示 了 第 1 帧 画面 的 2/3。 


e 0.015 秒 


第 1 帧 画面 在 显示 屏 上 终于 完整 地 显示 了 出 来 ， 而 此 时 buffer 中 有 
1/3 的 部 分 已 经 被 填充 上 第 2 帧 数据 了 。 


。 0.024) 


Buffer 中 已 经 准备 好 了 第 2 帧 数据 ， 而 显示 屏 出 现 了 Screen 
Tearing: 有 三 分 之 一 的 内 容 属 于 第 2 帧 ， 其 余 的 则 来 源 于 第 1 帧 画面 。 


在 单 缓冲 区 的 情况 下 ， 这 个 问题 是 很 难 规避 的 。 所 以 之 前 我 们 介绍 
的 双 缓 冲 技术 ， 其 基本 原理 就 是 采用 了 两 块 buffer 其 中 一 块 Back 
Buffer 用 于 CPU/GPU 后 台 绘 制 ， 另 一 块 Frame Buffer 则 用 于 屏幕 显示 ; 
“Back Buffer 准 备 就 绪 后 ， 它 们 才 进 行 交 换 。 不 可 否认 ，Double 
Buffer ing 可 以 在 很 大 程度 上 降低 Screen Tear ing 类 型 的 错误 ， 但 它 是 
万 能 的 吗 ? 


一 个 需要 考虑 的 问题 是 : 我 们 应 该 每 隔 多 少时 间 点 进行 两 个 缓冲 区 
的 交换 呢 ? 假如 是 Back Buffer 准 备 完 成 一 帧 数据 以 后 就 进行 ， 那 么 如 
果 此 时 屏幕 还 没有 完整 显示 上 一 帧 内 容 ， 肯 定 是 会 出 问题 的 。 看 来 只 能 
等 到 屏幕 处 理 完 一 帧 数据 后 ， 才 可 以 执行 这 一 操作 。 


我 们 知道 ， 一 个 典型 的 显示 器 有 两 个 重要 特性 ， 即 “ 行 频 和 场 
频 ”。 行 频 (Horizontal Scanning Frequency) 又 称 为 “水 平 扫 描 频 
率 ”， 是 屏幕 每 秒 钟 从 左 至 右 扫描 的 次 数 ; 场 频 (Vertical Scanning 
Frequency) 也 称 为 “垂直 扫描 频率 ”， 是 每 秒 钟 整个 屏幕 刷新 的 次 
数 。 由 此 也 可 以 得 出 它们 的 关系 : 行 频 = 场 频 * 纵 坐标 分 辩 率 。 


当 扫 描 完 一 个 屏幕 后 ， 设 备 需要 重新 回 到 第 一 行 以 进入 下 一 轮 的 循 
环 ， 此 时 有 一 段 时 间 空 隙 ， 称 为 Vertical Blanking Interval (VBI). 
大 家 应 该 能 想到 ， 这 个 时 间 点 就 是 我 们 进行 缓冲 区 交换 的 最 佳 时 间 。 
为 此 时 屏幕 没有 在 刷新 ， 也 就 避免 了 交换 过 程 中 出 现 Screen Tear ing 的 
状况 。Vsync 〈 重 直 同 步 ) 是 Vertical Synchronization 的 简写 ， 它 利 
用 VB1 时 期 出 现 的 Verti cal Sync Pul se 来 保证 双 缓 冲 能 在 最 佳 时 间 点 进 
行 交 换 。 


所 以 说 VSync 这 个 概念 并 不 是 Google 首 创 的 ， 而 是 在 早 些 年 前 的 PC 
领域 就 已 经 出 现 了 。 不 过 Android 4. 1 赋予 了 它 新 的 功用 ， 稍 后 就 可 以 
看 到 。 


上 面 我 们 讨论 的 情况 其 实 是 基于 一 个 假设 ， 即 绘图 速度 大 于 显示 速 
度 ， 那 么 如 果 反 过 来 呢 ? 绘图 过 程 中 没有 采用 VSync 同 步 时 如 图 9?-24 所 
/小 。 
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全 图 9-24 绘图 过 程 中 没有 采用 VSync 同 步 的 情况 


此 图 和 后 续 几 张 图 均 引 用 自 Google 2012 IO 大 会 的 主题 演讲 ， 作 者 是 
Chet Haase 和 Romain Guy(Android UI Toolkit Engineers). 


图 ?-24 中 有 3 个 元 素 ，Display 表 示 显 示 屏 幕 ，GPU 和 CPU 负责 泻 染 帧 
数据 。 每 一 帧 以 方 框 表 示 并 以 数字 进行 编号 ， 如 0、1、2 等 。VSync 用 于 
指导 双 缓 冲 区 的 交换 。 


以 时 间 的 顺序 来 看 看 当 不 采用 VSync 同 步 时 将 会 发 生 什 么 异常 。 


Step1. Display 显 示 第 0 帧 数据 ， 此 时 CPU 和 GPU 泻 染 第 1 帧 画面 ， 而 
且 赶 在 Display 显 示 下 一 帧 〈 帧 1) 前 完成 。 


Step2.， 因 为 泻 染 及 时 ，Display 在 第 0 帧 显示 完成 后 ， 也 就 是 第 1 个 
VSync 后 ， 正 常 显 示 第 1 帧 。 


Step3， 由 于 茶 些 原因 《比如 CPU 资源 被 占用 ) ， 系 统 没 能 及 时 地 处 
理 第 2 帧 ， 而 是 等 到 第 2 个 VSync 到 来 前 才 开 始 处 理 。 


Step4. 第 2 个 VSync 来 临时 ， 由 于 第 2 帧 数据 还 没有 准备 就 绪 ， 实际 
显示 的 还 是 第 1 帧 的 内 容 。 这 种 情况 被 Android 开 发 组 命名 为 “Jank” 。 


Step5， 当 第 2 帧 数据 准备 完成 后 ， 它 并 不 会 立即 被 显示 ， 而 是 要 等 
待 下 一 个 VSync。 


所 以 总 的 来 说 ， 就 是 屏幕 “ 平 白 无 故 ” 地 重复 显示 了 一 次 第 1 帧 。 
原因 大 家 应 该 都 看 到 了 ， 就 是 CPU 没有 及 时 地 着 手 处 理 第 2 帧 的 演 染 工 
作 ， 以 臻 “延误 军机 ”。Android 系 统 中 一 直 存 在 着 这 个 问题 ， 直 到 
Project Butter 的 引入 。 


MAndroid 4.1 Jelly Bean 开 始 ，VSync 得 到 了 进一步 的 应 用 一 一 
系统 在 收 到 VSync Pulse 后 ， 将 立即 开始 下 一 帧 的 泻 染 ， 如 图 9?-25 所 
7JNo 
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全 图 9-25 整个 显示 系统 都 以 VSync 进 行 同 步 的 情况 


图 中 展示 的 是 采用 VSync 进 行 显示 同步 的 情况 。 一 旦 VSync 信 号 出 
现 ，CPU 便 不 再 犹豫 ， 即 刻 开 始 执行 Buffer 的 准备 工作 。 大 部 分 的 
Android 显 示 设 备 刷 新 频率 是 60Hz， 这 也 就 意味 着 每 一 帧 最 多 只 能 留 给 
系统 1/60=16ms 左 右 的 准备 时 间 。 假 如 CPU/GPU 的 FPS (Frames Per 
Second) 高 于 这 个 值 ， 那 么 这 个 方案 是 完美 的 ， 显 示 效 果 将 很 好 。 


可 是 我 们 没有 办 法 保证 所 有 设备 的 硬件 配置 都 能 达到 要 求 。 假 如 
CPU/XGPU 的 性 能 无 法 满足 上 图 条 件 ， 又 会 是 什么 情况 呢 ? 


在 分 析 这 一 问题 之 前 ， 我 们 先 来 看 看 采用 双 缓 冲 区 系统 的 运行 情 
况 ， 如 图 9-26 所 示 。 
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全 图 9-26 采用 VSync 和 双 缓 冲 机 制 的 情况 
图 中 采用 了 双 缓 冲 技 术 以 及 前 面 介 绍 的 VSync 同 步 机 制 ， 可 以 看 到 
整个 显示 过 程 还 是 相当 不 错 的 。 哩 然 CPU/GPU 处 理 所 用 的 时 间 时 短 时 
长 ， 但 总 的 来 说 都 在 16ms 以 内 ， 因 而 不 影响 显示 效果 。A 和 B 分 别 代表 两 
个 缓冲 区 ， 它 们 不 断 地 互相 交换 以 保证 画面 的 正确 显示 。 


现在 我 们 可 以 继续 分 析 FPS 低 于 屏幕 刷新 率 的 情况 了 ， 如 图 9-27 所 





全 图 9-27 FPS 低 于 屏幕 刷新 率 的 情况 


如 果 CPU/GPU 的 处 理 时 间 超 过 16ms， 那 么 第 一 个 VSync 到 来 时 ， 绥 冲 
区 B 中 的 数据 还 没有 准备 好 ， 就 只 能 继续 显示 之 前 A 缓冲 区 中 的 内 容 。 m 
B 完 成 后 ， 又 因为 缺乏 VSync Pul se 信号 ， 也 只 能 等 到 下 一 轮 才 有 机 会 
换 了 。 于 是 在 这 一 过 程 中 ， 有 一 大 段 时 间 是 被 浪费 的 。 本 
出 现时 ，CPU/GPU 马 上 执行 操作 ， 此 时 它 可 操作 的 Buffer 是 A， 相 应 的 显 
示 屏 对 应 的 就 是 g。 这 时 看 起 来 就 是 正常 的 。 只 不 过 由 于 执行 时 间 仍 然 
超过 16ms ， 导 致 下 一 次 应 该 执行 的 缓冲 区 交换 又 被 推迟 一 一 如 此 循环 反 





复 ， 便 出 现 了 越 来 越 多 的 “Jank”。 
那么 ， 有 没有 规避 的 办 法 呢 ? 


很 显然 ， 第 一 次 的 Jank 看 起 来 是 没有 办 法 的 ， 除 非 升 级 硬件 配置 来 
加 快 FPS。 我 们 关注 的 重点 是 被 CPU/GPU 浪 费 的 时 间 段 怎么 才能 充分 利用 
起 来 。 分 析 上 述 过 程 ， 造 成 CPU/GPU 无 事 可 做 的 假象 是 因为 当前 已 经 没 
有 可 用 的 buffer 了 。 换 句 话 说， 如 果 增 加 一 个 Buffer， 情 况 会 不 会 好 转 
We? 如 图 9-28 所 示 。 
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全 图 9-28 Triple Buffering 


Triple Buffering 是 Multiple Buffering 的 一 种 ， 指 的 是 系统 使 用 
3 个 缓冲 区 用 于 显示 工作 。 我 们 逐步 分 析 下 这 个 新 机 制 是 否 有 效 。 首 先 
和 预料 中 的 一 致 ， 第 一 次 “Jank” 无 可 厚 非 。 不 过 让 人 欣慰 的 是 ， 当 第 
一 次 VSync 发 生 后 ，CPU 不 用 再 等 待 了 ， 它 会 使 用 第 三 个 Buffer C 来 进行 
下 一 帧 数据 的 准备 工作 。 哩 然 对 缓冲 区 C6 的 处 理 所 需 时 间 同 样 超过 了 
16ms， 但 这 并 不 影响 最 终 的 显示 第 二 次 VSync 到 来 后 ， 它 选择 
Buffer B 进 行 显 示 ; 而 到 了 第 三 次 VSync 时 ， 它 会 接着 采用 C6， 而 不 是 像 
Double Buffering 中 所 看 到 的 只 能 再 显示 一 遍 B。 这 样 就 有 效 地 降低 了 
系统 显示 错误 的 概率 。 


前 面 小 节 我 们 看 到 BufferQueue 中 最 多 有 32 个 BufferSlot， 不 过 在 
实际 使 用 时 的 具体 值 是 可 以 设置 的 。 


e TARGET_DISABLE_TRIPLE_BUFFERING 





这 个 宏 用 于 Disable Triple Buffering。 如 果 宏 打开 的 话 ， 
Layer. cpp 在 onF irstRef 有 如 下 操作 。 


#ifdef TARGET_DISABLE_TRIPLE_BUFFERING 
#warning "disabling triple buffering" 
mSurfaceFlingerConsumer ->setDefaultMaxBufferCount (2); 
#else 
mSurfaceFlingerConsumer ->setDefaultMaxBufferCount(3) ; 
#endif 


mSur faceF | ingerConsumer : :setDefaultMaxBufferCount 将 进一步 
调用 BufferQueue: :setDefault MaxBufferCount， 然 后 把 Buffer 数 〈2 
或 者 3) 保存 到 BufferQueue 内 部 的 mDefaultMaxBufferCount 成 员 变 量 


o 


。 对 于 应 用 程序 来 说 ， 它 也 可 以 通过 
IGraphicBufferProducet::setBufferCount 来 告诉 BufferQueue 它 所 希望 的 
Slot 值 一 一 这 个 操作 最 终 影响 的 是 BufferQueue 中 的 另 一 个 成 员 变 量 
mOverride MaxBufferCount (而 不 是 mDefaultMaxBufferCount) . $È 
认 情 况 下 这 个 变量 是 0， 表 示 应 用 端 不 关心 到 底 有 多 少 Buffer 可 用 。 

。 在 具体 的 实现 中 ， 以 上 两 个 变量 都 是 要 考虑 到 的 ，BufferQueue 会 通 





过 权衡 各 个 值 来 选择 最 佳 的 解决 方案 。 


请 大 家 务必 结合 本 小 节 分 析 的 几 种 情况 ， 理 解 清楚 Android 系 统 引 
入 Triple Buffering，VSync 机 制 的 原因 。 只 有 带 着 这 些 理解 进入 
SurfaceFlinger 的 分 析 中 ， 才 能 让 大 家 的 学 习 “ 有 的 放 矢 ”， 对 源码 的 
剖析 过 程 也 才能 “事半功倍 ”。 


9.6.2 SurfaceFlinger 的 启动 


SurfaceFlinger 的 局 动 和 ServiceManager 有 点 类 似 ， 它 们 都 属于 系 
统 的 底层 支撑 服务 ， 因 而 必须 在 设备 开机 的 早期 就 运行 起 来 : 


/*frameworks/base/cmds/system_server/library/System_init.cpp*/ 
extern "C" status_t system_init() 


{... 
property_get("system_init.startsurfaceflinger", propBuf, "1") 
if (strcmp(propBuf, "1") == 0) { 
SurfaceFlinger::instantiate(); 
J 


这 个 System_init. cpp 会 被 编译 到 1ibsystem_server 库 中 ， 然 后 由 
SystemServer 在 JN1 层 进行 加 载 调用 ， 从 而 启动 包括 SurfaceF1inger， 
SensorService 等 在 内 的 系统 服务 。 


和 我 们 将 会 在 后 续 AudioFlinger/AudioPolicyService 章 节 看 到 的 
情况 一 样 ，system_init 调 用 instantiate 来 创建 一 个 Binder Server, 
名 称 为 “SurfaceFlinger”; 而 且 强 指针 的 特性 让 它 在 第 一 次 被 引用 时 
触发 了 onFirstRef : 


void SurfaceFlinger: :onFirstRef() 


mEventQueue ,init(this),;// 初 始 化 事件 队列 
run("SurfaceFlinger", PRIORITY_URGENT_DISPLAY) ;// 启 动 一 个 新 的 业 : 
mReadyToRunBarrier .wait( );// 等 待 新 线程 启动 完毕 


成 员 变 量 mEventQueue 是 一 个 MessageQueue 类 型 的 对 象 ， 我 们 在 进 
程 章 节 已 经 详细 分 析 过 消息 队列 与 Looper，Handler 等 类 的 使 用 ， 大 家 
可 以 先 回头 参考 下 (虽然 Java 层 的 这 些 类 与 SurfaceFlinger 中 用 到 的 有 
一 定 差异 ， 但 其 本 质 原理 是 一 样 的 ) 。 既 然 有 消息 队列 ， 那 就 一 定 会 有 
配套 的 事件 处 理 器 Handler 以 及 循环 体 Looper， 这 些 是 在 


MessageQueue: :init 国 数 中 创建 的 。 即 : 


/*frameworks/native/services/surfaceflinger/MessageQueue.cpp*/ 
void MessageQueue: :init(const sp<SurfaceFlinger>& flinger ) 


{ 
mFlinger = flinger; 
mLooper = new Looper(true); 
mHandler = new Handler(*this);// 此 Handler 类 是 SurfaceFlinger 自 己 


也 就 是 说 ， 这 个 MessageQueue 类 不 但 提供 了 消息 队列 ， 其 内 部 还 于 
括 了 消息 的 处 理 机 制 ， 可 谓 一 个 “大 杂烩 ”。 那 么 ， 这 个 Looper 会 在 什 
么 时 候 运 行 起 来 呢 ? 显然 SurfaceFlinger 需 要 先 自行 创建 一 个 新 的 线程 
来 承载 这 一 “业务 ”， 否 则 就 会 阻塞 SystemServer 的 主线 程 ， 这 一 点 和 
AudioFlinger 是 有 区 别 的 。 函 数 最 后 的 mReadyToRunBarr ier. wait () 也 
可 以 证 明 这 一 点 一 一 mReadyTo RunBarr ier 在 等 待 一 个 事件 ， 在 事件 没 
有 发 生前 其 所 在 的 线程 就 会 处 于 等 待 状态 。 这 是 Android 系 统 里 两 个 线 
程 间 的 一 种 典型 交互 方式 。 举 个 例子 ，A 线 程 将 启动 B 线 程 ， 并 且 A 接 下 
来 的 工作 会 依赖 于 B。 换 句 话说 ，A 必 须要 等 到 B 说 “好 了 ， 我 已 经 
0K” 了 才能 继续 往 下 走 ， 否 则 就 会 出 错 。 由 此 可 见 ，SurfaceFlinger 新 
启动 的 这 个 线程 中 一 定 还 会 调用 mReadyToRunBarrier. open 来 为 等 待 它 
的 线程 解禁 。 


这 样 我 们 也 能 推断 出 SurfaceF1inger 一 定 是 继承 自 Thread 线 程 类 
的 。 如 下 所 示 : 


class SurfaceFlinger :public BinderService<SurfaceFlinger>, 


private Thread, 


PRLA_EiSurfaceF linger: :onFirstRef mya ALLA 
Thread: :run () 方 法 来 启动 一 个 名 为 “SurfaceFlinger” 的 线程 ， 并 为 
其 设置 了 PRIORITY_URGENT_DISPLAY 的 优先 级 。 这 个 优先 级 是 在 
ThreadDefs. h 中 定义 的 ， 如 表 9-6 所 示 。 


数值 越 大 的 ， 优 先 级 越 小 。 因 为 各 等 级 间 的 数值 并 不 是 连续 的 ， 所 
以 我 们 还 可 以 通过 表 中 最 后 的 ANDROID PRIORITY MORE FAVORABLE (-1) 
来 适当 地 提高 优先 级 ; 或 者 利用 
ANDROID PRIORITY LESS FAVORABLE (+1) 来 降低 优先 级 。 
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由 此 可 见 ，SurfaceFlinger 工 作 线程 所 采用 的 优先 级 相对 较 高 。 这 
样 做 是 必然 的 ， 因 为 屏幕 UI 显示 无 疑 是 人 机 交互 中 与 用 户 体验 关联 最 直 
接 的 ， 任 何 滞后 的 响应 速度 都 将 大 大 降低 产品 的 吸引 力 。 


在 执行 了 run () 以 后 ，Thread 会 自动 调用 threadLoop () 接口 。 即 : 


bool SurfaceFlinger: :threadLoop( ) 
{ 

waitForEvent(); 

return true; 


相当 简洁 的 两 句 话 ， 却 涵盖 了 所 有 SurfaceFlinger 接 下 来 要 执行 的 
工作 。 其 中 waitForEvent () 是 SurfaceFlinger 中 的 成 员 涵 数 ， 它 会 进 一 
步调 用 mEventQueue. waitMessage () : 


void MessageQueue: :waitMessage() { 
do { 
IPCThreadState: :self()->flushCommands(); 
int32_t ret = mLooper->pollOnce(-1); 
switch (ret) { 
case ALOOPER_POLL_WAKE: 
case ALOOPER_POLL_CALLBACK: 
continue; 
case ALOOPER_POLL_ERROR: 
ALOGE("ALOOPER_POLL_ERROR" ) ; 
case ALOOPER_POLL_TIMEOUT: 
// timeout (should not happen) 
continue; 
default: 


// should not happen 
ALOGE("Looper::pollOnce() returned unknown status 
continue; 


} 
} while (true); 


可 以 看 到 程序 在 这 里 进入 了 一 个 死 循 环 ， 而 且 即 便 pol10nce 的 执行 
结果 是 ALOOPER_POLL_TIMEOUT， 也 同样 不 会 跳出 循环 。 这 是 Android 在 
对 竺 严重 错误 时 的 一 种 普 壳 态度 如 果 不 幸 发 生 致命 错误 ， 就 听 天 由 
命 吧 。 


下 面 这 句 代 码 将 在 内 部 调用 MessageQueue: :mHandler 来 处 理 消息 : 
mLooper ->pollOnce(-1); 
9 注意 


pol110nce 函 数 同样 使 用 了 一 个 死 循 环 ， 它 不 断 地 读 取 消息 进行 
处 理 ， 关 系 如 图 ?-29 所 示 。 
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全 图 9-29 SurfaceFlinger 中 的 消息 循环 机 制 


实际 上 SurfaceFlinger 中 的 MessageQueue 类 不 应 该 叫 这 个 名 字 ， 
为 会 和 我 们 传统 的 消息 队列 发 生 混 清和 卜 义 。 变 量 mEventQueue 是 消息 
循环 处 理 机 制 的 管理 者 ， 其 下 包含 了 一 个 Looper 和 一 个 Handler。 
Looper 采 用 的 仍然 是 /frameworks/native/1ibs/uti1s/Looper. cpp FAY 
实现 ，Surface Flinger 没 有 重新 定义 这 个 类 。Looper 中 的 
mMessageEnvelope 才 是 真正 存储 消息 的 地 方 。 


太 “ 绕 ”了 ， 再 好 的 设计 也 应 该 考虑 可 读 性 。 


这 样 就 构建 了 一 个 完整 的 循环 消息 处 理 框架 ，SurfaceF1inger 就 是 
基于 这 个 框架 来 完成 各 个 应 用 程序 的 显示 请 求 的 。 大 家 可 能 会 有 疑问 ， 
mHandler 是 由 MessageQueue 在 init() 中 直接 通过 new Handler (0 生成 
的 ， 这 样 如 何 能 处 理 特定 的 SurfaceF1inger 消 息 请 求 呢 ?个 人 感觉 有 这 
个 困惑 也 是 由 于 Handler 类 取 名 不 当 引 起 的 。 实 际 上 此 Handler 并 非 我 们 
经 党 看 到 的 那个 Handler， 而 是 MessageQueue 中 自 定 义 的 一 个 事件 处 理 


器 ， 即 它 是 专门 为 SurfaceFlinger 设 计 的 : 


/*frameworks/native/services/surfaceflinger/MessageQueue.cpp*/ 
void MessageQueue: :Handler: :handleMessage(const Message& message) 
switch (message.what) { 
case INVALIDATE: 
android_atomic_and(~eventMaskInvalidate, &mEventMask) , 
mQueue.mFlinger ->onMessageReceived(message.what ); 
break; 
case REFRESH: 
android_atomic_and(~eventMaskRefresh, &mEventMask) ; 
mQueue.mFlinger ->onMessageReceived(message.what ); 
break; 
case TRANSACTION: 
android_atomic_and(~eventMaskTransaction, &mEventMask. 
mQueue.mFlinger ->onMessageReceived(message.what ); 
break; 


如 上 述 代 码 段 所 示 ， 当 mHandler 收 到 1NVALIDATE，REFRESH 及 
TRANSACTION 的 请 求 时 ， 将 进一步 回调 SurfaceFlinger 中 的 
onMessageReceived。 等 于 绕 了 一 个 大 圈 ， 又 回 到 SurfaceFlinger 中 
Ta 


到 目前 为 止 ， 我们 还 是 没 看 到 SurfaceF1inger 是 如 何 通 知 
SystemServer 线 程 解 除 等 待 的 。 这 个 工作 是 在 下 面 的 函数 中 完成 的 : 


status_t SurfaceFlinger: :readyToRun( ) 


mReadyToRunBarrier .open();// 好 了 ， 现 在 可 以 解禁 线程 A 了 


冰 数 readyToRun 是 在 一 个 线程 进入 run 循 环 前 被 调用 的 ， 它 为 
SurfaceFlinger 的 正常 工作 提供 了 各 种 必要 的 基础 。 我 们 在 后 续 小 节 还 
会 看 到 其 中 的 更 多 内 容 ， 这 里 暂时 只 分 析 与 消息 处 理 有 关 的 部 分 。 前 面 
所 说 的 mReadyToRunBarr ier 果 然 在 这 里 又 被 调用 了 ，open () 用 来 告诉 所 
有 正在 等 待 的 线程 可 以 继续 执行 下 一 步 操作 了 。Barrier 类 的 内 部 实际 
上 也 是 使 用 了 Condition: :broadcast (), Condition: :wait() 等 常规 互 
斥 方法 ， 只 是 加 了 一 层 封 装 而 已 。 对 同步 与 互 斥 这 些 常用 接口 方法 还 不 
熟悉 的 读者 ， 建 议 回 头 复习 下 本 书 的 进程 章节 。 


9.6.3 接口 的 服务 端 一 一 Client 


SurfaceF1inger 运 行 于 SystemServer 这 一 系统 进程 中 ， 需 要 显示 UI 
界面 的 应 用 程序 则 通过 Binder 服 务 与 它 进 行 跨 进 程 遂 信 。 在 后 续 音 频 系 
统 的 学 习 中 ， 我 们 会 发 现 每 一 个 AudioTrack 在 AudioFlinger 中 都 可 以 找 
到 一 个 对 应 的 Track 实 现 ， 如 图 9-30 所 示 。 这 种 设计 方式 同样 适用 于 显 
示 系 统 ， OE i ree inger 中 有 相对 应 的 
Client 实 例 。 
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全 图 9-30 每 个 应 用 程序 在 SutfaceFlinget 中 都 有 Client 对 象 为 其 提供 服务 


client 这 个 类 名 并 没有 完全 表达 出 它 的 真正 含义 ， 因 为 在 Android 
系统 的 很 多 其 他 地 方 都 可 以 找到 同名 的 类 。 应 用 程序 与 Client 间 的 


Binder 接 口 是 1SurfaceComposerClient， 所 以 作为 接口 的 服务 端 实现 ， 
Client 继 承 自 BnSurfaceComposerCl ient: 


/*frameworks/native/include/gui/ISurfaceComposerClient .h*/ 
class ISurfaceComposerClient : public IInterface 


{ a 
virtual status_t createSurface(const String8& name, uint32_t w, u 
uint32_t flags, sp<IBinder>* handle, sp<IG 


gbp) = 0; 
virtual status_t destroySurface(const sp<IBinder>& handle) = 


}; 


上 述 接口 方法 中 最 重要 的 两 个 是 createSurface() 和 和 
destroySurface () ， 分 别 用 于 向 SurfaceF1linger 申 请 和 销毁 一 个 
Surface (早期 版 本 的 系统 中 createSurface 返 回 的 是 一 个 叫 作 1Surface 
的 Binder 接 口 ， 目 前 已 经 不 复 存 在 。 但 createSurface 这 个 函数 名 称 还 
没有 变 。 我 们 可 以 认为 Surface 在 服务 器 端 对 应 的 是 Layer) 。 


值得 一 提 的 是 ，SurfaceFlinger 的 客户 端 程序 拥有 的 Surface 数 量 
很 可 能 不 止 一 个 。 通 常情 况 下 ， 同 一 个 Activity 中 的 U1 布局 共用 系统 分 
配 的 Surface 进 行 绘 图 ， 但 像 SurfaceView 这 种 U1 组 件 却 是 特例 一 一 它 独 
占 一 个 Surface 进 行 绘制 。 换 句 话 说 ， 如 果 我 们 制作 一 个 带 SurfaceView 
的 视频 播放 器 ， 其 所 在 的 应 用 程序 最 终 就 会 有 不 止 一 个 的 Surface 存 
在 。 这 样 的 设计 是 必需 的 ， 因 为 播放 视频 对 刷新 频率 要 求 很 高 ， 采 用 单 
独 的 Surface 既 可 以 保证 视频 的 流畅 度 ， 同 时 也 可 以 让 用 户 的 交互 动作 
(比如 触摸 事件 ) 得 到 及 时 的 响应 。 


Client 的 继承 关系 如 图 9-31 所 示 。 
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下 面 我 们 从 源码 角度 来 分 析 客 户 端 与 SurfaceF1inger 连 接 并 创建 
Layer 的 两 个 重要 接口 。 


1. SurfaceFlinger::createConnection 


Client FE Binder ARS Th Fe AITEN FY BE Ee FIR ALE 因而 
它 首 先 需 要 借 助 于 SurfaceFlinger 这 一 实名 Binder Server。 源 码 实 现 
如 下 : 


sp<ISurfaceComposerClient> SurfaceFlinger::createConnection() 


{ 
sp<ISurfaceComposerClient> bclient; 
sp<Client> client(new Client(this)); 
status_t err = client->initCheck(); 
if (err == NO_ERROR) { 
bclient = client; 


return bclient; 


首先 生成 一 个 Client 本 地 对 象 ， 然 后 调用 initCheck 进 行 必要 的 有 
效 性 检查 (当前 实现 中 直接 返回 NO_ERROR〉 。 如 果 initCheck 没 有 错 
误 ， 程序 就 会 把 新 生成 的 C1 ient 对 象 以 lsurfaceComposer Client 强 指 
针 的 形式 返回 


这 样 应 用 程序 内 部 就 拥有 一 个 Client 服 务 了 。 


2. Client::createSurface 


Client 只 是 SurfaceFlinger 分 派 给 应 用 程序 的 一 个 “代表 ”， 真 正 
的 图 形 层 (Layer) 创建 需要 另外 申请 ， 即 调用 C1ient 提 供 的 
createSurface 接 口 。 这 个 接口 的 实现 在 前 几 个 小 节 已 经 有 过 粗略 的 分 
析 ， 下 面 再 从 SurfaceFlinger 的 角度 来 审视 下 : 


/*frameworks/native/services/surfaceflinger/Client.cpp*/ 
status_t Client::createSurface(const String8& name, uint32_t w, u 


{ 


class MessageCreateLayer : public MessageBase { 


SurfaceFlinger* flinger;//SurfaceFlinger ks 

Client* client;// 表 明 此 消息 来 源 于 哪个 Client 

sp<IBinder>* handle;// 与 Layer 相 对 应 的 Handle 

sp<IGraphicBufferProducer>* gbp;// 与 Layer 相 对 应 的 gbp 

status_t result; 

const String8& name; 

uint32_t w, h; 

PixelFormat format; 

uint32_t flags; 

public: 

MessageCreateLayer(SurfaceFlinger* flinger, const String8 
uint32_t h, PixelFormat format, uint32 
sp<IBinder>* handle, sp<IGraphicBuffer 

: flinger(flinger), client(client), handle(handle), g 
name(name), w(w), h(h), format(format), flags(flags 

} 

status_t getResult() const { return result; } 

virtual bool handler() {//SurfaceFlinger 将 回调 这 个 handler 来 

result = flinger->createLayer (name, client, w, h, for 
return true; 


}; 


sp<MessageBase> msg = new MessageCreateLayer(mFlinger.get(), 
name, this, w, h, format, flags, handle, gbp);// 生 成 一 

mF linger ->postMessageSync(msg) ;// 将 这 一 Message 推 送 到 SurfaceF1Lin 

return static_cast<MessageCreateLayer*>( msg.get() )->getResu 


值得 注意 的 是 ，createSurface 这 个 函数 需要 从 0penGL ES 的 环境 线 
程 中 被 调用 ， 这 样 它 才能 访问 到 后 者 提供 的 服务 。 


这 个 函数 比较 特别 的 地 方 ， 是 它 先 在 内 部 创建 了 一 个 
MessageCreateLayer 类， 剩余 部 分 代码 就 是 围绕 这 个 类 来 展开 的 。 那 
么 ，MessageCreateLayer 有 什么 作用 呢 ? 从 名 称 上 看 ， 它 应 该 和 
Message 有 关 一 一 其 父 类 是 MessageBase， 定 义 在 MessageQueue. h 中 ， 如 
图 9-32 所 示 。 
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A 图 9-32 MessageCreateLayer 


从 继承 图 中 可 以 大 概 看 出 一 点 端倪 ， 即 MessageCreateLayer 是 一 个 
Message 的 承载 体 ， 并 且 内 部 提供 了 处 理 这 条 Message 的 handler () K 
数 。 这 是 不 是 和 Java 层 的 Handler 很 像 ” 可 能 也 是 这 个 原因 ， 所 以 
其 “ 祖 谱 ”中 有 一 个 类 取 名 为 MessageHandler 。 回 过 头 来 看 
createSurface 中 的 最 后 几 行 ， 程序 将 一 个 MessageCreateLayer 对 象 msg 
发 送 到 了 SurfaceFlinger 中 : 


mFlinger->postMessageSync(msg); 
为 什么 要 这 么 做 呢 ? 


大 家 还 记 不 记得 在 进程 章节 讲述 Message，Looper，Handler 的 关系 
时 曾经 打 过 一 个 比方 ， 为 了 方便 阅读 我 们 再 把 它 列 出 来 : 


打 个 比方 ， 某 天 你 和 朋友 去 健身 房 运 动 ， 正 当 你 在 跑步 机 上 气喘 吁 
旁边 有 个 朋友 跟 你 说 : “哥们 儿 ， 最 近 手 头 紧 ， 借 点 钱 花 
”这 时 候 你 就 有 两 个 选择 。 


e 立即 执行 


这 就 意味 着 你 要 从 跑步 机 上 下 来 ， 问 清 借 多 少 钱 ， 然 后 马上 打开 电 
脑 进行 转账 。 


。 稍 后 执行 


上 面 的 方法 在 某 些 场合 下 是 有 用 的 ， 不 过 大 部 分 情况 下 “ 借 钱 ”这 
种 事 并 不 是 刻不容缓 的 ， 因 而 你 可 以 跟 朋 友 说 : “ 借 钱 没 问题 ， 你 先 和 
我 秘书 约 时 间 ， 改 天 我 们 具体 谈 细 节 。” 那 么 在 这 种 情况 下 ， 这 个 “ 借 
钱 事件 ”就 通过 秘书 这 个 MessageQueue 进 入 了 排队 ， 所 以 你 并 不 需要 从 
跑步 机 上 下 来 ， 中 断 健身 运动 。 后 期 秘书 会 一 件 件 通知 你 MessageQueue 
上 的 待 办 事宜 (当然 你 也 可 以 主动 问 秘 书 ) ， 直 到 “ 借 钱 事件 ” 时 你 才 
需要 和 这 位 朋友 进一步 商谈 。 在 一 些 场合 下 这 样 的 处 理 方式 是 合 情 合 
的 。 比 如 健身 房 一 小 时 花费 是 10 万 元 ， 而 朋友 只 借 100 元 ， 那么 即刻 处 


理 这 一 事件 就 不 合理 了 。 


这 个 “ 借 钱 ”的 例子 在 createSurface () 这 个 场景 中 也 是 同样 适用 
的 ， 如 图 9-33 所 示 。 


SurfaceFlinger 所 在 工作 线程 


postMessageSync 





全 图 9-33 createSurface 中 的 消息 投递 与 执行 


水 数 postMessageSync 是 SurfaceFlinger 提 供 的 一 个 接口 ， 它 通过 
mEventQueue 将 Msg 压 入 其 消息 队列 中 ， 并 且 会 进入 等 待 状态 。 如 下 : 


status_t SurfaceFlinger::postMessageSync(const sp<MessageBase>& m 
status_t res = mEventQueue.postMessage(msg, reltime); 
if (res == NO_ERROR) { 


msg->wait(); 


} 


return res; 


MessageBase: :wait () 调用 内 部 的 Barrier: :wait 来 实现 等 待 ， 这 意 
味 着 发 送 消息 的 线程 将 暂时 停止 执行 ， 那 么 什么 时 候 才能 继续 呢 ? 显然 
得 有 人 唤醒 它 才 行 。 这 个 唤醒 的 地 方 隐 藏 在 
MessageBase: :handleMessage () 中 。 即 : 


/*frameworks/native/services/surfaceflinger/MessageQueue.cpp*/ 
void MessageBase: :handleMessage(const Message&) { 
this->handler(); 
barrier.open(); 


}; 


简单 来 讲 ， 就 是 Client 一 旦 收 到 来 自 客 户 端 的 请 求 ， 并 不 会 马上 让 
SurfaceFlinger 执 行 ， 而 是 间接 地 把 请 求 先 投递 到 后 者 的 消息 队列 中 
这 样 一 方面 保证 这 个 请 求 不 会 丢失 ， 另 一 方面 也 使 SurfaceF|inger 
不 至 于 中 断 当 前 的 操作 。 


在 createSurface 的 执行 过 程 中 ， 显 然 Client 所 在 线程 〈 即 Binder 
线程 ) 将 进入 wait 状 态 ， 直 到 SurfaceFlinger 成 功 完 成 业务 后 ， 它 才 被 
唤醒 ， 然 后 返回 最 终结 果 给 客户 端 一 一 这 一 工作 方式 和 
postMessageSync 所 要 实现 的 “同步 ”是 一 致 的 。 


这 其 中 的 流程 有 点 乱 ， 我 们 以 图 9-34 来 做 下 整理 。 
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全 图 0-34 Client:i:createSurface 流 程 图 


另外 ，SurfaceFlinger 中 还 有 一 个 类 似 的 消息 推送 函数 
postMessageAsync， 从 名 称 上 就 可 以 看 出 它 是 用 来 异步 执行 业务 的 。 通 
俗 地 讲 就 是 推送 消息 过 后 函数 就 直接 返回 了 ， 而 无 须 等 待 执行 结果 。 读 
者 可 以 自行 分 析 下 这 个 函数 的 源码 。 

绕 了 一 圈 ， 终 于 轮 到 SurfaceFlinger 工 作 线程 来 处 理 


createSurface() 了 。 这 个 函数 我 们 在 前 面 讲 解 “ 应 用 程序 与 
BufferQueue 的 关系 ”时 已 经 详细 分 析 过 ， 这 里 不 再 痊 述 。 


9.7 VSync 的 产生 和 处 理 
大 家 在 Pro ject Butter 小 节 中 学 习 了 从 Android 4. 1 开始 引入 的 显 
示 系 统 新 特性 这 个 工程 的 一 个 重要 核心 就 是 加 入 了 VSync 同 步 。 我 
们 从 理论 的 角度 分 析 了 采用 这 一 机 制 的 必要 性 和 运作 机 理 ， 那 么 
SurfaceF1inger 具 体 是 如 何 实施 的 呢 ? 
先 来 思考 一 下 SurfaceFlinger 实 现 VSync 同 步 有 哪些 要 点 。 
e VSync 信 号 的 产生 和 和 分 发 


ee a 那 是 最 好 的 ; 否则 就 得 通过 软件 模 
以 产生 。 


。VSync 信 号 的 处 理 


当 信 号 产生 后 ，SurfaceFlinger 如 何在 最 短 的 时 间 内 做 出 响应 。 另 
外 ， 具 体 的 处 理 流程 是 怎样 的 。 








9.7.1 VSync 信 号 的 产生 和 分 发 


Android 源 码 工 程 的 surfaceflinger 目 录 下 有 一 个 displayhardware 
文件 夹 ， 其 中 HWComposer 的 主要 职责 之 一 ， 就 是 用 于 产生 VSync 信 号 : 


/*frameworks/native/services/surfaceflinger/displayhardware/HWCom 
HwComposer: :HWComposer(const sp<SurfaceFlinger>& flinger, EventHa 
: mFlinger(flinger), mFbDev(0), mHwc(0), mNumDisplays(1), m 
mEventHandler (handler), mVSyncCount(0), mDebugForceFakeVSyn 


char value[PROPERTY_VALUE_MAX]; 
property_get("debug.sf.no_hw_vsync", value, "0");// 获 取 系 统 属性 
mDebugForceFakeVSync = atoi(value); 

bool needVSyncThread = true;// 是 否 需 要 软件 模拟 产生 VSync 信 和 号， 默认 和 





loadHwcModule( ) ;// 打 开 HWC 的 HAL 模 块 


if (mHwc) {... 
if (mHwc->registerProcs) {// 注 册 硬 件 回 调 事件 
mCBContext->hwc = this; 
mCBContext->procs.invalidate = &hook_invalidate; 


mCBContext->procs.vsync = &hook_vsync; 
if (hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_ 1 
mCBContext->procs.hotplug = &hook_hotplug; 
else 
mCBContext->procs.hotplug = NULL; 
memset (mCBContext->procs.zero, ©, sizeof(mCBContext-> 
mHwc ->registerProcs(mHwc, &mCBContext->procs); 


J 


// don't need a vsync thread if we have a hardware compos 
needVSyncThread = false;// 不 需要 软件 模拟 





} 


if (needVsyncThread) {/// 如 果 需 要 软件 模拟 VSync 信 号 的 话 ， 启 动 一 个 VSy 
// we don't have VSYNC support, we need to fake it 
mVSyncThread = new VSyncThread(*this); 





} 
} 

这 个 函数 的 核心 就 是 决定 VSync 的 “信号 发 生源 ”一 一 硬件 实现 或 
者 软件 模拟 。 


假如 当前 系统 可 以 成 功 地 加 载 名 称 为 


HWC_HARDWARE_MODULE_1D=“hwcomposer” 的 HAL 模 块 ， 并 且 通 过 这 个 库 
模块 能 顺利 打开 设备 〈hwc_composer_device t) ， 其 版 本 号 又 大 于 
HWC_DEVICE_AP1_VERSION_1_1， 我 们 就 采用 “硬件 源 ” (此 时 
needVSyncThread 为 false) ; 否则 需要 创建 一 个 新 的 VSync 线 程 来 模拟 
产生 信号 。 


1. 硬件 源 


如 果 mHwc->registerProcs 不 为 空 ， 我 们 注册 硬件 回调 


mCBContext. procs。 定 义 如 下 : 


struct HWComposer::cb_context { 


}; 


struct callbacks : public hwc_procs_t { 
void (*zero[4])(void); 


callbacks procs; 
HwWComposer* hwc; 


调用 regi sterProcs () 时 ， 传 入 的 参数 是 &mCBContext. procs. AHA 
当 有 事件 产生 时 ， 如 vsync 或 者 inval idate， 硬 件 模块 将 分 别 通过 
procs. vsync 和 procs. inval idate 来 通知 HWComposer : 


void HWComposer: :hook_vsync(struct hwc_procs* procs, int dpy, int 
reinterpret_cast<cb_context *>(procs)->hwc->vsync(dpy, timest 
} 


上 面 这 个 函数 中 procs 即 前 面 的 &mCBContext. procs， 从 指针 地 址 的 
角度 看 它 和 &mCBContext 是 一 致 的 (procs 是 cb_context 的 第 一 个 元 
素 ) ， 因 而 我 们 可 以 把 它 的 强制 类 型 转换 为 cb_context 来 操作 ， 并 由 此 
访问 到 hwc 中 的 vsync 实 现 : 


void HWComposer::vsync(int dpy, int64_t timestamp) { 
mEventHandler.onVSyncReceived(dpy, timestamp); 


HWComposer 将 VSync 信 号 直接 传递 给 mEventHandler， 这 个 Handler 
是 由 HWComposer 在 构造 时 传 入 的 。 换 句 话说 ， 我 们 需要 看 看 是 谁 创建 了 


HWComposer : 


/*frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp*/ 
status_t SurfaceFlinger: :readyToRun( ) 


£ 


mHwc = new HWComposer (this, *static_cast<HwComposer: :EventHand 


从 中 可 以 看 出 ，HWComposer 中 的 mEventHandler 就 是 
SurfaceFlinger 对 象 ， 所 以 后 者 必须 要 继承 自 
HWComposer : :EventHandler， 这 样 才 能 处 理 cal Ibackek 
onVSyncRecei ved: 


class SurfaceFlinger : public BinderService<SurfaceFlinger>,... 
private HwWComposer: :EventHandler 


早期 版 本 的 实现 中 ， 还 有 另外 一 个 类 DisplayHardware 来 间接 处 理 
EventHandler， 有 再 通过 一 系列 的 传递 才能 到 达 SurfaceF1inger 本 身 的 处 
理 。 可 以 说 Android 4. 3 中 对 j 这 些 中 间 宛 余 过 程 进行 了 精简 ， 很 值得 称 


道 。 


2. 软件 源 


软件 源 和 硬件 源 相 比 最 大 区 别 是 它 需 要 局 动 一 个 新 线程 
VSyncThread， 其 运行 优先 级 与 SurfaceFlinger 的 工作 线程 是 一 样 的 ， 
都 是 -q。 从 理论 的 角度 来 讲 ， 任 何 通 过 软件 定时 来 实现 的 机 制 都 不 可 能 
是 100% 可 靠 的 ， 即 使 优先 级 再 高 也 可 能 出 现 延 迟 和 意外 。 不 过 如 果 “ 不 
可 靠 ” 的 概率 很 小 ， 而 且 就 算出 现 意外 时 也 不 至 于 是 致命 错误 ， 那 么 还 
所 以 说 VSyncThread 从 实践 的 角度 来 讲 ， 的 确 起 到 了 很 
了 的 作用 。 


来 看 看 VSyncThread 都 做 了 些 什 么 工作 : 


bool HWwComposer::VSyncThread::threadLoop() { 
/*Step1. 判断 系统 是 否 使 能 了 VSync 信 号 发 生机 制 */ 
{ // 自动 锁 控 制 范围 
Mutex::Autolock _1(mLock); 
while (!mEnabled) {//VSync 信 号 开关 
mCondition.wait(mLock); 
} 


} 
/*Step2. 计算 需要 产生 VSync 信 号 的 时 间 点 */ 
const nsecs_t period = mRefreshPeriod;// 信 号 的 产生 间隔 
const nsecs_t now = systemTime(CLOCK_MONOTONIC) ; 
nsecs_t next_vsync = mNextFakeVSync;// 产 生 信号 的 时 间 
nsecs_t sleep = next_vsync - now; // 需 要 休眠 的 时 长 
if (sleep < 0) {// 已 经 过 了 时 间 点 
sleep = (period - ((now - next_vsync) % period)); 
next_vsync = now + sleep; 





这 




















mNextFakeVSync = next_vsync + period; // 下 一 次 的 VSync 时 间 
struct timespec spec; 

spec.tv_sec = next_vsync / 1000000000; 

spec.tv_nsec = next_vsync % 1000000000; 


int err; 
do { 

err = clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &sp 
} while (err<0 && errno == EINTR); 


if (err == 0) { 
mHwc .mEventHandler.onVSyncReceived(0, next_vsync) ;// 和 硬件 
} 


return true; 


Step1@VSyncThread: :threadLoop。 关 于 自动 锁 的 使 用 我 们 已 经 分 


析 过 很 多 次 ， 此 处 不 再 玲 述 。 这 里 要 注意 的 是 mEnabled 这 个 变量 ， 它 是 
用 于 控制 是 否 产 生 VSync 信 号 的 一 个 使 能 变量 。 当 系统 希望 关闭 VSync 信 
号 发 生源 时 ， 可 以 调用 VSyncThread: :setEnabled (false); 否则 调用 
setEnabled (true)。 假 如 mEnabled 为 false，VSyncThread 就 处 于 等 待 
状态 ， 直 到 有 人 再 次 使 能 这 个 线程 。 


Step2@VSyncThread: :threadLoop。 接 下 来 的 代码 用 于 真正 产生 一 
个 VSync 信 号 。 可 以 思考 一 下 ， 无 非 就 是 以 下 步 又 : 


。 计算 下 一 次 产生 VSync 信 号 的 时 间 ; 

。 进 入 休眠 ; 

。 休眠 时 间 到 了 后 ， 发 出 VSync 信 和 号， 通知 感 兴趣 的 人 ; 
。 循环 往复 。 


变量 mRefreshPer iod 指 定 了 产生 VSync 依 号 的 间隔 。 它 的 计算 过 程 
分 为 几 种 情况 : 首选 是 从 硬件 设备 获得 真实 的 值 ; 否则 就 采用 如 下 办 
法 : 


if (disp.refresh == 0) { 
disp.refresh = nsecs_t(1e9 / mFbDev->fps); 


Í 
if (disp.refresh == 0) { 

disp.refresh = nsecs_t(1e9 / 60.0); 
} 


也 就 是 说 第 二 优先 级 的 取 值 是 由 nsecs t(1e9 / mFbDev->fps) 计算 
得 到 的 一 一 如 果 还 不 行 ， 那 就 只 能 采用 默认 值 了 。 即 : 


nsecs_t(1e9 / mRefreshRate); 
在 这 种 情况 下 ，mRefreshPer iod 差 不 多 是 16ms 。 


因为 nNextFakeVSync 代 表 的 是 “下 一 次 ”产生 信号 的 时 间 点 ， 所 以 
首先 通过 next vsync= mNextFakeVSync 来 确定 next_vsync 的 值 。 接 着 计 
算 sleep， 也 就 是 距离 产生 信号 的 时 间 点 还 有 多 长 〈 同 时 也 是 需要 休 眼 
的 时 间 ) 。 那 么 ， 如 果 sleep 的 结果 小 于 0 呢 ? 代表 我 们 已 经 错过 了 这 一 
次 产生 信和 号 的 最 佳 时 间 点 〈 这 是 有 可 能 发 生 的 ) 。 在 这 种 情况 下 ， 就 只 
能 计算 下 一 个 最 近 的 VSync 离 现在 还 剩 多 少时 间 。 公 式 如 下 : 


sleep = (period - ((now - next_vsync) % period)); 


我 们 以 图 9-35 来 表述 以 下 采用 这 个 公式 的 依据 。 


next vyne 





全 图 9-35 休眠 时 间 推 算 简 图 


图 9-35 的 前 提 是 now 超 时 时 间 不 能 超过 一 个 per iod 一 一 因而 sleep 公 
式 中 还 要 加 上 %per iod。 


计算 完成 sleep 后 ，mNextFakeVSync=next_vsync + period。 这 是 
因为 nNextFakeVSync 代 表 的 是 下 一 次 threadLoop 需 要 用 到 的 时 间 点 ， 而 


next_vsync 是 指 下 一 次 (最 近 一 次 ) 产生 VSync 的 时 间 点 。 
这 样 我 们 就 计算 出 来 下 一 次 产生 信号 的 时 间 点 了 ， 那么 如 何在 指定 
的 时 间 点 产生 信号 呢 ? 有 两 种 方法 : 其 一 是 采用 定时 器 回调 ; 其 二 就 是 


采用 休眠 的 形式 主动 等 待 一 一 HWComposer 使 用 的 是 后 者 。 


可 想 而 知 这 里 对 时 间 精 度 的 要 求 比较 高 ， 所 以 采用 的 单位 是 
nanosecond， 即 纳 秒 级 。 函 数 clock_nanosleep 的 第 一 个 入 参 是 
CLOCK_MONOTON1C6， 这 种 类 型 的 时 钟 更 加 稳定 ， 且 不 受 系统 时 间 的 影 
Aa] o 


休眠 时 间 一 到 ， 表 示 产 生 信号 的 时 刻 到 了 。 根 据 前 面 的 分 析 ， 就 是 
通过 mEventHand1ler. onVSyncReceived 0 回调 来 通知 对 消息 感 兴趣 的 人 
一 一 无 论 软 件 还 是 硬件 发 生源 ， 其 回调 方式 都 是 一 样 的 。 


当 产 生 完 一 次 信号 后 ，VSyncThread: :threadLoop 这 个 函数 就 直接 
返回 true 了 。 有 些 读 者 可 能 会 觉得 奇怪 ， 怎 么 没有 看 到 循环 的 地 方 ? 这 
是 因为 当 threadLoop 返 回 值 为 “ 真 ”时 ， 它 将 被 系统 再 一 次 调用 ， 如 此 
循环 往复 。 不 清楚 的 读者 可 以 参阅 一 下 Thread 类 的 实现 。 


接 下 来 我 们 分 析 下 SurfaceF 1inger 是 如 何 处 理 这 个 VSync 信 号 的 。 


中 间 过 程 很 简单 ， 就 不 一 一 解释 了 。 在 
SurfaceF | inger: :onVSyncReceived#: 


void SurfaceFlinger: :onVSyncReceived(int type, nsecs_t timestamp) 


if (uint32_t(type) < DisplayDevice: :NUM_DISPLAY_TYPES) { 
// we should only receive DisplayDevice::DisplayType from 
mEventThread->onVSyncReceived(type, timestamp) ;//EventThr 


又 出 现 了 一 个 新 类 ， 即 EventThread。SurfaceFlinger 直 接 调 用 了 
它 的 onVSyncReceived 实 现 。 从 名 称 上 可 以 猜测 到 ，EventThread 是 
SurfaceFi lnger 中 专门 用 于 处 理事 件 的 线程 。 这 个 线程 对 象 是 在 
SurfaceFlinger::readyToRun 生 成 的 : 


status_t SurfaceFlinger: :readyToRun( ) 


ee 
mEventThread = new EventThread(this); 
mEventQueue.setEventThread(mEventThread) ; 
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` 于 站 
9 Em 


EventQueue 与 EventThread 进 行 了 绑 定 ， 后 续 我 们 还 会 再 分 析 
它们 之 间 的 关系 。 


EventThread 的 启动 并 不 是 由 SurfaceFlinger 决 定 的 ， 而 是 取决 于 
引用 它 的 人 一 一 因为 EventThread 继 承 自 Thread， 后 者 又 是 RefBase 的 子 
类 ， 所 以 当 第 一 次 有 人 用 智能 指针 引用 它 时 ， 会 自动 调用 onF irstRef & 
数 ， 继 而 把 这 个 线程 run 起 来 〈 线 程 优先 级 为 PRIORITY_URGENT_D1SPLAY 
+ PRIORITY MORE FAVORABLE) 。 


了 解 了 EventThread 的 启动 过 程 后 ， 再 来 看 看 它 是 如 何 处 理 消息 
的 : 


/*frameworks/native/services/surfaceflinger/EventThread.cpp*/ 
void EventThread: :onVSyncReceived(int type, nsecs_t timestamp) {... 
Mutex: :Autolock _1(mLock); 
if (type < HWC_NUM_DISPLAY_TYPES) {// 显 示 类 型 目前 有 两 种 
mVSyncEvent[type].header.type = DisplayEventReceiver::DIS 
mVSyncEvent[type].header.id = type; 
mVSyncEvent[type].header.timestamp = timestamp; 
mVSyncEvent[type].vsync.count++; 
mCondition.broadcast();// 条 件 满足 ， 唤 醒 谁 





~ 





} 
} 
Android4. 3 版 本 中 ，HWC_NUM_D1SPLAY_TYPES 的 定义 如 下 : 
enum { 
HWC_DISPLAY_PRIMARY = 0, 
HWC_DISPLAY_EXTERNAL = 1, // HDMI, DP, etc. 
HwWC_NUM_DISPLAY_TYPES 
}; 


可 以 看 到 ，Android 系 统 除 了 主 显示 屏 外 ， 还 支持 HDMI 的 显示 (或 
者 称 为 外 部 显示 屏 ) 。 所 以 VSync 的 产生 者 类 型 值 只 会 小 于 
HWC_NUM_D I SPLAY_TYPES. 


确定 了 Display TypeA, AROR RAKE KIRK 
mVSyncEvent [type] 数组 中 的 DisplayEventReceiver : :Event 对 象 ， 包 括 
Event 类 型 、 时 间 惟 、 信 号 计数 等 。 而 最 重要 的 是 ， 程 序 在 函数 末尾 通 
过 mCondition. broadcast () 来 通知 等 待 Event 的 人 一 一 会 是 谁 呢 ? 


没 错 ， 是 EventThread 所 在 的 线程 。 可 能 SHISTE, 
onvsynoReceived 不 就 是 属于 EventThread 吗 ， 怎 怎么 么 还 能 处 于 等 待 中 ? 发 
出 这 种 疑问 可 能 是 被 线程 的 概念 “ 困 ” 住 了 。 由 上 面 的 分 析 可 以 看 出 ， 
EventThread: :onVSyncReceived a ae 
的 ， 所 以 它 的 执行 也 是 由 SurfaceFlinger 所 在 线程 完成 的 一 一 个 过 
onVSyncReceived 并 没有 对 信和 号 做 具体 的 处 理 。 打 个 比方 ， 
SurfaceF1inger 线 程 只 是 到 了 EventThread 家 的 厨房 

(onVSyncReceived) 里 ， 然 后 把 “食材 ”通过 
DisplayEventReceiver: :Event 准 备 好 ， 放 在 mVSyncEvent 中 ， 然 后 唤醒 


正在 屋 里 睡 大 觉 的 “EventThread” 一 一 嘿 ， 哥 们 儿 ， 东 西 都 准备 好 
了 ， 开 动 吧 ! 于 是 接 下 来 的 处 理工 作 就 正式 移交 到 EventThread 线 程 
Ta 


这 点 我 们 从 下 面 这 个 代码 段 中 也 能 得 到 验证 : 


bool EventThread::threadLoop() { 
DisplayEventReceiver::Event event; 
Vector< sp<EventThread: :Connection>> signalConnections; 


signalConnections = waitForEvent(&event );//EventThread mt 61x! 


const size_t count = signalConnections.size(); 


for (size_t i=0 ; i<count ; i++) {// 开 始 dispatch 消 息 给 所 有 感 兴趣 | 


const sp<Connection>& conn(signalConnections[i]); 


status_t err = conn->postEvent(event ) ;//iiiConnection“ iit 


} 
return true;// 如 我 们 前 面 所 述 ， 返 回 true 后 系统 将 再 次 调用 threadLoop 


首先 还 得 强调 下 ， 当 threadLoop 返 回 true 时 ， 系 统 将 会 再 次 调用 


它 ， 从 而 形成 一 个 循环 。 在 一 个 单 次 循环 中 ， 它 会 利用 waitForEvent 来 
等待 一 个 事件 的 发 生 ， 如 VSync。 我 们 前 面 所 说 的 EventThread 在 “ 睡 大 
膏 ”， 就 是 由 此 引起 的 。 而 一 旦 mCondition. broadcast () 后 ， 它 就 会 得 


到 唤醒 。 


接着 EventThread 会 统计 所 有 对 Event 感 兴趣 的 人 ， 即 记录 在 
signalConnections 中 的 元 素 。 然 后 它 通 过 与 这 些 元 素 间 的 纽带 
(Connection) 来 一 一 通知 它们 有 事件 发 生 了 。 变 量 
signalConnections 是 在 waitForEvent 中 准备 的 ， 根 据 Event 的 实际 情 
从 EventThread 的 全 局 变量 mDisplayEvent Connections 中 挑选 出 来 的 。 


换 句 话说 ， 所 有 对 Event 感 兴趣 的 人 都 需要 被 记录 到 
mDisplayEventConnections 中 。 具 体 而 言 ， 有 两 种 类 型 的 “忠实 听 
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e SurfaceFlinger 


毋庸 置疑 ，SurfaceF1inger 一 定 会 收听 VSync 信 和 号 的 产生 。 这 一 工 
作 由 它 内 部 的 EventQueue， 即 “事件 队列 管家 ”来 完成 。 当 
SurfaceFlinger::readyToRun 中 生成 EventThread 对 象 后 ， 会 马上 调用 


MessageQueue: :setEventThread 来 把 它 设 置 到 内 部 的 mEventThread 变 量 
中 ; 同时 ，MessageQueue 还 会 通过 接口 
EventThread: :createEventConnection 来 创建 一 个 Connect ion 连 接 。 


。 需要 刷新 UI 的 各 进程 


SurfaceFlinger 只 是 负责 最 后 的 U1 数据 合成 ， 而 各 应 用 程序 才 是 
正 的 数据 生产 者 ， 所 以 它们 也 必定 是 要 监听 VSync 信 和 号 的 。 
SurfaceFlinger 提 供 了 createDisplayEventConnection 接 口 来 满足 各 应 
用 程序 的 需求 ， 这 个 接口 同样 调用 了 


EventThread: :createEventConnection 来 创建 一 个 Connection 连 接 。 


真 


~ 


那么 ， 什 么 情况 下 这 些 创 建 的 Connect ion 会 添加 到 EventThread 的 
mDisplayEventConnections 中 呢 ? 


没 错 ， 是 当 这 些 Connect ion 被 第 一 次 引用 的 时 候 ， 它 会 自动 调用 
registerDisplayEventConnection 来 注册 到 EventThread 中 。 


我 们 以 图 9-36 来 总 结 本 小 节 的 内 容 。 







HW Composer: FventHandler 
|onVSyncRecetved () 
A 


BRO. a 四 





A SYNC 





AW Composer* mHwe 
-p< Event Lhread >mvent l hread 


HWComposer 
jp VSyneThread > mV SyncThread; 
| -hwe composer device t* mHlwes 
-Eventllandler& — mEvent{landler; 










VSyne! head 





全 图 9-36 VSync 信 号 的 产生 与 分 发 


整体 逻辑 关系 相对 复杂 ， 建 议 大 家 在 做 源码 分 析 时 紧 紧 抓 住 下 面 两 





e VSync 信 号 的 传递 流向 。 
。 各 个 类 的 静态 依赖 关系 ， 如 SurfaceFlinger 5 EventThread, 
EventThread 与 Connection 等 类 之 间 的 联系 。 


9.7.2 VSync 信 号 的 处 理 


经 过 上 一 小 节 的 分 析 ， 现 在 我 们 已 经 明白 了 系统 是 如 何 通 过 硬件 设 
备 或 者 软件 模拟 来 产生 VSync 信 号 了 ， 也 明白 了 它 的 流转 过 程 。VSync 最 
终 会 被 EventThread: :threadLoop () 分 发 给 各 监听 者 ， 如 
SurfaceFlinger 进 程 中 就 是 MessageQueue。 


MessageQueue 通 过 与 EventThread 建 立 一 个 Connect ion 来 监听 事 
件 ， 如 图 9-37 所 示 。 






Fyent Thread M assage ueue 


Sorted Vector<wp< Connection > >mDisplayEventConnections; 








-sp< FventThread>mFventThread; 
+threadLoop () -sp< [DisplayEventČonnection>mEvents; 
terealeEventConmection (} 
+revisterDisplayEventConnection () 
+UnregisterLisplayEventConnection () 





EventThread::Connection 


-sp<EventThread>mEventThread; 
-3p <BifTube> const mChannel; 


+virtual void onF irstRet (} 
+p<BitTube> gelDalaChannel () 


全 图 9-37 “Connection 是 EventIhtead 与 对 事件 感 兴 趣 的 对 象 的 连接 


对 VSYNC 等 事件 感 兴趣 的 对 象 ( 如 MessageQueue) ， 首 先 要 通过 调 
用 接口 EventThread:: createEventConnection() 来 建立 一 个 连接 (应 
用 进程 是 间接 由 SurfaceF1inger 完 成 的 ) ， 实 际 上 就 是 生成 了 一 个 
EventThread: :Connection 对 象 。 这 个 对 象 将 对 双方 产生 如 下 影响 。 


e ~4Connection::onFirstRef() 时 ， 即 “连接 ”第 一 次 被 引用 时 ， 它 会 主 
动 调用 EventThread:: fepgistetDisplayEventConnection0 来 把 自己 添加 到 
EventThread fy mDisplayEvent Connections 中 ， 这 是 保证 事件 发 生 后 
EventThread 能 找到 符合 要 求 的 “连接 ”的 关键 一 步 。 

e X MessageQueue 得 到 Connection 后 ， 它 会 马上 调用 getDataChannel 来 
获得 一 个 BitfTube。 从 届 辑 关系 上 看 ，Connection 只 是 双方 业务 上 的 
连接 ， 而 BitTube 则 是 数据 传输 通道 ， 各 种 Event 信 息 就 是 通过 这 里 
传输 的 。 


下 面 以 MessageQueue 为 例 来 分 析 各 个 进程 是 如 何 与 MessageThread 
进行 交互 的 : 


void MessageQueue: :setEventThread(const sp<EventThread>& eventThr 


{ 











mEventThread = eventThread; 
mEvents = eventThread->createEventConnection(); // 建 立 一 个 Connk 
mEventTube = mEvents->getDataChannel( ) ;//.7BU3k#XBitTube 
mLooper ->addFd(mEventTube->getFd(),0, 

ALOOPER_EVENT_INPUT, MessageQueue: :cb_eventRec 





从 扮演 的 角色 来 看 ，EventThread 是 Server， 不 断 地 往 Tube 中 写 入 
数据 ; 而 MessageQueue 是 Client， 负 责 读 取 数据 。 可 能 会 很 好 奇 ， 
MessageQueue 如 何 得 知 有 Event 到 来 ， 然 后 去 读 取 它 呢 ? 答案 就 是 它们 
之 间 的 数据 读 写 模 式 采 用 的 是 Socket (CAF_UNIX 域 ) 。 

上 面 这 个 函数 的 末尾 通过 Looper 添 加 了 一 个 fd， 这 实际 上 就 是 
Socket Pair 中 的 一 端 。 然 后 Looper 将 这 个 fd 与 其 cal lback 函 数 〈 即 
MessageQueue: :cb_eventReceiver) 加 入 全 局 的 mRequests 进 行 管理 : 


KeyedVector<int, Request> mRequests; 


这 个 Vector 会 集中 所 有 需要 监测 的 fd。 这 样 当 Looper 进 行 
polllnner 时 ， 只 要 有 事件 需要 处 理 ， 它 就 可 以 通过 cal lback 函 数 通 
知 “ 接 收 者 ”。 这 里 面 的 实现 细节 主要 包括 BitTube. cpp 和 Looper. cpp 
两 个 源 文 件 ， 有 兴趣 的 读者 可 以 自行 研究 。 


当 Event 发 生 后 ，MessageQueue: : cb_eventReceiver 开 始 执 行 ， 进 
而 调用 eventReceiver 。 如 果 event 的 类 型 是 
DisplayEventReceiver: :DISPLAY_EVENT_VSYNC， 则 正 是 我 们 想 要 监听 
的 事件 。 这 时 会 有 两 种 情况 : 


if (buffer[i].header.type == DisplayEventReceiver: :DISPLAY_EVENT_ 


#if INVALIDATE_ON_VSYNC 

mHandler ->dispatchInvalidate()j; 
#else 

mHandler ->dispatchRefresh(); 
#endif 


宏 INVALIDATE_0ON_VSYNC 默 认 情 况 下 被 def ine 为 1， 什 么 意思 呢 ? 


我 们 知道 在 把 UI 刷 新 到 屏幕 上 (refresh) 之 前 ， 各 U1 进程 需要 先 
准备 好 数据 (invalidate) 。 那 么 SurfaceF1inger 是 在 VSYNC 来 临时 再 
做 数据 的 准备 工作 ， 然 后 立即 刷新 到 屏幕 上 ; 还 是 平常 就 开始 准备 ， 而 
当 VSYNC 来 临时 把 数据 刷新 到 屏幕 上 呢 ? 


INVAL1DATE_ON_VSYNC 为 1 时 ， 程 序 执行 前 面 的 操作 ; 否则 就 是 第 
二 种 情况 。 


函数 dispatchlnvalidate 和 dispatchRefresh 在 SurfaceFlinger 中 
的 处 理 过 程 是 有 一 定 差异 的 ， 对 比如 表 9-7 所 示 。 


因为 signalRefresh 最 终 的 处 理 和 handleMessageRefresh 一 样 ， 可 
见 INVALIDATE 的 情况 下 多 执行 了 两 个 洱 数 hand1eMessageTransaction 和 和 
handleMessagelnval idate 一 一 它们 分 别 用 于 处 理 “ 业 务 ” (也 就 是 客 
户 端 发 起 的 对 Layer 属 性 的 变更 业务 ， 后 续 小 节 有 讲解 ) 和 数据 


Inval idate- 


529-7 INVALIDATE_ON_VSYNC 的 差异 对 比 


| dispatchInvalidate | dispatchRefresh | 


case 


MessageQueue::INVALIDATE: 
case 


handleMessageTransaction(); MessageQueue::REFRESH: 


handleMessageRefresh(); 


handleMessagelnvalidate(); 
signalRefresh(); 





先 来 看 看 handleMessageRefresh 所 要 做 的 工作 〈 这 也 是 我 们 后 续 几 
个 小 节 的 前 述 重点 ) : 


void SurfaceFlinger: :handleMessageRefresh() { 
ATRACE_CALL(); 
preComposition( );// 合 成 前 的 准备 
rebuildLayerStacks();//##t€ WLayer HER 
setUpHwWComposer(); //HWComposer 的 设 定 
doDebugFlashRegions(); 
docomposition();// 正 式 的 合成 工作 
postcomposition( );// 合 成 后 期 工作 








虽然 Jelly Bean 的 几 个 版 本 (4. 1~4. 3) 中 ， 对 于 SurfaceFl|inger 
泻 染 U1 的 处 理 过 程 改动 很 大 ， 但 不 可 否认 的 是 ， 目前 4. 3 系统 已 经 达到 
了 比较 好 的 状态 一 一 不 论 是 从 代码 风格 还 是 逻辑 关系 上 ， 相 比 前 两 个 版 
本 都 有 很 大 程度 的 提高 。 


整个 UI 合 成 过 程 包 括 了 如 下 几 个 函数 : 


e preComposition ; 

e rebuildLayerStacks ; 

e setUpHWComposer ; 
e doDebugFlashRegions ; 
e doComposition ; 


e postComposition 。 


上 述 这 些 函 数 再 加 上 handleMessageTransaction、 


handleMessagelnvalidate， 基 本 涵盖 了 SurfaceFlinger 的 所 有 功能 。 
接 下 来 的 几 个 小 节 我 们 将 详细 分 析 它 们 。 


9.7.3 handleMessageTransaction 


水 数 hand1eMessageTransaction 在 做 了 简单 的 判断 后 ， 直 接 调 用 了 
handleTransaction。 接 着 handleTransaction 首 先 获取 mStateLock 锁 ， 
然后 才能 进一步 调用 handleTransactionLocked， 最 后 再 将 
mHwWorkLi stDirty 《后 面 小 节 会 看 到 这 个 变量 的 作用 ) 置 为 true。 


显然 后 一 个 handleTransactionLocked 才 是 真正 处 理 业务 的 地 方 ， 
它 的 具体 工作 分 为 两 部 分 ， 即 traversal (对 应 eTraversalNeeded) 和 
transaction (对 应 eTransactionNeeded) : 


void SurfaceFlinger: :handleTransactionLocked(uint32_t transaction 
{ 
const LayerVector& currentLayers(mCurrentState.1layersSortedBy 
const size_t count = currentLayers.size(); 
if (transactionFlags & eTraversalNeeded) {V/VPart1L， 是 否 需要 tran 
for (size_t i=0 ; i<count ; i++) {// 逐 个 layer 来 处 理 
const sp<Layer>& layer(currentLayers[i]); 
uint32_t trFlags = layer->getTransactionFlags(eTransaction 




















AS t 

HI 

if (!trFlags) continue;// 如 果 不 需 要 的 话 ， 直 接 进入 下 一 轮 循环 

const uint32_t flags = layer->do Transaction(0);/* 由 各 

做 i 

if (flags & Layer::eVisibleRegion)// 各 Layer 计 算 可 见 区 域 ; 
mVisibleRegionsDirty = true;// 可 见 区 域 发 生变 化 





} 


if (transactionFlags & eDisplayTransactionNeeded) { 
…// 代 码 略 


if (transactionFlags & (eTraversalNeeded|eDisplayTransactionN 
…// 代 码 略 











} 
.//Part2. SurfaceFlinger 内 部 所 产生 的 “Transaction 的 处 理 
commitTransaction( );// 提 交 结 果 








TransactionFlags 分 为 3 种 类 别 ， 即 : 


enum { 
eTransactionNeeded = 0x01, 
eTraversalNeeded = 0x02, 


0x04, 
0x07// NF RUE 


eDisplayTransactionNeeded 
eTransactionMask 


}; 


上 述 代码 段 的 Part1 部 分 就 是 围绕 这 3 种 Flag 展 开 的 。 因 为 各 Flag 的 
处 理 过 程 基本 上 相似 ， 限 于 篇 幅 我 们 只 选取 eTraversalNeeded 为 例 来 讲 
解 。 


Part1. 处 理 各 Flags (以 eTraversalNeeded 为 例 ) 


先 来 看 eTraversalNeeded 的 处 理 。 从 名 称 可 以 看 出 ， 它 表示 当前 需 
要 一 个 “Traversal” 的 操作 ， 即 人 遍历 所 有 Layers。 


SurfaceFlinger 中 记录 当前 系统 中 1ayers 状 态 的 有 两 个 全 局 变量 ， 
分 别 是 
State mDrawingState; 
State mCurrentState; 


前 者 是 上 一 次 “drawing” 时 的 状态 ， 而 后 者 则 是 当前 状态 。 这 样 
我 们 只 要 通过 对 比 这 两 个 Sttate， 就 知道 Layer 在 两 次 状态 中 发 生 了 什么 
变化 ， 从 而 采取 相应 的 措施 。 它 们 内 部 都 包含 了 一 个 LayerVector 类 型 
的 layersSortedByZ 成 员 变 量 ， 从 变量 名 可 以 看 出 是 所 有 Layers 按 照 Z- 
order 顺 序 排列 而 成 的 Vector 。 


所 以 我 们 可 以 通过 mCurrentState. layersSortedByZz 来 遍历 所 有 
Layers， 然 后 对 其 中 需要 执行 transaction 的 Layer 调 用 内 部 的 
doTransaction() 。 显 然 ， 并 不 是 每 个 Layer 在 每 次 handleTransaction 
Locked 中 都 需要 调用 doTransact ion 一 一 判断 的 标准 就 是 
Layer: :getTransactionFlags 返 回 的 标志 中 是 否 指 明了 
eTransactionNeeded。 大 家 要 注意 SurfaceFlinger 和 Layer 都 有 一 个 
mTransactionFlags 变 量 ， 不 过 含义 不 同 。 另 外 ，Layer 对 象 中 也 同样 有 
mcCurrentState 和 mDrawingState， 却 属于 完全 不 同 的 Struct 数 据 结构 。 
其 对 比如 图 9-38 所 示 。 


-(reometry 
-Cieometry 


Layer State 


active; 
requested 


is Surtacct linger: State 
layerStack; 
alpha; 


-layerVector  layersSortedBy7, 


es ~DelauliKeyedVeclor<wp<TBinder>, DisplayDeviceSlate > cisplays: 


reserved [2]: 
sequence; 
transform: 
transparenRegion: 





A 9-38 两 个 State 结 构 体 对 比 


为 了 理解 各 个 Layer 究 竞 在 doTransaction 中 做 了 些 什 么 ， 我 们 先 穿 
插 分 析 下 它 的 实现 : 


uint32_t Layer::doTransaction(uint32_t flags) 


const Layer::State& front(drawingState());/*mDrawingState*/ 
const Layer::State& temp(currentState());/*mCurrentState*/ 


const bool sizeChanged = (temp.requested.w != front.requested 
h != front.requested.h); 
if (sizeChanged) {// 尺 寸 发 生变 化 


mSurfaceFlingerConsumer ->setDefaultBufferSize(temp.reques 
temp. reques 


} 


if (front.active != temp.active) {// 需 要 重新 计算 可 见 区 域 
flags |= Layer::eVisibleRegion; 








if (temp.sequence != front.sequence) {// 什 么 是 sequence? 
flags |= eVisibleRegion;// 也 需要 重新 计算 可 见 区 域 
this->contentDirty = true; 
const uint8_t type = temp.transform.getType(); 
mNeedsFiltering = (!temp.transform.preserveRects() || (ty 





commitTransaction(); 
return flags; 


首先 判断 Layer 的 尺寸 是 否 发 生 了 改变 (sizeChanged 变 量 ) , BS 
HIRA (temp) 中 的 宽 / 高 与 上 一 次 状态 (front) 一 致 与 否 。 假 如 size 
发 生 了 变化 ， 我 们 调用 mSurfaceFlingerConsumer 一 > 
setDefaultBufferSize() 来 使 它 生效 。 其 中 mSurfaceFl|ingerConsumer 
在 前 几 个 小 节 已 经 详细 分 析 过 ， 若 不 清楚 可 以 回头 看 看 。 


ek setDefaultBufferSize 0) 改变 的 是 内 部 的 mDefaultWidth 和 
mDefaultHeight 两 个 默认 的 宽 高 值 。 当 我 们 调用 requestBuffers () 请 求 
Buffer 时 ， 如 果 没 有 指定 width 和 height 〈 值 为 0) ，BufferQueue 就 会 
使 用 这 两 个 默认 配置 。 


接 下 来 的 难点 就 是 理解 sequence。 这 个 变量 是 一 个 int 值 ， 当 Layer 
Hposition, z-order, alpha, matrix, transparent region, 
flags，crop 等 一 系列 属性 发 生变 化 时 《〈 这 些 属 性 的 设置 函数 都 以 
setXXX 开 头 ， 如 setCrop，setFlags) , mCurrentState: :sequence 就 会 
自 增 。 因 而 当 doTransaction 时 ， 它 和 mDrawingState: :sequence 的 值 就 
不 一 样 了 。 相 比 于 每 次 属性 变化 时 都 马上 做 处 理 ， 这 样 的 设计 是 合理 
的 。 因 为 它 在 平时 只 收集 属性 的 变化 ， 直 到 特定 的 时 刻 (VSYNC 信 号 产 
HAY) 才 做 统一 处 理 。 一 方面 ， 这 节约 了 系统 资源 ; AAA, URE 
性 频繁 变化 ， 会 给 整个 画面 带 来 不 稳定 感 ， 而 采用 这 种 方式 就 能 规避 这 
些 问题 。 


仔细 观察 Layer 的 doTransaction () 实现 ， 我 们 可 以 大 致 得 出 它 的 目 
的 ， 就 是 通过 分 析 当 前 与 上 一 次 的 状态 变化 ， 来 制定 下 一 步 的 操作 一 一 
比如 是 否 要 重新 计算 可 见 区 域 (eVisibleRegion 、 是 否 需 要 重 绘 
(contentDirty) =. 


1 He Hel EB = ASurfaceFl ingeri — ùA, AmE aay 
返回 值 flags 传 递 给 SurfaceFlinger， 如 eVisibleRegion; 有 些 则 属于 
Layer 的 “家 务 ”， 因 而 只 要 内 部 做 好 标记 即 可 。 


最 后 ，commitTransaction () 把 mCurrentState 赋 值 给 
mpDrawingState， 这 样 它们 两 个 的 状态 就 又 一 样 了 。 在 下 一 轮 
doTransaction () 前 ，mCurrentState 又 会 随 着 属性 的 变更 〈 引 起 变更 的 
1 如 U1 程序 客户 端 主 动 发 起 的 申请 〉 而 产生 变化 ， 如 此 循环 往 


这 样 Layer : :doTransaction () 肖 数 就 结束 了 ， 带 着 flags 值 返回 到 
前 面 的 SurfaceFlinger:: handleTransactionLocked() 中 。 一 旦 某 个 
Layer 明 确 表 明 可 见 区 域 发 生 了 改变 CeVisibleRegion) ， 
SurfaceF1linger 就 会 将 其 mVisibleRegionsDirty 设 为 true， 这 个 标志 将 


影响 后 续 的 操作 。 
Part2. “内 务 ” 处理 


完成 当前 系统 中 所 有 Layer 的 遍历 后 ，SurfaceFlinger 就 进入 自己 
的 “内 务 ” 处 理 了 ， 即 handleTransactionLocked () 源码 中 的 第 二 部 
分 。 我 们 在 代码 中 列 出 了 它 需 要 完成 的 工作 ， 即 


o 新 增 Layet 


与 上 一 次 处 理 时 相 比 ， 系 统 可 能 有 新 增 的 Layer 。 我 们 只 要 对 比 两 
个 State 中 的 Layer 队 列 数目 是 否 一 致 就 可 以 得 出 结论 。 假 如 Layer 数 量 
有 增加 ， 可 见 区 域 需 要 重新 计算 ， 我 们 将 mVisibleRegionsDirty 置 为 


trues 
o 移 除 Layet 


和 上 面 的 情况 类 似 ， 有 些 Layer 也 可 能 被 移 除 了 。 针 对 这 种 情况 ， 
我 们 也 需要 重新 计算 可 见 区 域 。 可 是 怎么 知道 哪些 Layer 被 移 除了 呢 ? 
有 一 个 简单 的 办 法 就 是 比较 两 个 State 中 的 layersSortedByz 一 一 假如 一 
个 Layer 在 上 一 次 的 mDrawingState 中 还 有 ， 到 了 这 次 mCurrentState 找 
不 到 了 ， 那 么 就 可 以 认定 它 被 removed ss. RNB aK “MAIR 
图 层 ” 的 可 见 区 域 ， 因 为 一 旦 Layer 被 移 除 ， 则 意味 着 被 它 遮 盖 的 区 域 
就 有 可 能 重新 显露 出 来 。 


在 handleTransactionLocked () 末尾 ， 它 也 调用 了 
commitTransaction () 来 结束 整个 业务 处 理 。 








另外 ，SurfaceFlinger 还 需要 通知 所 有 被 移 除 的 Layer， 相 应 的 
cal | back K #t ÆonRemoved () 。Layer 在 得 到 这 一 消息 后 ， 就 知道 它 已 经 
被 SurfaceFlinger 剔 除了。 最后， 唤醒 所 有 正在 等 待 Transaction 结 束 
的 线程 : 


mTransactionCV.broadcast(); 


SurfaceFlinger:: handleTransaction () 的 流程 如 图 9-39 所 示 。 


SurfaceF linger 


handleTransaction 


handleTransactionLocked 






getTransactionFlags 


1. AIA Layer 


eTransactionNeeded 


doTransaction 






根据 返回 值 判断 






3.“ 内 务 ” 处 理 ， 如 Layer 被 移 除 





2. eDisplayTransactionNeeded， 与 显示 相关 的 变化 ， 如 orientation 


全 图 9-39 ”handleTransaction 流 程 图 


9.7.4 “下 面 已 经 过 时 /无 效 ， 需 要 重新 绘制 ”一 一 


handleMessagelnvalidate 


Invalidate 的 字面 意思 是 “使 无 效 ”， 在 不 少 窗口 系统 中 都 被 用 来 


表示 “界面 已 经 过 时 /无 效 ， 需 要 重新 绘制 ”。 在 SurfaceFlinger 中 ， 
与 lnvalidate 关 系 最 直接 的 是 Buffer 数 据 ， 因 而 
handleMessagelnvalidate 实 际 上 只 是 简单 地 调用 了 另 一 个 函数 
hand|ePageF | ip. 


PageF1ip 可 以 理解 为 “ 翻 页 ”。 从 字面 意思 上 来 理解 ， 它 的 确 


与 “图 层 缓冲 区 ”有 关系 一 一 因为 是 多 缓冲 机 制 ， 那 么 在 适当 的 时 机 融 
需要 做 “ 翻 页 ”的 动作 。 核 心 源码 如 下 : 


void SurfaceFlinger::handlePageFlip() 


Region dirtyRegion; 
bool visibleRegions = false; 
const LayerVector& currentLayers(mDrawingState. layersSortedBy 
const size_t count = currentLayers.size(); 
for (size_t i=0 ; i<count ; i++) { 
const sp<Layer>& layer(currentLayers[i]); 
const Region dirty(layer->latchBuffer(visibleRegions) );/* 
const Layer::State& s(layer->drawingState()); 
invalidateLayerStack(s.layerStack, dirty);//Step2. 更 新 Dis 


mVisibleRegionsDirty |= visibleRegions; 


Step1@SurfaceFlinger::handlePageFlip, jAitlatchBuffer Hl 


锁定 各 Layer 当 前 要 处 理 的 缓冲 区 。 源 码 作 者 用 了 一 个 有 趣 的 
词 “latch”， 形 象 地 表达 了 “把 门 门 上 ， 锁 住 Buffer” 的 意图 。 可 想 
而 知 ， 这 个 函数 一 定 与 BufferQueue 有 直接 联系 : 


Region Layer::latchBuffer(bool& recomputeVisibleRegions) 


Region outDirtyRegion; 

if (mQueuedFrames > 0) {...// 有 需要 处 理 的 Frame 
const bool oldOpacity = isOpaque(); 
sp<GraphicBuffer> oldActiveBuffer = mActiveBuffer; 

















if (android_atomic_dec(&mQueuedFrames) > 1) { 
mFlinger->signalLayerUpdate()j; 


} 

.….// 定 义 一 个 名 为 “Reject” 的 struct， 代 码 略 

Reject r(mDrawingState, currentState(), recomputeVisibleR 

if (mSurfaceFlingerConsumer->updateTexImage(&r) != NO_ERR 
al | Fe AEE, FP ZAR PAL 











mActiveBuffer = mSurfaceFlingerConsumer ->getCurrentBuf fer 


glTexParameterx(GL_TEXTURE_EXTERNAL_OES, GL_TEXTURE_WRAP_ 
glTexParameterx(GL_TEXTURE_EXTERNAL_OES, GL_TEXTURE_WRAP_ 
const Layer::State& front(drawingState()); 

Region dirtyRegion(Rect(front.active.w, front.active.h)); 
outDirtyRegion = (front.transform.transform(dirtyRegion) ) 


} 


return outDirtyRegion; 


Layer 中 继承 了 FrameAvai lableListener， 专 门 用 于 “ 监 
听 ”onFrameAvai lable。 因 而 当 BufferQueue 中 的 一 个 BufferSlot 被 
queued 后 ， 它 会 通知 这 个 Li stener， 进 而 调用 所 属 Layer 的 
onFrameQueued 这 个 函数 会 增加 mQueuedFrames 的 计数 ， 并 且 回 
SurfaceFlinger 发 出 一 个 INVALIDATE 信 号 (signalLayerUpdate) 。 


如 果 当 前 没有 任何 queued buffer，latchBuffer 什 么 都 不 用 做 ; 如 
果 当 前 有 多 个 mQueuedFrames， 除 了 正常 处 理 外 ， 我 们 还 需要 另外 调用 
signalLayerUpdate 来 组 织 一 次 新 的 invalidate。 





Layer 中 持 有 一 个 SurfaceFlingerConsumer 对 象 (成 员 变 量 
mSurfaceFlingerConsumer) ， 用 于 管理 BufferQueue。 根 据 前 几 个 小 节 
我 们 对 BufferQueue 状 态 迁 移 的 分 析 ， 一 旦 SurfaceFlinger (消费 者 ) 
需要 对 某 个 buffer 进 行 操 作 ， 首 先 应 该 accquire 它 一 一 这 个 动作 被 封装 
在 SurfaceFlinger Consumer: :updateTexlmage 中 。 除 此 之 外 ， 这 个 通 
数 还 需要 根据 Buffer 中 的 内 容 来 更 新 Texture， 稍 后 再 做 详细 分 析 。 


在 latchBuffer 内 部 定义 了 一 个 Reject 结 构 体 ， 并 作为 函数 参数 传 
递 给 updateTexlmage。 后 者 在 acqui re 到 buffer 后 ， 会 主动 调用 
Reject: :reject (来 判断 这 个 缓冲 区 是 否 符合 SurfaceF 1inger 的 要 求 。 
如 果 updateTexlmage 成 功 ，Layer 就 可 以 更 新 mActiveBuffer 了 ， 即 当前 
活跃 的 缓冲 区 〈 每 个 Layer 对 应 32 个 BufferSlot) ; 以 及 其 他 一 系列 相 
关内 部 成 员 变 量 ， 如 mCurrentCrop、mCurrentTransform 等 ， 这 部 分 源 





码 省 略 。 


纹理 贴图 还 涉及 很 多 细节 的 配置 ， 比 如 说 纹理 图 像 与 目标 的 矿 寸 大 


小 有 可 能 不 一 致 ， 这 种 情况 下 怎么 处 理 ? 或 者 当 纹 理 坐 标 超过 

[0. 0,1. 0] 范 围 时 ， 应 该 怎么 解决 ? 这 些 具体 的 处 理 方式 都 可 以 通过 调 
用 glTexParameterx (GLenum target，GLenum pname, GLfixed param) 
KAS. HAWE TSA E SA SHMRAD 〈 比 如 
GL_TEXTURE_WRAP_S 和 GL_TEXTURE_WRAP_T 分 别 代 表 两 个 坐标 维 ) ; 第 三 


个 参数 param 就 是 具体 的 配置 : 





status_t SurfaceFlingerConsumer: :updateTexImage(BufferRejecter* r 


fs, 


Mutex::Autolock lock(mMutex); 


BufferQueue: :BufferItem item; 
err = acquireBufferLocked(&item) ;//acquire—‘buffer 
int buf = item.mBuf; 
if (rejecter && rejecter->reject(mSlots[buf].mGraphicBuffer, 
// 这 个 b 
releaseBufferLocked(buf, EGL_NO_SYNC_KHR); 
return NO_ERROR;//JER, rejectikHlfalse mS" ; GUA Tez 





J 


// 生成 Texture 
err = releaseAndUpdateLocked(item) ; 


return err; 


这 个 函数 比较 长 ， 我 们 只 保留 了 最 核心 的 部 分 。 它 的 目标 是 更 新 


Layer 的 纹理 (Texture) ， 分 为 如 下 几 步 。 


(1) Acquire 一 个 需要 处 理 的 Buffer 。 根 据 前 面 对 Buffer 状 态 迁 移 


的 分 析 ， 当 消费 者 想 处 理 一 块 Buffer 时 ， 首 先 要 向 BufferQueue 做 
acquire 申 请 。 那 么 ，BufferQueue 怎 么 知道 当前 要 处 理 的 是 哪 一 个 
Buffer? 这 是 因为 其 内 部 维护 有 一 个 Fifo 先 入 先 出 队列 。 一 旦 有 
Buffer 被 enqueued 后 ， 就 会 被 压 入 队 尾 ; 每 次 acqui re 就 从 队 头 取 最 前 
面 的 元 素 进行 处 理 ， 完 成 之 后 再 将 其 从 队列 移 除 。 


(2) Acquire 到 的 Buffer 封 装 在 Buffer1tem 中 ，item. mBuf 代 表 它 


在 BufferSlot 中 的 序号 。 假 如 mEGLS1ots [buf]. mEg|11mage 当 前 不 为 空 


(EGL_NO_IMAGE_KHR) ， 则 需要 先 把 旧 的 image 销 毁 


(eg|IDestroylmageKHR) 。 


(3) SurfaceFlinger 有 权 决 定 updateTexlmage 得 到 的 Buffer 是 否 
为 合法 有 效 的 〈 比 如 说 size 是 否 正 确 ) ， 这 是 通过 
updateTex Image (BufferRe jecter* rejecter) 中 的 rejecter 对 象 来 完成 
的 。BufferRe jecter 实 现 了 一 个 reject 接 口 ， 用 于 验证 前 面 acqui re 到 
的 buffer 是 否 符合 SurfaceFlinger 的 要 求 。 


(4) 接 下 来 就 可 以 生成 Texture 了 ， 内 部 实现 中 需要 分 别 调用 
glBindTexture 和 g1EGLImage TargetTexture2D0ES。 后 一 个 函数 是 
OpenGL ES 中 对 g1Texlmage2D 的 扩展 〈 因 为 在 能 入 式 环 境 下 如 果 直 接 采 
用 glTexlmage2D1， 一 旦 图 片 很 大 时 会 严重 影响 执行 速度 ， 而 经 过 扩展 
后 的 g1EGLImageTargetTexture2D0ES 可 以 避免 这 个 问题 ) 。 这 个 接口 是 
和 eglcreatelmageKHR 配 套 使 用 的 ， 被 封装 在 前 面 的 createlmage 中 。 不 
了 解 这 些 函 数 用 法 的 读者 希望 能 自行 查询 0penGL ES 技术 文档 。 


(5) 消费 者 一 旦 处 理 完 Buffer， 就 可 以 将 其 release 了 。 此 后 这 个 
Buffer 就 又 恢复 到 FREE 状 态 ， 以 供 生 产 者 再 次 dequeue 使 用 之 后 ， 我 们 
需要 更 新 GLConsumer (SurfaceFlingerConsumer 的 父 类 ) 中 的 各 成 员 变 
量 ， 包 括 mCurrentTexture、mCurrentTextureBuf 等 。 


具体 如 图 9-40 所 示 。 
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lockPageFlip | 
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A 49-40 latchBuffet 流 程 图 


Step2@SurfaceFlinger::handlePageFlip, jai 
inval idateLayerStack 来 更 新 各 DisplayDevice 中 的 dirtyRegion。 内 部 
实现 比较 简单 ， 读 者 可 以 自行 分 析 。 


9.7.5 合成 前 的 准备 工作 一 一 preCompos ition 


从 字面 来 理解 就 是 “ 预 合成 ”一 一 即 合 成 前 的 准备 工作 。 在 分 析 
preComposition 的 具体 工作 前 ， 我 们 有 必要 先 了 解 下 VSync Rate. 


IDisplayEventConnection 中 提供 了 与 YSync Rate 有关 的 两 个 接 
口 : 


virtual void setVsyncRate(uint32_t count) = 0; 
virtual void requestNextVsync() = 0; // asynchronous 


它们 之 间 具 有 互 斥 的 关系 : 当 setVSyncRate 设 置 了 数值 1， 表 示 每 
个 VSync 信 号 都 要 报告 ; 数值 2 表示 隔 一 个 VSync 报 告 一 次 ; 数值 0 则 表示 
不 报告 任何 VSync， 除 非 有 人 主动 调用 了 requestNextVsync。 同 理 ， 除 
韭 setVSyncRate 设 置 的 值 为 0， 否 则 调用 requestNextVsync 来 安排 下 一 
次 VSync 会 被 认为 是 无 效 的 。 


接 下 来 我 们 看 看 preComposition 的 实现 : 
void SurfaceFlinger::preComposition() 


bool needExtraInvalidate = false; 
const LayerVector&currentLayers(mDrawingState. layersSortedByZ 
const size_t count = currentLayers.size();//Layer## 
for (size_t i=0 ; i<count ; i++) { 
if (currentLayers[i]->onPreComposition()) {// 调 用 每 个 Layeri 
needExtraInvalidate = true; 
} 


if (needExtraInvalidate) { 
signalLayerUpdate( ) ;// 这 个 函数 是 做 什么 的 ? 
} 


这 个 函数 的 逻辑 比较 简单 ， 它 会 遍历 系统 中 记录 的 所 有 Layers， 并 


一 一 调用 它们 的 onPre Composition。 换 句 话 说， 就 是 给 每 个 人 机 会 来 
做 “准备 工作 ”。 那 么 ， 需 要 做 什么 样 的 准备 呢 ? 


bool Layer::onPreComposition() {... 
return mQueuedFrames> 0; 
} 


可 见 当 onPreComposition 的 返回 值 为 true 了 时， 表示 
mQueuedFrames>0; 否则 就 是 false。 结 合 


SurfaceFlinger::preComposition 中 的 判断 ， 只 要 有 一 个 Layer 中 存在 
被 Queued 的 Frames， 那 么 needExtralnval idate 都 会 变 成 true。 这 时 就 


会 触发 如 下 的 函数 调用 流程 : 


SurfaceF linger: :signalLayerUpdateMessageQueue: : inval idatell 
NextVsync EventThread: :requestNextVsync: 


void EventThread: :requestNextVsync(const sp<EventThread: :Connecti 
Mutex::Autolock _1(mLock); 
if (connection->count < 0) {//<09 说 明 disabled 
connection->count = 0;//=0 说 明 还 有 可 以 接收 一 次 event 
mCondition. Br Oddeas te // 通 知 EventThread， 有 人 对 VSync 感 兴趣 


9 注意 
这 里 的 count 是 Connection 类 的 成 员 变 量 。 它 的 含义 如 下 : 
e 过 1 时 
可 以 连续 性 地 接收 事件 。 
。 =0Ht 
一 次 性 事件 〈 还 未 接收 ) 。 
e =-1 it 


可 以 认为 事件 接收 被 di sabled 了 。 


所 以 在 requestNextVsync 中 ， 如 果 connection->count<0， 会 被 重 
新 赋值 为 0， 代 表 这 个 connection 可 以 接收 一 次 事件 。 


最 后 ，requestNextVsync 会 调用 mCondition. broadcast () ， 那 么 是 
谁 在 等 待 呢 ? 


没 错 ， 还 是 EventThread。 我 们 知道 EventThread: :threadLoop 会 不 
断 地 调用 waitForEvent 来 等 待 Event。 这 个 函数 的 内 部 还 有 一 个 重要 的 
判断 ， 即 当前 是 否 有 对 VSync 信 号 感 兴 趣 的 人 《基于 所 有 Connection 中 
的 count 状 态 来 判断 ) : 有 的 话 才能 正常 返回 ， 否 则 调用 : 


mCondition.wait(mLock); 
进入 等 待 ， 直 到 有 人 来 唤醒 它 。 
9.7.6 可 见 区 域 一 一 rebui ldLayerStacks 


经 过 preComposition 后 ，SurfaceFlinger::handleMessageRefresh 
接着 会 调用 rebui 1dLayerStacks。 这 个 函数 负责 rebui 1d 所 有 可 见 的 
Layer (Visible Layer) 核心 思想 就 是 计算 有 了 哪些 Layer 是 可 见 的 及 
它们 的 可 见 区 域 。 源 码 实现 如 下 : 


void SurfaceFlinger::rebuildLayerStacks() { 
if (CC_UNLIKELY(mVisibleRegionsDirty)) {... 
mVisibleRegionsDirty = false;// 重 置 变量 
invalidateHwcGeometry();// 将 mHwWorkListDirty 置 为 true, 后 续 会 








const LayerVector& currentLayers(mDrawingState.layersSort 
for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {/*Step 
Region opaqueRegion;// 不 透明 区 域 
Region dirtyRegion;//“ 脏 ”区 域 
Vector< sp<Layer>> layersSortedByZ,;// 最 终 排序 后 的 可 见 Lay 
const sp<DisplayDevice>& hw(mDisplays[dpy]);/* 每 一 个 Di 
const Transform& tr(hw->getTransform());//Transform 变 ] 
const Rect bounds (hw->getBounds());//Display 的 区 域 
if (hw->canDraw()) {// 当 前 这 个 Display 是 否 可 以 绘制 
SurfaceFlinger: :computeVisibleRegions(currentLaye 
hw->getLayerStack(), dirtyRegion, opaqueReg 
const size_t count = currentLayers.size();// 当 前 La 
for (size_t i=0 ; i<count ; i++) {/*Step3 ,逐个 计算 : 
const sp<Layer>& layer(currentLayers[i]); 
const Layer::State& s(layer->drawingState()); 
if (s.layerStack == hw->getLayerStack()) {//HH 





Region drawRegion(tr.transform(layer->vis 

drawRegion.andSelf (bounds); 

if (!drawRegion.isEmpty()) {// 如 果 绘 制 区 域 不 
layersSortedByZ.add(layer); 


J 


/*Step4. 将 前 述 的 计算 结果 保存 到 hw 中 */ 
hw->setVisibleLayersSortedByZ(layersSortedByZ) ; 
hw->undefinedRegion.set(bounds); 
hw->undefinedRegion.subtractSelf(tr.transform(opaqueR 
hw->dirtyRegion.orSelf(dirtyRegion); 





Step1@SurfaceFlinger::rebuildLayerStacks。 前 面 说 过 ， 系 统 的 
Display 可 能 不 止 一 个 一 一 它们 都 存储 在 mDisplays 中 ， 
rebui 1dLayerStacks 需 要 逐个 处 理 这 些 Display。 这 个 函数 中 涉及 的 与 
Display 有 关 的 全 局 属性 包括 : 


e Transform mGlobalTransform 


即 整 个 Di splay 都 需要 做 的 Transform。 换 名 话说， 各 个 Layer 也 可 
以 有 自己 的 Transform。 


e int mDisplayWidth; 
int mDisplayHeight; 


即 Di splay 的 宽 和 高 ， 上 述 代 码 段 中 的 bounds 变 量 《hw- 
>getBounds () ) 得 到 的 是 : 


Rect(mDisplaywidth, mDisplayHeight). 


Step2@SurfaceFlinger::rebuildLayerStacks， 调 用 
computeVisibleRegions。 这 个 函数 将 根据 所 有 Layer (Bp 
currentLayers) 的 当前 状态 ， 计 算出 两 个 重要 变量 。 


e dirtyRegion 


“ 脏 ” 区 域 ， 也 就 是 需要 被 重新 绘制 的 区 域 。 
e opaqueRegion 


不 透明 区 域 ， 它 会 对 Z-0rdered 的 Layers 产 生 影响 。 因 为 排 在 前 面 
的 Layer 的 不 透明 区 域 可 能 会 遮挡 其 后 的 Layer 。 


函数 computeVisibleRegions 的 源码 实现 很 长 ， 我 们 放 在 后 面 单 独 
分 析 。 


Step3@SurfaceF | inger : :rebuildLayerStacks. #+t#WVisible 
Regions 后 ， 程 序 需要 进一步 确定 各 Layer 需 要 被 绘制 的 区 域 
(drawRegion) 。 


首先 要 明白 系统 中 可 用 的 Display 不 止 一 个 ， 但 所 有 的 Layers 却 都 
是 通过 mDrawingState. layersSortedByZ 来 记录 的 ， 显 然 系 统 需 要 一 个 
机 制 来 区 别 各 Layer 的 归属 方 一 一 这 就 是 LayerStack 的 作用 。 每 个 
ne eee “标志 ”， 作 为 SurfaceFlinger 管 理 它们 的 依 
Fo 





所 以 在 第 二 个 for 循 环 中 ， 需要 先 判 断 下 s. E E eae eat 
>getLayerStack: 是 的 话 才 需要 进一步 处 理 。 变 量 drawRegion 的 计算 过 
但 分 为 如 下 两 步 。 


(1) 对 Layer 中 的 visibleNonTransparentRegion 按 照 整个 Display 
的 Transform 要 求 进 行 变 换 。 其 中 visibleNonTransparentRegion 如 其 名 
所 示 ， 代 表 了 Layer 的 “可 见 不 透 明 区 域 ”， 是 由 前 面 的 
computeVisibleRegions 计 算出 来 的 。 


(2) 在 上 述 区 域 drawRegion 的 基础 上 考虑 bounds， 即 整个 Display 
的 区 域 限制 。 


后 得 到 的 dr awRegion 如 果 不 为 empty， 那 么 说 明 该 Layer 在 此 次 U 
刷新 过 程 中 是 需要 被 重新 绘制 的 ， 因 而 把 它 加 入 layersSortedByZ 中 。 
我 们 对 Layer 的 处 理 过 程 是 按照 z-0rder 顺 序 来 执行 的 ， 所 以 在 把 它们 依 
次 加 入 layersSortedByZz 时 ， 也 同样 已 经 “SortedByZ-0rder” 了 。 


Step4@SurfaceFlinger::rebuildLayerStacks。 这 一 步 将 前 面 的 计 


算 结 果 即 layersSortedByZ，opaqueRegion 等 保存 到 hw 中 ， 这 些 数据 对 
后 面 的 合成 起 到 了 关键 的 作用 。 


接 下 来 我 们 专门 分 析 下 computeVisibleRegions 的 实现 ， 其 中 Dirty 
区 域 的 计算 过 程 是 关注 的 重点 。 读 者 可 以 先 思考 下 ， 如 果 让 我 们 来 写 这 
个 函数 ， 该 如 何 实现 呢 ? 


把 问题 重新 明确 下 : 已 知 当前 所 有 的 Layers 《按照 Z-0rder 排 
F) ， 如 何 计算 它们 的 DirtyRegion 与 0paqueRegion? 


(1) 既然 Layers 是 Z-0rder 排 序 的 ， 那 么 我 们 在 处 理 各 个 Layer 时 
是 按照 递增 还 是 递减 的 顺序 来 执行 呢 ? 显然 是 递减 ， 因 为 Z-0rder 值 大 
的 更 靠近 “用 户 ”。 换 名 话说， 如 果 我 们 计算 出 某 Layer 的 
0paqueRegion， 那 么 后 面 比 它 Z-0rder 小 的 Layer 的 对 应 区 域 根 本 就 不 需 
要 考虑 一 一 从 用 户 视 角 来 看 ， 这 部 分 区 域 一 定 会 被 “遮挡 ”。 


(2) 计算 DirtyRegion 的 前 提 是 获得 该 图 层 的 可 见 区 域 ， 因 为 可 见 
区 域 之 外 的 “ 脏 ” 区 域 是 没有 意义 的 。 图 层 中 什么 样 的 区 域 是 可 见 的 
Ne? 至 少 需要 考虑 以 下 几 点 。 


e Z-Order 


各 Layer 的 Z-0rder 无 疑 是 第 一 要 素 。 因 为 排 在 越前 面 的 图 层 ， 其 获 
得 曝光 的 概率 越 大 ， 可 见 的 区 域 也 可 能 越 大 ， 如 图 9?-41 所 示 。 


前 面 说 过 ， 计 算 可 见 性 时 是 按照 Z-0rder 由 大 而 小 的 顺序 进行 的 。 
假如 一 个 Layer 的 某 个 区 域 被 确定 为 可 见 且 不 透明 ， 那 么 与 之 相对 应 的 
其 下 面 的 所 有 Layer 区 域 都 会 被 遮盖 而 不 可 见 。 


。 透明 度 


虽然 越前 面 的 Layer 优 先 级 越 高 ， 但 这 并 不 代表 后 面 的 “图 层 ” 完 
全 没有 机 会 。 只 要 前 一 个 Layer 不 是 完全 不 透明 〈 透 明 或 者 半 透 明 ) 
的 ， 那么 从 理论 上 来 讲 用 户 就 应 该 能 “ 透 过 ”这 部 分 区 域 看 到 后 面 的 内 
容 。 





e Layet 大 小 


与 透明 度 一 样 ，“ 图 层 ” 大 小 也 直接 影响 到 其 可 见 区 域 。 因 为 每 个 
Layer 都 是 有 大 有 小 的 ， 即 便 前 一 个 Layer 是 完全 不 透明 的 ， 但 只 要 它 的 
尺寸 没有 达到 “ 满 屏 ”， 那 么 比 它 Z-0rder 小 的 “图 层 ” 还 是 有 机 会 显 
示 出 来 的 。 这 也 是 我 们 需要 考虑 的 因素 之 一 。 

综合 上 面 的 几 点 分 析 ， 我 们 大 概 能 制定 出 计算 Layer 可 见 区 域 的 逻 


one 
辑 步 又 。 

按照 Z-0rder 逐 个 计算 各 Layer 的 可 见 区 域 ， 结 果 数 据 记 录 在 
LayerBase:: visibleRegion Screen 中 。 


对 于 2-0rder 值 最 大 的 Layer， 显 然 没有 其 他 “图 技 ” 会 遮 震 


它 。 所 以 它 的 可 见 区 域 (visibleRegion) 应 该 是 〈 当 然 ， 前 提 是 
这 个 Layer 没 有 超过 屏幕 区 域 ) 自身 的 大 小 再 减 去 完全 透明 的 部 分 
(transparentRegionScreen) ， 由 此 计算 出 来 的 结果 我 们 称 之 为 
aboveCoveredLayers。 这 个 变量 应 该 是 全 局 的 ， 因 为 它 需要 被 传递 
到 后 面 的 Layers 中 ， 然 后 不 断 地 做 累积 运算 ， 直 到 覆盖 整个 屏幕 区 


域 。 


A APAR 


2 


Z-Order HEH Layers 


全 图 9-41 后 面 的 Layetr 有 可 能 被 遮挡 而 不 可 见 





Layer-| 





全 图 9-42 Z-Order 最 大 的 Layer 可 见 区 域 示意 图 


如 图 9-42 所 示 ， 最 外 围 边框 是 这 个 “图 层 ” 的 尺寸 大 小 ， 中 间 挖 空 
区 域 则 是 完全 透明 的 ， 因 而 需要 被 吻 除 。 半 透明 区 域 比 较 特 殊 ， 它 既 属 
于 上 一 个 “图 层 ” 的 可 见 区 域 ， 又 不 被 列 为 遮盖 区 域 。 


。 对 于 Z-Otder 不 是 最 大 的 Layet， 它 首先 要 计算 自身 所 占 区 域 扣除 
aboveCoveredLayers (EW #Z-Order th © A By Layersiih 3 BY Bh) 后 所 
剩 的 空间 ， 然 后 才能 像 上 一 步 一 样 再 去 掉 完 全 透明 的 区 域 ， 这 样 得 
到 的 结果 就 是 它 最 终 的 可 见 区 域 ， 如 图 9-43 所 示 。 


此 区 域外 的 部 分 对 于 
Layer2 hie Al WH 


Layer) HEPA se ei i 





全 图 9-43 ”其 他 Layet 的 可 见 区 域 计算 


现在 我 们 可 以 进入 源码 分 析 了 : 


void SurfaceFlinger: :computeVisibleRegions(const LayerVector& cur 
re 
Region above0paqueLayers;// 对 于 当前 Layer 来 说 ， 是 在 它 “ 上 面 ”的 不 透明 | 
Region aboveCcoveredLayers;/* 对 于 当前 Layer 来 说 ， 是 在 它 “ 上 面 “的 遮盖 区 
Region dirty; 


outDirtyRegion.clear();//if# 
size_t i = currentLayers.size(); 
while (i--) {// 逐 步 处 理 各 Layer， 并 按照 Z-0rder 递 减 的 顺序 
const sp<Layer>& layer = currentLayers[i];// 当 前 处 理 的 Layer 


const Layer::State& s(layer->drawingState()); 


if (s.layerStack != layerStack)/* 义 进行 了 一 次 检查 ， 如 果 此 Laye 
continue; 
/* 接 下 来 的 几 个 变量 是 计算 的 基础 */ 
Region opaqueRegion;// 用 于 记录 完全 透明 区 域 
Region visibleRegion;// 可 见 区 域 ， 前面 已 经 讲解 过 了 
Region coveredRegion;// 被 覆盖 的 区 域 ， 前 面 已 经 讲解 过 了 
Region transparentRegion;// 完 全 透明 区 域 

















if (CC_LIKELY(layer->isVisible())) {// 判 断 Layer 的 Visible 属 1 
const bool translucent = !layer->is0paque();/* 不 是 0paqu 
translucent 
Rect bounds(s.transform.transform( layer ->computeBounds 
visibleRegion.set (bounds) ;//bounds mt 4A Hy AT IL x sak 
if (!visibleRegion.isEmpty()) { 
// 计 算 transparentRegion， 代 码 略 ... 
// 接 着 计算 opaqueRegion: 
const int32_t layerOrientation = s.transform.getor 
if (s.alpha==255 && !translucent && 
((layerOrientation & Transform: :ROT_INVALID) = uri 
opaqueRegion = visibleRegion; // ÆW LIK ILAA EE 





} 
} 
coveredRegion = aboveCoveredLayers.intersect(visibleRegio 
aboveCoveredLayers.orSelf(visibleRegion);// 为 下 一 个 Layer 计 入 
visibleRegion. subtractSelf (aboveOpaqueLayers) ; /* 前 面 我 们 说 六 
需要 考虑 被 其 上 面 
/* 现 在 可 见 区 域 已 经 得 出 来 了 ， 可 以 在 此 基础 上 计算 “ 脏 ” 区 域 了 。 换 句 话说 ， 
“在 可 见 区 域 范围 内 的 那些 需要 被 重新 绘制 的 内 容 ”*/ 
if (layer->contentDirty) {// 是 否 要 重新 绘制 所 有 区 域 
dirty = visibleRegion;// 是 的 话 “ 脏 “区域 自 然 就 等 于 可 见 区 域 了 
dirty,.orSelf(layer->visibleRegion);// 以 及 老 的 visibleRer 
layer->contentDirty = false; 
} else {// 不 需要 重新 绘制 所 有 区 域 的 情况 ， 见 后 面 的 注释 1 
const Region newExposed = visibleRegion - coveredRegi 
const Region oldVisibleRegion = layer->visibleRegion; 
const Region oldCoveredRegion = layer->coveredRegion; 
const Region oldExposed = oldVisibleRegion - oldCover 
dirty = (visibleRegion&oldCoveredRegion) | (newExpose 


















































dirty.subtractSelf(aboveOpaqueLayers ) ; 
outDirtyRegion.orSelf (dirty) ;//#ltLayer Hy” HEX sk” Ze yn Bll 4 fey 
aboveOpaqueLayers.orSelf(opaqueRegion) ;//##taboveOpaqueLa 


/* 将 这 些 计算 结果 存储 到 1ayer 中 ， 供 后 续 判 断 使 用 : */ 

layer ->setVisibleRegion(visibleRegion) ; 

layer ->setCoveredRegion(coveredRegion) ; 

layer ->setVisibleNonTransparentRegion(visibleRegion.subtr 























} 
outOpaqueRegion = above0paqueLayers;// 最 终 的 不 透明 区 域 就 是 above0l 


注释 1: 

在 不 需要 全 部 重 绘 的 情况 下 ， 应 考虑 如 下 因素 : 

(1) 这 一 次 被 “暴露 ”出 来 的 区 域 (newExposed) ; 

(2) 上 一 次 的 可 见 区 域 (oldVisibleRegion) ; 

(3) 上 一 次 被 覆盖 的 区 域 (oldCoveredRegion) ; 

(4) 上 一 次 被 “暴露 ”出 来 的 区 域 ColdExposed) 。 

相信 不 少 读者 会 有 这 样 的 疑问 ， 本 次 的 di rty 区 域 为 什么 要 考 
虑 “上 一 次 ”的 结果 呢 ? 举 个 例子 : 假设 在 上 一 次 的 计算 过 程 
中 ，“ 脏 ”区 域 原 本 有 oldDirty 那 么 大 ， 但 是 受 限 于 可 见 区 域 ， 有 一 部 
分 oldDirty 内 容 〈 暂 且 称 之 为 mi ssedDirty) 很 可 能 并 没有 真正 “ 显 
示 ” 到 屏幕 上 ; 而 到 了 本 次 计算 时 ， 如 果 missedDirty 区 域 没 有 任何 变 
化 ， 就 意味 着 它 不 再 是 Dirty 的 了 此 时 如 果 我 们 只 考虑 本 次 的 结 
果 ， 那 么 这 部 分 区 域 肯定 是 不 会 被 “绘制 ”出 来 的 。 


这 样 我 们 就 分 析 完 rebui 1dLayerStacks 的 处 理 过 程 了 ， 这 些 计算 结 
果 将 影响 后 续 SurfaceFlinger 的 合成 操作 。 








9.7.7 J “Composition” EMIA 


“万 事 俱 备 ， 只 欠 东 风 ”， 经 过 前 面 两 步 的 努力 ，“ 合 成 ”操作 所 
需 的 各 种 数据 已 经 准备 好 了 。 接 下 来 的 setUpHWComposer 就 是 
J “Composition” JMR, 

关于 HWComposer 我 们 在 前 几 个 小 节 已 经 接触 过 ， 要 特别 注意 源码 工 
程 中 有 两 个 HWComposer. h 文 件 ， 分 别 是 : 


hardware/libhardware/include/hardware/HwComposer .h 
frameworks/native/services/surfacefligner/displayhardware/HwCompo 


第 一 个 HWComposer 属 于 HAL 模 块 的 定义 ; 后 面 一 个 则 是 


setUpHWComposer 


SurfaceF1inger 管 理 HWComposer 模 块 而 设计 的 。 在 
SurfaceFlinger: :readyToRun 中 ， 程 序 会 调用 : 


mHwc = new HWComposer(this, *static_cast<HWComposer: :EventHan 


此 时 生成 的 HWComposer 担 当 的 是 “管理 者 ”身份 ， 而 它 的 构造 函数 
中 又 进一步 通过 loadHwcModule 来 加 载 名 称 为 “HWC_HARD 
WARE_MODULE_1D” 的 HWComposer 模 块 ， 如 图 ?-44 所 示 。 


SurfaceF linger 


HWComposer 


HWComposer (HAL) 


全 图 9-44 两 个 HWComposet 对 象 





先 来 了 解 下 HAL 层 的 HWComposer 提 供 的 接口 ， 如 表 9-8 所 示 。 


表 9-8 HWComposer 的 HAL 接 口 


| 


在 每 帧 图 像 合 成 前 ， 都 会 被 调用 。 它 用 于 判断 
HWC 模 块 在 合成 操作 中 所 能 完成 的 功能 。 具 体 而 
言 ，prepare 的 第 三 个 函数 参数 : 
hwc_display_contents_1_t** displays 中 有 个 
hwc_layer_1_t hwLayers[0] 成 员 变 量 ， 而 
hwc_layer_1_t 中 的 compositionType 则 是 HWC 对 
的 回应 ， 详 细 的 CompositionType 类 型 描述 
参见 后 面 表格 


set 接 口 用 于 代 倒 早期 版 本 中 的 eglSwapBuffers， 
而 从 功能 上 看 它们 是 基本 相同 的 。 通 过 前 一 个 
prepare, 现在 SurfaceFlinger 和 HWC 模 块 已 经 达成 
了 共识 一 一 即 哪 些 Layer 是 可 以 由 HWC 来 处 理 的 
(也 就 是 源码 中 所 称 的 Work List) ， 所 以 set 了 水 数 
就 是 将 这 些 Layer 的 具体 数据 传送 给 HWC 做 实 际 的 
操作 。 要 特别 注意 的 是 ，set 中 传 入 的 Layer list 必 须 
“Jprepare vt $F HOR AZ 吉 果 保持 一 致 。 可 以 猜想 到 ， 
set 内 部 实现 中 一 定 会 调用 eglSwapBuffers， 有 兴 
的 读者 可 以 找 一 个 具体 的 HWC 模 块 实现 来 验证 下 


用 于 控制 display 相 关 的 events 的 开 / 关 ， 如 
oo HWC_EVENT_VSYNC 
用 于 控制 屏幕 的 开局 和 关闭 
| 用 于 查询 HWC 的 各 种 状态 











eset 于 向 HWC 注 册 callback 函 数 ， 详 情 参 见 后 给 


” ”CompositionType 对 整个 合成 过 程 是 很 重要 的 参考 值 ， 如 表 9-9 所 
7J“ o 





表 9-9 参考 值 


在 prepare 前 被 调用 者 设置 的 值 。 表 
明 这 是 一 个 特别 的 “background” 图 
层 ， 此 时 只 有 backgroundColor 是 有 
效 的 


HWC_BACKGROUND 


也 是 在 prepare 前 被 调用 者 设置 的 
值 。 表 明 此 图 层 是 OpenGL ES 合成 
时 的 目标 “framebuffer surface”. 
在 
HWC_DEVICE API VERSION 1 1 
以 后 的 版 本 有 效 


HWC_FRAMEBUFFER_TARGET 





在 prepare 前 被 调用 者 设置 的 值 ， 且 
要 求 

HWC_FRAMEBUFFER HWC_GEOMETRY_CHANGEDt, 
应 该 置 位 。 表 明 Layer 将 通过 
OpenGL ES 来 绘制 到 framebuffer 中 





Hy 


生 prepare 的 执行 过 程 中 由 HWC 模 块 
来 设置 的 值 。 表 示 该 图 层 将 由 HWC 
HWC_OVERLAY 处 理 ， 而 不 是 像 上 面 的 


HWC_FRAMEBUFFERJ/t¥ H 
OpenGL ES 来 绘制 





通过 表 9-9 的 解释 ， 大 家 应 该 可 以 了 解 到 如 下 信息 : 合成 过 程 既 可 
以 由 HWC 模 块 来 完成 ， 也 可 以 通过 0penGL ES 来 处 理 。 具 体 采 用 哪 种 方式 
是 由 prepare () 的 结果 ， 即 CompositionType 来 决定 的 。 


使 用 者 可 以 向 HWC 模 块 注册 cal lback 函 数 来 接收 相关 事件 ， 包 括 : 


typedef struct hwc_procs { 
void (*invalidate)(const struct hwc_procs* procs);/* 触 发 屏幕 刷新 */ 
void (*vsync)(const struct hwc_procs* procs, int disp, int64_t ti 
前 面 表格 中 的 eventControl 接 口 将 HWC_EVENT_VSYNC 事 件 
VSync 信 号 的 话 就 会 回调 此 函数 */ 
void (*hotplug)(const struct hwc_procs* procs, int disp, int conn 
被 connected 或 者 disconnected 时 会 回调 此 函数 。 
display 必 须 一 直 是 connected 的 ， 所 以 不 适用 此 函 





了 解 了 以 上 这 些 知 识 ， 现 在 我 们 可 以 来 分 析 setUpHWComposer 的 源 
码 实现 了 。 


void SurfaceFlinger::setUpHWComposer() { 
HWComposer& hwc(getHwComposer()); 
if (hwc.initCheck() == NO_ERROR) { 
if (CC_UNLIKELY(mHwworkListDirty)) {//=4mHwworkListDirtyA 
mHwWworkListDirty = false; 
for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {// 
sp<const DisplayDevice> hw(mDisplays[dpy]); 
const int32_t id = hw->getHwcDisplayId(); 
if (id >= 0) { 
const Vector< sp<Layer>>& currentLayers(hw->g 
const size_t count = currentLayers.size();//L 

















if (hwc.createWorkList(id, count) == NO_ERROR 
wal [EAA AE FAS HS 
} 


} 


// set the per-frame data 
for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) { 
sp<const DisplayDevice> hw(mDisplays[dpy]); 


const int32_t id = hw->getHwcDisplaylId(); 
if (id >= 0) { 
const Vector< sp<Layer>>& currentLayers(hw->getVi 
/* 注 意 ， 是 所 有 可 见 Layers， 即 前 面 小 节 的 计算 结果 */ 
const size_t count = currentLayers.size(); 
HWComposer::LayerListIterator cur = hwc.begin(id) 
const HWComposer::LayerListIterator end = hwc.end 
for (size_t i=0 ; cur!=end && i<count ; ++i, ++cu 
const sp<Layer>& layer(currentLayers[i]); 
layer ->setPerFrameData(hw, *cur);//Step2. 注意 








J 


} 
status_t err = hwc.prepare();/*Step3. 调用 HWC 的 prepare*/ 
ALOGE_IF(err, "HWComposer::prepare failed (%s)", strerror 


WH 


刚 接触 这 个 函数 ， 相 信 不 少 读者 会 觉得 无 从 下 手 。 鉴 于 此 ， 我 们 和 希 
望 能 以 最 简洁 的 方式 把 setUpHWComposer 的 “骨干 ”体现 出 来 。 


用 一 句 话 来 概括 ，setUpHWComposer 用 于 把 需要 显示 的 那些 Layer 的 
数据 准备 好 ， 然 后 “报告 ”给 HWC 模 块 来 决定 由 谁 (0penGL ES 或 者 HWC 
自己 ) 进行 最 终 的 “合成 ”工作 。 


本 细 化 来 说 ， 实 际 上 它 只 完成 了 3 件 事 〈 也 就 是 代码 中 颜色 加 深 的 部 
JI o 

Step1@SurfaceFlinger::setUpHWComposer, #i&Work List。 这 个 
词 的 字面 意思 是 “工作 事项 ”， 它 是 SurfaceF1inger 写 给 HWC “Fh 
告 ”的 标准 格式 。 完 成 WorkLi st 构造 工作 的 是 createWorkLi st， 这 个 团 
数 会 从 全 局 变量 mDisplayData 中 取出 与 Display 对 应 的 DisplayData， 然 
后 给 其 中 各 field 进 行 必要 的 赋值 “其 中 最 重要 的 就 是 给 
DisplayData: :1ist 申 请 空间 ) 。 


Step2@SurfaceFlinger: :setUpHWComposer 。 好 了 ， 现 在 我 们 已 经 
构造 出 了 WorkList， 接 下 来 还 要 填充 各 Layer 的 数据 。 这 项 工作 是 由 每 
个 Layer 单 独 完 成 的 ， 调 用 的 接口 是 setPerFrameData。 关 键 源码 如 下 : 
void Layer::setPerFrameData(const sp<const DisplayDevice>& hw, HWC 


const Transform& tr = hw->getTransform(); 
Region visible = tr.transform(visibleRegion. intersect (hw->get 


layer .setVisibleRegionScreen(visible) ; 
layer .setBuffer(mActiveBuffer ) ;//stifbuffer NULL 


根据 前 几 个 小 节 对 显示 数据 的 分 析 ， 我 们 知道 各 “Producer” 生 产 
出 来 的 数据 是 存储 在 GraphicBuffer 中 的 ， 而 mActiveBuffer 则 代表 的 是 
当前 “活跃 ”的 Buffer 它 将 被 设置 到 layer 变 量 〈 要 特别 注意 ， 这 
个 layer 的 数据 类 型 是 HWComposer : :HWCLayer Interface, Mz 
Layer) 中 作为 本 次 合成 的 数据 。 值 得 一 提 的 是 ，mActiveBuffer 是 有 可 
能 为 NULL 的 ， 表 明生 产 者 还 未 生产 东西 ， 或 者 内 存 不 足 。 


Step3@SurfaceFlinger::setUpHWComposer. —WiE SRA, PW 
可 以 “报告 ”HWC 了。 不 过 不 要 志 记 有 两 个 HNComposer， 所 以 这 里 调用 
的 prepare 其 实 是 displayhardware 目 录 下 的 类 实现 : 





/*frameworks/native/services/surfaceflinger/displayhardware/HwCom 
status_t HWComposer::prepare() { 
for (size_t i=0 ; i<mNumDisplays ; i++) { 
DisplayData& disp(mDisplayData[i]); 


mLists[i] = disp. list; 


} 


int err = mHwc->prepare(mHwc，mNumDisplays，mLists);// 真 正 调用 | 


return (status_t)err; 


上 面 代码 段 中 的 mHwc 是 与 HWC 的 HAL 模 块 相 对 应 的 。 函 数 prepare 会 
对 DisplayData: :1ist 做 进一步 的 赋值 操作 ， 然 后 集中 所 有 Display 中 的 
list 〈 即 mLists) 一 并 传 给 HWC: :prepare。 注 意 : mLists 是 一 个 数组 指 
针 ， 或 者 说 是 二 级 指针 ， 这 是 HWC 能 正确 执行 prepare 的 关键 。 


这 样 HWC 就 在 WorkLi st 的 基础 上 判断 出 有 哪些 Layer 是 可 以 由 它 来 完 
成 的 了 。 


9.7.8 doDebugFlashRegions 
当 mDebugRegion 变 量 为 true 时 ， 系 统 才 会 执行 


doDebugFlashRegions。 而 mDebugRegion 本 身 则 是 由 系统 属性 
debug. sf. showupdates 来 决定 的 ， 默 认 值 为 false， 所 以 我 们 直接 略 


9.7.9 doComposition 


还 记得 我 们 在 setUpHWComposer 小 节 中 对 HWC 提 供 的 各 HAL 接 口 的 描 
述 吗 ? 前面 的 setUpHWComposer 只 是 将 显示 数据 “报告 ” (prepare) 给 
了 HWC， 决 定 了 由 谁 来 执行 “合成 ”操作 ， 而 真正 的 工作 还 并 未 开始 
一 一 显然 ， 这 是 doCompos ition 所 要 实现 的 功能 。 


对 于 合成 过 程 有 两 个 核心 点 : 


e 如 何 合成 ; 
e 如何 显 示 到 屏幕 上 。 
前 面 已 经 讲 过 ，“ 合 成 ” 既 可 以 由 0penGL ES 完成 ， 也 可 以 通过 HWC 


模块 来 处 理 ， 区 别 的 关键 就 在 于 CompositionType; 而 将 U1 数据 显示 到 
屏幕 上 的 关键 则 是 eg1SwapBuffers， 如 图 9-45 所 示 。 


SurfaceFlinger DisplayDevice HWComposer} | HWComposer (HAL) 
| 
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doComposition 
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| 
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| 
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A 9-45 doCompostion 的 调用 流程 图 


接 下 来 我 们 根据 流程 图 来 展开 源码 分 析 : 


void SurfaceFlinger::doComposition() { 
ATRACE_CALL(); 
const bool repaintEverything = android_atomic_and(0, &mRepain 
// 是 否 需要 “ 重 绘 " 所 有 数据 
for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {f/V/ 逐 个 处 理 D: 
const sp<DisplayDevice>& hw(mDisplays[dpy]); 
if (hw->canDraw()) { 
const Region dirtyRegion(hw->getDirtyRegion(repaintEv 
doDisplayComposition(hw，dirtyRegion);// 有 可 能 会 调用 egl 
hw->dirtyRegion.clear(); 
hw->flip(hw->swapRegion); 
hw->swapRegion.clear(); 


























} 
hw->compositionComplete( );// 通 知 HWC 合 成 已 经 完成 


} 
postFramebuffer();//HWC 的 set 接 口 就 是 在 这 里 调用 的 


变量 mRepaintEverything 用 于 指示 是 否 要 “ 重 绘 ”所 有 内 容 。 一 旦 
这 个 变量 为 true 的 话 ， 那 么 dirtyRegion 直 接 就 等 于 由 DisplayDevice 中 
的 mDisplayWidth 和 mDisplayHeight 组 成 的 Rect; 否则 由 
DisplayDevice::dirtyRegion 转 换 成 屏幕 坐标 而 来 。 


对 于 每 个 Di splayDevice 而 言 ， 它 们 需要 单独 调用 
doDi splayComposition 这 个 函数 有 可 能 通过 eg1SwapBuffers 来 交换 
前 后 台 Buffer 。 如 下 所 示 : 





void SurfaceFlinger: :doDisplayComposition(const sp<const DisplayD 
Region& inDirtyRegion) 
{ 
Region dirtyRegion(inDirtyRegion); 
hw->swapRegion.orSelf(dirtyRegion); 
uint32_t flags = hw->getFlags(); 
/* 先 对 dirtyRegion 进 行 “ 微 调 ”*/ 
if (flags & DisplayDevice: :SWAP_ RECTANGLE) { 
dirtyRegion.set(hw->swapRegion.bounds()); 
} else { 
if (flags & DisplayDevice::PARTIAL_UPDATES) { 
dirtyRegion.set(hw->swapRegion.bounds()); 


} else { 
dirtyRegion.set(hw->bounds()); 
hw->swapRegion = dirtyRegion; 


} 
} sf 
doComposeSurfaces(hw, dirtyRegion) ;// 合 成 数据 





hw->swapBuffers(getHwComposer ( )) ; // 交 换 前 后 台 ( 如果 需要 的 话 ) 


虽然 函数 入 人 参 inDi rtyRegion 已 经 指明 了 “ 脏 ” 区 域 ， 但 它 并 不 是 
直接 可 用 的 ， 还 需要 根据 条 件 进行 微调 。 


e DisplayDevice::SWAP_RECTANGLE 


此 时 只 要 求 泻 染 “ 脏 ” 区 域 ， 或 者 说 系统 在 软件 层面 上 支持 部 分 区 
域 更 新 ， 但 更 新 区 域 必 须 是 长 方形 的 。 由 于 这 个 限制 ，dirtyRegion 应 
该 是 履 盖 所 有 “ 脏 ” 区 域 的 最 小 矩形 。 


e DisplayDevice::PARTIAL_UPDATES 
系统 支持 硬件 层面 部 分 区 域 更 新 ， 同 样 也 要 求 是 矩形 区 域 。 
o 其 他 


除了 上 面 两 种 情况 外 ， 我 们 需要 “ 重 绘 ”整个 Display 区 域 ， 即 
hw. bounds () 。 


人 确认 完 最 终 的 dirtyRegion 后 ， 现 在 可 以 调用 doComposeSurfaces 
了 。 从 名 称 中 可 以 看 出 ， 这 个 函数 用 于 “Compose” Surface。 相 信 读 
者 会 有 疑问 ， 这 里 的 Surface 指 什么 呢 ? 


void SurfaceFlinger: :doComposeSurfaces(const Sp<const DisplayDevi 
Region& dirty) 
{ 
const int32_t id = hw->getHwcDisplayId(); 
HWComposer& hwc(getHwComposer()); 
HWComposer::LayerListIterator cur = hwc.begin(id); 
const HWComposer::LayerListIterator end = hwc.end(id); 


const bool hasGlesComposition = hwc.hasGlesComposition(id) | | 


if (hasGlesComposition) { 
if (!DisplayDevice: :makeCurrent(mEGLDisplay, hw, mEGLCont 
ALOGW("DisplayDevice: :makeCurrent failed. Aborting sur 
hw->getDisplayName().string()); 
return; 














} 
glMatrixMode(GL_MODELVIEW);// 指 定 哪 一 个 矩阵 是 当前 矩阵 
glLoadIdentity();// 单 位 和 矩阵 
const bool hasHwcComposition = hwc.hasHwcComposition(id); 
if (hasHwcComposition) { 
glClearColor(0, 0, 0, 0); 
glClear(GL_COLOR_BUFFER_BIT); 
} else { 


} 





const Vector< sp<Layer>>& layers(hw->getVisibleLayersSortedBy 
const size_t count = layers.size(); 
const Transform& tr = hw->getTransform(); 
if (cur != end) {/* 使 用 HWC 的 情况 */ 
-/* 代 码 后 续 分 析 */ 
} else {/* 不 使 用 HWC 的 情况 */ 
aD / RIBBER 








先 来 看 两 个 变量 : 
1. hasGlesComposition 
个 变量 在 两 种 情况 下 会 是 true。 


。 在 prepare 的 处 理 过 程 中 ， 如 果 有 layet 的 compositionType 是 
HWC_FRAMEBUFFER, 4} 4 DisplayData:: hasFbComp 会 被 置 为 true 
一 一 通常 情况 下 ，HWComposet:: hasGlesComposition 就 是 由 它 决定 
的 。 

e cuf==end， 此 时 说 明 需 要 由 OpenGL ES 来 处 理 合成 。 











2. hasHwcComposition 


需要 特别 注意 的 是 ， 这 个 变量 和 hasGlesCompos ition 并 不 是 互 斥 


的 ， 它 们 有 可 能 同时 为 true 一 一 这 种 情况 说 明 既 有 需要 0penGL ES 处 理 
的 layer， 也 有 需要 HWC 来 执行 合成 的 layer。 


了 解 这 两 个 变量 ， 对 理 清 doComposeSurfaces 的 函数 逻辑 有 一 定 帮 
助 。 


如 果 hasGlesComposition 条 件 成 立 的 话 ， 那 么 程序 首先 通过 
makeCurrent 来 设置 当前 的 泻 染 环境 ， 然 后 调用 
glMatrixMode (GL_MODELVIEW) 来 设置 当前 矩阵。 顺便 说 一 下 ， 
glMatrixMode 有 3 种 可 选 参数 ， 具 体 包括 如 下 。 
GL_MODELVIEW: 将 接 下 来 的 矩阵 操作 应 用 到 模型 视 景 矩阵 中 。 
GL_PROJECTION: 将 接 下 来 的 矩阵 操作 应 用 到 投影 矩阵 中 。 
GL_TEXTURE: 将 接 下 来 的 矩阵 操作 应 用 到 纹理 和 矩阵 中 。 


后 者 会 把 当前 矩 阵 设置 为 单位 
ERF. 


紧 接 着 如 果 hasHwcComposition 为 true 的 话 ， 那 么 程序 会 使 用 
glClear 来 将 窗口 清除 为 g1C1earColor 所 指定 的 color， 即 
(0,0,0,0) à 


a 程序 就 真正 进入 “图 层 ” 的 处 理 了 。 这 里 又 分 为 
两 种 情况 : 


1. cur== end 


此 时 就 不 是 由 HWC 来 主导 了 ， 核 心 实 现 是 通过 1ayer->draw 来 完成 
的 ， 下 面 有 详细 讲解 。 


2. cur!l= end 
说 明 将 使 用 HWC Composer 。 这 部 分 代码 如 下 : 
for (size_t i=0 ; i<count && cur!=end ; ++i, ++cur) { 


const sp<Layer>& layer(layers[i]); 
const Region clip(dirty.intersect(tr.transform(layer- 


if (!clip.isEmpty()) { 
Switch (cur->getCompositionType()) { 
case HWC_OVERLAY: { 
if ((cur->getHints() & HWC_HINT_CLEAR_FB) 
&& layer->i1sOpaque()&& hasGlesCo 
layer->clearWithOpenGL(hw, clip); 
} 


break; 


} 

case HWC_FRAMEBUFFER: { 
layer ->draw(hw, clip);//HOpenGL ES 来 处 理 
break; 














} 
} | 
layer->setAcquireFence(hw, *cur); 


} 


细 市 部 分 我 们 不 再 获 述 ， 读 者 可 以 自行 阅读 。 当 CompositionType 
为 HWC_FRAMEBUFFERH 了 时， 说 明 此 1ayer 需 要 由 0penGL ES 来 处 理 ， 具 体 而 
言 就 是 调用 layer->draw， 然 后 draw 又 直接 调用 了 onDraw: 


void Layer::onDraw(const sp<const DisplayDevice>& hw, const Regio 


if (CC_UNLIKELY(mActiveBuffer == 0)) { 
/* 如 果 texture 还 没有 生成 ， 换 句 话说 ， 此 Layer 未 绘制 过 。 这 是 有 可 能 发 人 
没有 办 法 知道 客户 程序 什么 时 候 才 会 进行 第 一 次 绘制 。 当 发 生 这 种 情况 时 ， 急 
东西 的 话 ， 就 将 屏幕 “ 涂 黑 ”， 否 则 跳 过 */ 
…// 代 码 略 


























} 


status_t err = mSurfaceFlingerConsumer->bindTextureImage( ) ; 
.…//0penGL ES 环境 的 准备 工作 ， 省 略 
drawwithOpenGL(hw, clip); 


变量 mAct iveBuffer 在 前 面 几 个 小 节 的 处 理 中 已 经 被 设置 成 最 新 的 
缓冲 区 了 。 但 它 有 可 能 是 空 的 ， 如 应 用 程序 还 没有 开始 做 绘制 工作 ， 在 
此 之 前 都 可 能 发 生 这 种 情况 。 此 时 程序 将 进一步 找 出 所 有 在 此 layer 之 
下 的 可 见 区 域 ， 再 由 此 计算 不 会 被 遮盖 的 区 域 : 


Region holes(clip.subtract(under) ); 


除 holes 之 外 的 所 有 区 域 ， 都 会 被 “ 涂 黑 ”， 这 是 由 





clearWithOpenGL (holes，0，0，0， 人 完成 的 。 紧 接着 通过 
SurfaceF1ingerConsumer::bindTexturelmage 来 把 当前 缓冲 区 数据 绑 定 
到 0penGL 纹 理 中 。 


接 下 来 根据 当前 情况 调用 openg1 的 各 AP1 接 口 进行 必要 配置 ， 为 
drawWithopenGL 做 最 后 准备 工作 : 


void Layer: :drawwithopenGL(const sp<const DisplayDevice>& hw, con 
const uint32_t fbHeight = hw->getHeight();//DisplayM ime 
const State& s(drawingState());//mDrawingState 
/*Parti: 判断 是 否 需 要 BLEND? */ 
GLenum src = mPremultipliedAlpha ? GL_ONE : GL_SRC_ALPHA; 
if (CC_UNLIKELY(s.alpha < OxFF)) {// 非 完全 不 透明 
const GLfloat alpha = s.alpha * (1.0f/255.0f);;// 归 一 化 
if (mPremultipliedAlpha) {// 预 乘 alpha 打 开 
glColor4f(alpha，alpha，alpha，alpha);// 两 个 函数 的 RGBA3 
} else { 
glColor4f(1i, 1, 1, alpha); 











} 
glEnable(GL_BLEND) ;// 需 要 混合 
glBlendFunc(src, GL_ONE_MINUS_SRC_ALPHA); //i#il] IRA HIF 
glTexEnvx(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULAT 
} else {// 完 全 不 透明 ，alpha 为 1 
glColor4f(1, 1, 1, 1); 
glTexEnvx(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE 
if (!isOpaque()) {// 不 是 opaque， 也 需要 blend 
glEnable(GL_BLEND); 
glBlendFunc(src, GL_ONE_MINUS_SRC_ALPHA);//lAlfiifis.alp 
} else { 
glDisable(GL_BLEND) ,;// 不 需要 blend 
} 




















} 
/*Part2: 下 面 开始 执行 具体 操作 */ 
struct TexCoords { /* 顶 点 结构 体 */ 


GLfloat u; 
GLfloat v; 





}; 


const Rect win(computeBounds());// 边 框 

GLfloat left = GLfloat(win.left) / GLfloat(s.active.w);//Aidz 
GLfloat top = GLfloat(win.top) / GLfloat(s.active.h);// EZ% 
GLfloat right = GLfloat(win.right) / GLfloat(s.active.w) ;//43 
GLfloat bottom = GLfloat(win.bottom) / GLfloat(s.active.h);// 





TexCoords texCoords[4];// 定 义 4 个 顶点 





texCoords[0].u = left;/*texCoords[4]， 分别 用 来 表示 下 面 的 几 个 顶点 */ 
texCoords[0].v = top; /*win 框 的 左上 、 ve ela ey 
texCoords[1].u = left; 

texCoords[1].v = bottom; 

texCoords[2].u = right; 

texCoords[2].v = bottom; 

texCoords[3].u = right; 

texCoords[3].v = top; 

for (int i = 0; i < 4; i++) { 


texCoords[i].v = 1.0f - texCoords[i].v; 


} 


glEnableClientState(GL_TEXTURE_COORD_ARRAY ) ; // 接 下 来 要 处 理 纹理 从 
glTexCoordPointer(2，GL_FLOAT，0，texCoords);// 设 置 纹理 坐 标 数组 
glVertexPointer(2, GL_FLOAT, ©, mesh.getVertices());//iK BJA: 
glDrawArrays(GL_TRIANGLE_FAN, 0, mesh.getVertexCount());/* 根 据 

pri 


















































glDisableClientState(GL_TEXTURE_COORD_ARRAY) ; 
glDisable(GL_BLEND) ,;// 关 闭 BLEND 


整个 函数 逻辑 分 为 两 部 分 : 首先 判断 是 否 需要 BLEND， 然 后 再 执行 
具体 的 操作 。 


量 mPremultipliedAlpha 表 示 “ 预 乘 alpha 通 道 ”， 它 是 RGBA 的 另 
二 和 比如 传统 的 RGBA 是 ees a) ， 而 premultiplied 
alpha 就 是 〈ra, ga, ba, a) 。 在 某 些 场景 “采用 后 一 种 方式 能 达到 更 好 
的 效果 ， 大 家 可 以 自 和 了 查阅 相关 次 失 料 以 了 解 详情 。 


因而 当 mPremultipliedAlpha 为 true 时 ， 设 置 颜色 : 
glColor4f(alpha, alpha, alpha, alpha); 
否则 就 是 : 
glColor4f(1, 1, 1, alpha); 
在 判断 是 否 需要 BLEND 时 有 如 下 几 种 情况 
。 当前 不 是 完全 不 透明 的 


毋庸 置疑 ， 这 种 情况 需要 开启 BLEND。 
。 当前 是 完全 不 透明 的 


如 果 is0paque () 返回 值 为 false， 那 么 还 是 需要 开启 BLEND 功 能 ; A 
则 Disable BLEND. 


开启 BLEND 在 0peng | ES 中 对 应 的 AP1 是 g1Enab | e (GLenum cap), & 


数 为 GL_BLEND。BLEND 的 目的 就 是 通过 “ 源 色 ”和 “目标 色 ” 的 混合 计 
_ 透明 特效 ， 有 多 种 混合 算法 可 供 选择 ， 由 glBlendFunc 来 配 


glBlendFunc(GLenum sfactor, GLenum dfactor); 
第 一 个 参数 是 源 因 子 ， 后 一 个 则 是 目标 因子 。 
可 选 值 如 表 9-10 所 示 。 


表 9-10 EE om | 


Gro oo hemo eoof RAT 0 作为 混合 因 
crome eo 0 作为 混合 因子 


根据 源 颜色 的 各 分 量 计算 出 泥 


GL_SRC_COLOR Snr 


根据 〈1- 源 颜色 各 分 量 ) 计算 
出 混合 A 因子 


GL_ONE_MINUS_SRC_COLOR 





| pat S 


i 


aaa | F 


根据 〈1.0- 源 颜色 alpha) 计算 


GL_ONE_MINUS_SRC_ALPHA 
ae cane, 出 混合 因子 


GL DST_ALPHA a 颜色 的 alpha 计 算出 混 


根据 《〈1.0- 目 标 颜 色 alpha) 计 
GL_ONE_MINUS_DST_ALPHA| 筑 出 混合 因子 





GL_DST COLOR 根据 目标 颜色 的 各 分 量 计 算出 
混合 因子 


根据 《〈1- 目 标 颜色 各 分 量 ) 计 
GL_ONE_MINUS_DST_COLOR| 筑 出 混合 因子 








每 种 情况 下 混合 因子 的 具体 算法 以 及 blend 的 计算 公式 ， 可 以 参考 
官方 文档 描述 。 这 里 我 们 只 要 明白 它 的 使 用 方法 即 可 。 


完成 BLEND 功 能 的 判断 后 ， 接 下 来 就 可 以 执行 具体 操作 了 。 


首先 计算 纹理 区 域 的 各 坐标 点 ， 结 果 值 以 texCoords[4] 数 组 来 记 
录 。 这 样 做 的 目的 是 保证 我 们 外 在 正确 的 区 域 中 绘制 图 形 。 一 切 准 备 就 
绪 ， 最 后 就 可 以 调用 0penGL ES 的 各 AP1 接 口 进行 绘制 了 。 


其 中 glEnableClientState (GL_TEXTURE_COORD_ARRAY) 说 明 要 处 理 
的 是 纹理 坐标 数组 ，glVertexPointer (2, GL_FLOAT, 0, mVertices) #§ 
明 是 二 维 坐标 ，float 数 据 类 型 ， 紧 凑 方 式 排 列 ， 摘 述 顶 点 数组 的 是 
mVertices (这 个 数组 值 在 validateVisibility 中 计算 ,个 数 为 4) ; 
glTexCoordPointer (2, GL FLOAT, 0, texCoords) 也 表示 二 维 坐标 系 ， 


float 数 据 类 型 ， 紧 凑 排 列 ， 纹 理 的 项 点 数组 由 前 面 计 算得 到 的 
texCoords 表 示 。 


最 后 ， 调 用 glDrawArrays (GL _TRIANGLE FAN，0，mNumVertices) 来 
绘制 三 角形 。0penGL ES 取消 了 对 QUAD 的 支持 ， 但 提供 了 
GL_TRIANGLE_FAN 与 GL_TRIANGLE_STRIP 两 种 三 角形 绘制 方式 。 下 面 大 致 
讲解 下 它们 的 操作 方式 。 


GL_TRIANGLE_FAN: 假设 有 N 个 顶点 ， 那 么 第 n 个 三 角形 的 顶点 就 是 
(1, n+1, n+2) ， 总 共有 N-2 个 三 角形 。 


GL_TRIANGLE STRIP: 假设 有 N 个 项 点， 也 是 有 N-2 个 三 角形 。 
。 NAAM (odd) 。 那 么 第 n 个 三 角形 的 顶点 是 (n, n+1, n+2) 。 


。 N 为 偶数 (even) 。 那 么 第 n 个 三 角形 的 顶点 就 是 


(Cn+1, n, n+2) 。 
以 这 个 场景 为 例 ， 因 为 mVyertices[0]- mVertices[3] PARRA 


上 、 左 下 、 右 下 、 右 上 4 个 顶点 〈 可 以 参见 validateVisibility 中 的 实 
现 ) ， 那 么 采用 这 两 种 模式 的 结果 如 图 ?-46 所 示 。 


Vl 





V 
GL TRIANGLE FAN GL TRIANGLE STRIP 


全 图 9-46 三 角形 绘制 的 两 种 模式 


这 样 drawWith0penGL 就 成 功 完成 当前 Layer 的 绘制 了 ， 然 后 先 返 回 
doComposeSurfaces, F3J&[EldoDisplayComposition#: 


void SurfaceFlinger::doDisplayComposition(const sp<const DisplayD 

Region& inDirtyRegion) 

oe 

doCcomposeSurfaces(hw，dirtyRegion);/* 返 回 到 这 里 ， 此 时 已 经 完成 了 hw 中 相关 
compose 工 作 */ 


hw->swapBuffers(getHwComposer()); 


虽然 相关 Layer 的 compose 已 经 完成 ， 但 用 户 此 时 还 看 不 到 ， 因 为 我 
们 还 需要 最 后 一 个 关键 操作 ， 即 swapBuffers: 


void DisplayDevice: :swapBuffers(HWComposer& hwc) const { 
if (hwc.initCheck() != NO_ERROR || (hwc.hasGlesComposition(mH 
hwc.supportsFramebufferTarget())) { 
EGLBoolean success = eglSwapBuffers(mDisplay, mSurface); 


可 以 看 到 ， 程 序 并 不 是 在 任何 情况 下 都 会 调用 eglSwapBuffers 来 交 
换 前 后 台数 据 。 需 要 满足 如 下 条 件 之 一 : 


e hwc.initCheck0 != NO_ERROR 
也 就 是 说 ，HWC 模 块 无 法 正确 加 载 使 用 。 


e hwc.hasGlesComposition(mHwcDisplayld) 
&&hwe.supportsFramebufferTarget() 


有 的 Layer 的 compositionType 是 HWC_FRAMEBUFFER， 且 HWC 支 持 
Framebuffer Target。 


当 doDisplayComposition 返 回 时 ， 说 明 doComposition 对 某 个 
DisplayDevice 的 处 理 结 束 ， 接 着 它 会 继续 进入 下 一 轮 循环 ， 直 到 所 有 
DisplayDevice 的 处 理 都 完成 。 最 后 ，doComposition 调 用 如 下 函数 : 


void SurfaceFlinger: :postFramebuffer ( ) 


HWComposer& hwc(getHwComposer()); 
if (hwc.initCheck() == NO_ERROR) { 


hwc .commit( ) ， 


在 HWComposer : :commint 中 ， 将 调用 HWC 模 块 的 HAL 接 口 set。 这 个 豫 
数 我 们 前 面 已 经 讲解 过 ， 大 家 可 以 回头 看 看 。 


后 以 图 9-47 来 总 结 本 小 节 的 内 容 ， 和 希望 能 帮助 读者 理 顺 整个 流 


1. 


2. 


HWComposer prepare 
Composition ype 


HWC FRAMEBUFFER HWC OVERLAY 
OpenGL ES HWC HAL 
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WindowManagerService 〈 以 下 简称 WMS) 是 做 什么 的 ? 


“Window” 表 明 它 是 与 窗口 相关 的 ，“Manager” 指 出 它 具 有 管理 
者 的 身份 。 因 而 简单 来 说 ， 它 就 是 “窗口 管理 员 ” “窗口 ”是 一 个 
抽象 的 概念 ， 从 用 户 的 角度 来 讲 ， 它 是 一 个 “页面 ”， 如 拨号 面板 ; 从 
SurfaceFlinger 的 角度 来 看 ， 它 是 一 个 Layer， 承 载 着 和 “表面 ”有 关 
的 数据 和 属性 ; 从 WMS 的 角度 来 看 ， 它 是 一 个 WindowState， 用 于 管理 
和 “表面 ”有 关 的 状态 。 综 合 来 说 ， 无 论 是 SurfaceFlinger、WMS 或 者 
后 面 章 节 中 将 会 分 析 的 ViewRoot， 都 是 在 为 “同一 个 目标 ”而 努力 一 一 
正确 高 效 地 显示 U1 界面 ， 只 不 过 大 家 的 职责 不 一 样 。 


打 个 比方 ， 就 像 一 出 由 N 个 演员 参与 的 话剧 : SurfaceF1inger 是 摄 
像 机 ，WMS 是 导演 ，ViewRoot 则 是 演员 个 体 。 摄 像 机 
(SurfaceFlinger) 的 作用 是 单一 而 规范 的 一 一 它 负 责 客观 地 捕获 当前 
的 画面 ， 然 后 真实 地 呈现 给 观众 ; 导演 《WMS〉 则 会 考虑 到 话剧 的 舞台 
效果 和 视觉 美感 ， 如 他 需要 根据 实际 情况 来 安排 各 个 演员 的 排序 站 位 ， 
谁 在 前 谁 在 后 ， 都 会 影响 到 演出 的 “画面 效果 ”与 “剧情 编排 ”; 而 各 
个 演员 的 长 相 和 表情 (ViewRoot) ， 则 更 多 地 取决 于 他 们 自身 的 条 件 与 
努力 。 正 是 通过 这 三 者 的 “各 司 其 职 ”， 才 能 最 终 为 观众 呈现 出 一 场 美 
妙 绝伦 的 “视觉 盛宴 ”。 


从 计算 机 1/0 系 统 的 角度 来 分 析 ，WMS 至 少 要 完成 以 下 两 个 功能 。 


。 全 局 的 窗口 管理 (Output) 





根据 计算 机 体系 结构 的 分 类 ，“ 窗 口 管理 ”属于 “输出 ”部 分 一 一 
应 用 程序 的 显示 请 求 在 SurfaceF1linger 和 WMS 的 协助 下 有 序 地 输出 给 物 
理 屏幕 或 者 其 他 显示 设备 。 

。 全 局 的 事件 管理 派发 〈Input) 

与 此 相对 应 ，“ 事 件 的 管理 派发 ”就 可 以 看 作 WMS 的 “输入 ” 功 
能 。 这 同时 也 是 WMS 区 别 于 SurfaceF linger 的 一 个 重要 因素 一 一 因为 后 
者 只 做 与 “显示 ”相关 的 事情 ， 而 WMS 则 还 要 “兼职 ”对 输入 事件 的 派 
发 。 因 为 硬件 配置 的 差异 ， 不 同 的 产品 对 于 事件 的 管理 需求 也 是 不 一 样 
的 。 需 要 WMS 管理 的 事件 源 包 括 但 不 限于 : 

。 键盘 


岁入 式 设备 〈 比 如 手机 〉 通常 不 会 配备 Qwerty 全 键盘 ， 更 多 情况 下 
只 是 设计 了 Home、Back、Menu、Vol+/- 等 常用 的 功能 按 键 。 


。 触摸 屏 
目前 市 面 上 的 主流 Android 设 备 都 配备 了 触摸 屏 
。 鼠标 
不 常见 ， 移 动 式 设备 很 少 支持 鼠标 。 
o 轨迹 球 (Trackball) 
可 能 不 少 读者 对 轨迹 球 比 较 陌 生 ， 它 在 手机 发 展 的 早期 曾经 存在 过 


一 段 时 间 (如 2008 年 上 市 的 G6og1e 第 一 款 手 机 61)， 不 过 已 经 逐渐 退出 
了 历史 舞台 。 有 兴趣 的 读者 可 以 自行 查阅 相关 资料 。 


10.1 “窗口 管理 员 ” 一 一 WMS 综述 


了 解 了 WMS“ 需 要 做 什么 ”后 ， 接 下 来 可 以 有 针对 性 地 去 分 析 它 
是 “怎么 做 的 了 ”。 在 看 Android 给 出 的 答案 之 前 ， 读 者 可 以 先 试想 一 
下 ， 如 果 让 我 们 来 设计 一 个 窗口 管理 器 ， 该 如 何 着 手 ? 相信 经 过 自己 的 
思考 与 探索 再来 研究 Android 中 的 源码 ， 很 多 东西 就 会 “一 点 即 透 ”。 


图 10-1 描 述 了 WMS 的 一 个 设计 漫 想 ， 大 家 可 以 先 参 考 下 。 


Application- Window 


ActivityThread 


ActivityManager 
Service 


System 
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事件 派发 
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InputManagerService SurfaceF linger 





全 图 10-1 WindowManagerService 49 i 1% %8 


从 图 中 可 知 ， 要 实现 完整 的 窗口 管理 器 ， 所 涉及 的 元 素 最 少 应 包括 
LAR ILA. 


1. WindowManagerService(W MS) 


WMS 将 以 什么 样 的 形态 来 提供 服务 呢 ? 没 错 ， 和 AMS 等 Servi ce 一 
样 ，WMS 也 会 是 系统 级 服务 的 一 部 分 。 细 化 而 言 ， 它 应 该 具有 如 下 属 
性 。 


o 由 SystemServer 负 责 启动 


这 就 意味 着 WMS 的 启动 时 机 相对 较 晚 。 聪 明 的 读者 一 定 会 问 ， 那 么 
在 WMS 还 没有 运行 之 前 ， 终 端 显示 屏 上 难道 就 “一 团 黑 ”?” 当然 不 是 。 
因为 在 WMS 启动 前 系统 只 需要 显示 开机 画面 ， 而 它们 都 有 特殊 的 方式 来 
向 屏幕 输出 图 像 。 比 如 前 一 章 中 介绍 的 开机 动画 ， 就 是 由 
BootAnimation 直 接 通过 0penGL ES 与 SurfaceFlinger 的 配合 来 完成 的 。 
这 也 从 侧面 告诉 我 们 ， 要 想 在 Android 中 显示 U1 界面 ， 并 不 一 定 要 通过 
WMS 一 一 我 们 完全 可 以 模拟 BootAnimation 来 写 一 个 不 基于 WMS 的 Linux 应 
用 程序 ， 有 兴趣 的 读者 可 以 尝试 下 。 


。 直到 系统 关机 时 才能 退出 


这 很 容易 理解 一 一 如 果 “ 导 演 ” 都 不 在 了 ， 那 整 台 话 剧 自然 也 就 乱 
Ta 


。 发 生 异 常 时 必须 能 自动 重启 


是 软件 就 难免 有 Bug。 如 果 WMS 不 幸 发 生 了 异常 ， 后 果 将 非常 严重 。 
所 以 要 求 它 必须 具备 发 生 异 常 时 重启 的 功能 。 





2. SurfaceFlinger 


前 面 我 们 分 析 了 SurfaceFlinger 与 WMS 的 关系 ， 从 中 可 以 推测 出 两 
者 间 必 定 会 有 不 少 交 集 ， 后 续 小 节 会 有 详细 分 析 。 


3. 有 图 形 显 示 需 求 的 程序 


除了 常见 的 以 Activity 组 件 所 构成 的 应 用 程序 外 ，Android 系 统 自 
身 也 有 界面 显示 的 需求 。 可 想 而 知 ， 不 同类 型 的 用 户 所 创建 的 窗口 是 有 
优先 级 的 。 比 如 : 


e Application Window 


针对 普通 应 用 程序 的 显示 申请 所 产生 的 窗口 。 和 系统 窗口 相 比 ， 它 
们 的 窗口 “层级 值 ” 比 较 低 。 


e System Window 
比如 顶部 的 系统 状态 栏 、 壁 纸 等 都 属于 系统 窗口 。 
e Sub Window 


这 种 类 型 的 窗口 也 称 为 子 窗 口 ， 所 以 它 的 属性 很 大 程度 上 受 限 于 其 
父 窗 口 。 比 如 我 们 点 击 Menu 时 出 现 的 应 用 程序 菜单 ， 束 是 在 原来 窗口 的 
基础 上 弹出 来 的 。 


后 续 小 节 会 详细 描述 所 有 类 型 窗口 的 “层级 值 ”分 配 。 
4. InputManagerService(IMS) 


WMS 是 派发 系统 按键 和 触摸 消息 这 一 “重任 ”的 最 佳 “ 人 ” 选 。 当 
IMS 收 到 一 个 按键 或 者 触摸 事件 时 ， 它 需要 寻找 一 个 最 合适 的 “ 窗 
口 ”来 处 理 消息 ; 而 WMS 是 窗口 的 管理 者 ， 系 统 中 所 有 窗口 的 状态 和 信 
息 都 在 其 掌控 中 ， 完 成 这 一 工作 “不 在 话 下 ”。 


5. ActivityManagerService (AMS) 


AMS 和 WMS 之 间 也 有 交互 。AMS 是 管理 系统 中 所 有 Activity 的 “大 总 
管 ”， 而 Activity 状 态 的 变化 通常 会 带 来 “页面 ”上 的 改变 。 举 个 例 
子 ， 假 设 Activity1 局 动 了 Activity2， 那 么 体现 到 表面 上 的 变化 就 是 
Activity1 逐 步 淡出 〈 窗 口 动画 效果 ， 后 续 小 节 有 讲解 ) 显示 ， 而 后 


Activity2 描 述 的 U1 界面 占据 屏幕 。 


6. Binder 通 信 


无 论 是 SurfaceFlinger，AMS 或 者 应 用 进程 ， 它 们 与 WMS 间 都 需要 进 
行 Binder 通 音信 。 面 对 不 同 的 设计 需求 ，Binder 也 会 有 各 种 样式 上 的 变 
异 。 不 过 “万 变 不 离 其 宗 ”， 如 果 读 者 对 这 些 基 础 知识 还 不 清楚 ， 建 议 
先 回头 复习 一 下 进程 /线程 和 Binder 相 关 章 节 的 内 容 ， 然 后 再 来 看 WMS 中 
对 它们 的 应 用 。 


从 WindowManagerService 的 内 部 实现 来 讲 ， 它 需要 包含 如 下 子 功 


能 。 
o 窗口 的 添加 与 删除 


当 茶 个 进程 (Kite s ees ee ee 


Ja oh i a 


, Se Ta RON, ERER TARAMA “a 
， 后 续 小 节 有 详细 分 析 。 


。 窗口 动画 


当 窗口 则 切换 上 时， 采用 “窗口 动画 ”可 以 加 强 U1 特 效 ， 让 你 自 
看 起 来 更 “ 炫 ”。 窗 口 动 画 是 允许 定制 的 。 


。 窗口 大 小 
Android 系 统 支 持 显示 不 同 尺 寸 大 小 的 窗口 ， 如 StatusBar 就 只 是 屏 
幕 最 顶层 的 一 条 “Bar”; 类 似 的 还 有 对 话 框 、 悬 浮 窗 等 ， 这 些 窗口 的 
大 小 it 及 定 与 管理 都 需要 由 WWS 完 成 。 
e 窗口 层级 


即 Z-0rder， 在 SurfaceFlinger 中 我 们 已 经 看 到 了 Le ts 入 显示 
结果 的 影响 。 FistSurface Flinger 只 是 “摄像 机 ”， 它 负责 客观 地 拍 


D 
>| 


摄 当前 场景 ; 而 各 窗口 Z-0rder 的 调整 则 是 由 WMS 来 完成 的 。 
。 事件 派发 
事件 派发 也 是 WMS 一 个 必 不 可 少 的 功能 。 
10.1.1 WMS 的 启动 
我 们 说 过 ，WMS 属 于 SystemServer 启 动 众多 系统 服务 中 的 一 种 : 


/*frameworks/base/services/java/com/android/server/SystemServer , j 
public void run() { 


Slog.i(TAG, "Window Manager"); 
wm = WindowManagerService.main(context, power, display, inputM 
factoryTest != SystemServer .FACTORY_TEST_LOW_LEVEL, ! firs 
ServiceManager .addService(Context .WINDOW_SERVICE, wm); /*}E/ft2ils 
其 他 进程 可 以 利用 Context .WINDOW_SERVICE 即 “win 


它 提 供 了 一 个 静态 的 main 函 数 ， 真 正 的 创建 工作 是 在 这 里 面 实现 
的 。 中 体 源码 分 析 可 以 参见 术 书 a al ”章节 中 
的 “Thread 休 眠 和 唤醒 ”， 这 里 不 册 歼 述 


这 样 WMS 服 务 就 成 功 地 局 动 起 来 了 ， 而 且 其 他 进程 也 可 以 通过 向 
ServiceManager 查 询 “window” 来 获取 它 的 服务 。 接 下 来 的 小 节 我 们 会 
分 析 WMS 提 供 了 哪些 接口 功能 。 


10.1.2 WMS 的 基础 功能 


WMS 使 用 AI1DL 的 方式 来 摘 述 它 的 接口 。 关 于 使 用 AIDL 生 成 的 Binder 
Server 与 手工 Binder Server 的 区 别 ， 我 们 在 前 面 章节 已 经 详细 分 析 
过 ， 不 清楚 的 读者 可 以 回头 复习 一 人 下。 在 未 进行 编译 的 情况 下 ， 源 码 中 
只 能 找到 1WindowManager. aidl。 而 后 这 个 文件 会 被 A1DL 工 具 转 化 为 


|WindowManager. java: 


/*frameworks/base/core/java/android/view/IWindowManager .aid1l*/ 
interface IWindowManager 


IWindowSession openSession(in IInputMethodClient client, in I 
inputContext); /* 与 WMS 建 立 一 个 Session 连 接 :， 有 点 类 似 于 SurfaceFlinge 
boolean inputMethodClientHasFocus(IInputMethodClient client); 








void getInitialDisplaySize(int displayId, out Point size);/* fT 
void getBaseDisplaySize(int displayId, out Point size); 
void setForcedDisplaySize(int displayId, int width, int heigh 


boolean hasSystemNavBar(); 


void addWindowToken(IBinder token, int type);// 后 面 一 个 小 节 会 解 和 
void removeWindowToken(IBinder token); 
void addAppToken(int addPos, IApplicationToken token, 

int groupId, int requestedOrientation, boolean fullscre 


void prepareAppTransition(int transit, boolean alwaysKeepCurr 

int getPendingAppTransition(); 

void overridePendingAppTransition(String packageName, int ent 
IRemoteCallback startedCallback) ; 

void overridePendingAppTransitionScaleUp(int startX, int star 

startHeight ); 


void setAppStartingwWindow(IBinder token, String pkg, int them 
in CompatibilityInfo compatInfo, CharSequence nonLocali 
int icon, int windowFlags, IBinder transferFrom, boolea 
/* 启 动 窗口 */ 
void setAppWillBeHidden(IBinder token); 
void setAppVisibility(IBinder token, boolean visible) ;/* “4App: 
整 界 面 显示 


void updateRotation(boolean alwaysSendConfiguration, boolean f 


旋转 有 关 的 





int getRotation(); 
int watchRotation(IRotationWatcher watcher); 
void removeRotationwatcher(IRotationwatcher watcher); 


Bitmap screenshotApplications(IBinder appToken, int displayId 
maxHeight) ;/* 屏 幕 截图 */ 
void statusBarVisibilityChanged(int visibility);/*Status bari 





上 面 代码 段 节 选 了 WMS 提供 的 部 分 重要 接口 ， 以 此 让 大 家 有 个 直观 
的 印象 。 从 中 可 以 了 解 到 WMS 所 要 完成 的 “功能 ” 既 多 且 杂 一 一 比如 获 
得 显示 屏 的 尺寸 大 小 、 判 断 是 否 有 System Bar 、 是 否 有 Navi gat ion 
Bar 、 锁 定 屏 幕 、 截 取 屏 幕 等 。 


10.1.3 WMS 的 工作 方式 


WMS 是 Android 中 一 个 非常 重要 的 系统 服务 ， 内 部 实现 也 相对 复杂 。 
对 于 初学 者 来 说 可 能 会 找 不 到 “入 手 ” 的 地 方 ， 因 而 我 们 可 以 先 把 它 的 
工作 方式 作为 学 习 的 切入 点 ， 如 图 10-2 所 示 。 


WMS 的 工作 方式 在 几 个 Jelly Bean 版 本 中 〈4. 1 一 4. 3) 差异 还 是 比 
较 大 的 。4. 1 版 本 中 ， 当 SystemServer 调 用 WindowManagerService. main 
时 《仍然 是 运行 在 SystemServer 自己 的 线程 中 的 ) ， 它 会 创建 一 个 
WMThread 来 作为 WMS 独立 的 服务 线程 一 一 我 们 称 之 为 WMS 的 主线 程 。 当 主 
线程 成 功 运行 后 ，SystemServer 才 能 从 main 函 数 返 回 并 继续 做 其 他 操 
作 。 同 时 ，WMS 的 主线 程 则 进入 循环 中 ， 即 Looper。 


4. 1 版 本 以 后 的 WMS 工作 方式 逐步 发 生 了 改变 ， 其 中 最 显著 的 一 个 惑 
是 WMThread 不 复 存 在 ， 取 而 代 之 的 是 SystemServer 中 的 
wmHandlerThread。 这 样 的 设计 使 得 SystemServer 中 的 其 他 Servi ce 也 可 
以 往 wmHandlerThread 中 投递 事件 ， 从 而 便捷 地 获取 WMS 的 服务 。 另 外 ， 
WMS 中 接收 到 的 大 部 分 服务 请 求 都 是 由 跨 进 程 的 对 象 产生 的 〈 我 们 在 上 
图 中 把 它们 统一 命名 为 “调用 者 ”) ， 如 InputManagerService、 各 应 
用 进程 等 。 这 些 调用 者 通过 以 下 两 种 典型 的 方式 ， 源 源 不 断 地 将 外 部 用 
户 的 请 求 和 状态 反馈 给 WMS。 


。 事件 投递 


既然 WMS 有 自己 运行 的 主线 程 ， 那 么 通常 情况 下 外 再 的 请 求 或 者 事 
件 只 要 投递 到 这 个 线程 的 队列 中 即 可 。 具 体 而 言 ， 当 wmHand1erThread 
创建 一 个 WindowManagerService 对 象 时 ， 后 者 的 mH 成 员 变 量 将 与 
wmHand1lerThread 产 生 关 联 。 而 后 如 果 调 用 者 通过 1WindowManager 提 供 
的 接口 来 获取 服务 时 ， 就 可 以 利用 mH 来 把 消息 投递 到 wmHandlerThread 
所 属 的 消息 队列 中 。 这 就 是 事件 投递 的 方法 。 







WindowManagerService.main 





wmHandler 


全 图 10-2 WMS 工作 方式 简 图 


。 直接 调用 


我 们 在 进程 章节 讲述 Handler 和 MessageQueue 的 关系 时 ， 曾 举 过 一 
个 借 钱 的 例子 : 如 果 这 一 事件 〈 借 钱 ) 不 是 非常 着 急 的 话 ， 可 以 先 排队 
再 处 理 ; 反之 ， 如 果 是 刻不容缓 的 事件 ， 就 需要 当即 处 理 。WMS 同 样 也 
存在 这 样 的 工作 方式 一 一 不 过 要 特别 注意 ， 此 时 事件 的 处 理 过 程 仍然 运 


行 在 事件 产生 者 自己 的 线程 中 。 


比如 下 面 的 isKeyguardLocked 就 直接 调用 了 WMS 的 内 部 实现 ， 而 没 
有 先 将 事件 入 队 : 


public boolean isKeyguardLocked() { 
return mPolicy.isKeyguardLocked(); 
} 


另 一 个 接口 showStrictModeViolation 则 是 通过 事件 投递 的 方式 实 
现 的 : 


public void showStrictModeViolation(boolean on) { 
if (mHeadless) return; 
int pid = Binder.getCallingPid(); 
mH.sendMessage(mH.obtainMessage(H.SHOW_STRICT_MODE_VIOLAT 
} 


10.1.4 WMS，AMS 与 Activity 间 的 联系 


一 个 Activity 在 启动 过 程 中 ， 需 要 多 个 系统 服务 的 支持 一 一 而 其 中 
最 主要 的 就 是 AMS 和 WMS。 我 们 从 两 个 方面 来 考查 这 三 者 的 关系 。 


1. IPC 通 信 


Activity 运 行 在 应 用 程序 进程 中 ， 而 AMS 和 WMS 则 运行 在 系统 相关 进 
程 中 ， 它 们 之 间 的 通信 和 需要 Binder 的 支持 。 从 这 个 角度 来 看 ， 它 们 之 间 
的 关系 如 图 10-3 所 示 。 


Activity 与 AMS 的 进程 间 通 信 实 现 ， 我 们 在 
ActivityManagerService 章 节 有 详细 分 析 ， 这 里 不 表 歼 述 。 另 外 ， 因 为 
WMS 与 AMS 实 际 上 是 驻 留 在 同一 个 进程 中 的 (它们 都 由 SystemServer 启 
动 ) ， 所 以 理论 上 是 可 以 直接 进行 函数 调用 的 。 比 如 SystemServer 就 通 
过 ActivityManager Service. self). setWindowManager (wm) 来 将 
WindowManagerService. main 的 结果 传递 给 AMS; 而 WMS 虽然 是 通过 
ActivityManagerNative. getDefault () 来 取得 一 个 IActivityManager 对 
象 ， 但 根据 Binder 驱 动 的 实现 原理 ， 它 实际 上 得 到 的 也 是 AMS 对 象 的 内 
存 地 址 。 如 果 读 者 党 得 这 部 分 知识 还 不是 很 清楚 ， 建 议 回头 复习 下 
Binder 章 节 。 
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全 图 10-3 WMS、AMS 和 Activity 三 者 间 的 IPC 通 信 


应 用 程序 访问 WMS 的 服务 首先 当然 得 通过 ServiceManager， 因 为 WMS 


是 实名 Binder Server; 除 此 之 外 ，WMS 还 需要 针对 每 个 Act ivity 提 供 另 
一 种 匿名 的 实现 ， 即 IWindowSession 这 有 点 类 似 于 SurfaceF|inger 
中 的 Client。WMS 和 SurfaceFlinger 是 面向 系统 中 所 有 应 用 程序 服务 
的 ， 如 果 客 户 的 任何 “小 请 求 ” 都 需要 直接 通过 它们 来 处 理 ， 那 么 无 疑 
会 加 重 两 者 的 负担 ， 进 而 影响 到 系统 的 整体 响应 速度 。 所 以 WMS 通 过 
|WindowManager : :openSession() 辣 外 界 开放 一 个 打开 Session 的 接口 ， 
然后 客户 端的 一 些 “ 琐 碎 ” 杂 事 就 可 以 找 Session 解 决 了 。 比 如 
ViewRoot 在 构造 时 就 会 调用 这 个 了 洱 数 : 
/*frameworks/base/core/java/android/view/ViewRootIimpl.java*/ 


public ViewRootImpl(Context context) 4.. 
mWindowSession = WindowManagerGlobal.getWindowSession( ) ;//3k Ex 





/*frameworks/base/core/java/android/view/WindowManagerGlobal. java 
public static IWindowSession getWindowSession() { 
synchronized (WindowManagerGlobal.class) { 
if (sWindowSession == null) { 


try 4.. 
IWindowManager windowManager = getWindowManag 
sWindowSession = windowManager .openSession( 
imm.getClient(), imm.getInputContext( 


1Session 在 Server 端 的 实现 是 Session， 后 续 我 们 会 进行 更 详细 的 
讲解 。 

那么 ，WMS 如 何 访问 应 用 程序 呢 ? 

这 也 是 由 匿名 Binder 来 完成 的 。 在 应 用 程序 进程 中 ， 它 首先 通过 
openSession 来 建立 与 WMS 的 “私有 连接 ”。 紧 接着 它 会 调用 
IWindowSession: :relayout(IWindow window, ==") 这 个 函数 的 第 一 


个 参数 就 是 由 应 用 程序 提供 的 ， 用 于 WMS 回 访 应 用 进程 的 匿名 Binder 
Server。1Window 在 应 用 进程 中 的 实现 是 W 类 : 


static class W extends IWindow.Stub {... 





W 提 供 了 包括 resized,， dispatchAppVisibi lity, 
dispatchScreenState 在 内 的 一 系列 回调 接口 ， 用 于 WMS 实时 通知 应 用 进 
程 开 面 上 的 变化 《有 些 变化 并 不 是 应 用 进程 的 主动 意愿 ) 。 


2. 内 部 组 织 方式 

当 一 个 新 的 Activity 被 启动 时 (startActivity) ， 它 首先 需要 在 
AMS 中 注册 一 一 此 时 AMS 会 在 内 部 生成 一 个 ActivityRecord 来 记录 这 个 
Activity; 另外 因为 Activity 是 四 大 组 件 中 专门 用 于 UI 显 示 的 ， 所 以 
WMS 也 会 对 它 进 行 记 录 一 一 以 WindowState 来 表示 。 


所 以 从 服务 内 部 组 织 方式 的 角度 来 讲 ， 三 者 的 关系 如 图 10-4 所 示 。 


WMS 
App Window Token 









Activity 





ActivityRecord 


全 图 10-4 Activity 在 AMS 和 WMS 中 的 组 织 和 管理 


如 图 所 示 ，WMS 除 了 利用 WindowState 来 保存 一 个 “窗口 ”相关 的 信 


息 外 ， 还 使 用 AppWindowToken 来 对 应 AMS 中 的 一 个 ActivityRecord。 这 
a AREE 为 窗口 的 显示 与 管理 打下 了 坚实 的 基 
fili o 


10.2 窗口 属性 
10.2.1 窗口 类 型 与 层级 

Android 支 持 的 窗口 类 型 很 多 ， 不 过 我 们 可 以 将 它们 统一 划分 为 三 
大 类 ， 即 Application Window, System Window 和 Sub Window. BIAS 
个 种 类 下 还 细 分 为 若干 子 类 型 ， 且 都 在 Wi ndowManager. java 中 定义 ， 如 
下 所 示 。 
1. Application Window 

普通 应 用 程序 的 窗口 都 属于 这 一 类 ， 如 表 10-1 所 示 。 


表 10-1 Application Window 细 分 


FIRST_APPLICATION_WINDOW= | 应 用 程序 窗口 类 型 的 起 始 
1 值 








应 用 程序 窗口 类 型 的 基础 
TYPE BASE _ APPLICATION= 1 值 ， 其 他 窗口 类 型 以 此 为 








应 用 程序 的 启动 窗口 类 
型 。 它 不 能 由 应 用 程序 本 
身 使 用 ， 而 是 Android 系 统 
为 应 用 程序 启动 前 设计 的 
窗口 当真 正 的 应 用 窗 
口 启动 后 就 消失 了 








TYPE_APPLICATION_STARTING= 
3 


















LAST_APPLICATION_WINDOW= 


99 





2. Sub Window 


M “Sub Window” 的 字面 意思 可 以 了 解 到 ， 这 类 窗口 将 附着 在 其 他 
Window 中 ， 因 而 被 称 为 “ 子 窗口 ”。 有 具体 包括 如 下 子 类 型 ， 如 表 10-2 所 


小 。 


_  - 2 Sub Window 细 分 


FIRST_SUB_WINDOW= FIRST-SUB_WINDOW=I00 窗口 类 型 的 起 始 值 


TYPE_APPLICATION_PANEL= 应 用 程序 的 panel 子 窗口 . 
FIRST_SUB_WINDOW 的 父 窗口 之 上 显示 










TYPE APPLICATION_ MEDIA= 用 于 显示 多 媒体 内 容 的 - 
FIRST SUB WINDOW+1 口 ， 位 于 父 窗口 之 下 





也 是 一 种 panel 子 窗口 ， 
TYPE_APPLICATION_SUB_PANEL= 窗口 以 及 所 有 

FIRST_ SUB_WINDOW+2 TYPE APPLICATION I 
FRBAZE 


TYPE APPLICATION_ATTACHED_DIALOG= Dialog 子 窗口 ， 如 menuz 


FIRST_SUB_WINDOW+3 





多 媒体 窗口 的 覆盖 层 ，{1 
TYPE_APPLICATION_1 
和 应 用 程序 窗口 之 间 ，i 
要 是 透明 的 才 有 意义 。| 
类 型 处 于 未 开放 状态 







TYPE APPLICATION_MEDIA_OVERLAY= 
FIRST_SUB_WINDOW+4 





LAST_SUB_WINDOW2= 1999 


3. System Window 


系统 程序 所 采用 的 窗口 类 型 ， 细 分 如 表 10-3 所 示 。 


表 10-3 System Window 细 分 


FIRST_SYSTEM_ WINDOW = 2000; 系统 窗口 的 起 始 值 


TYPE STATUS_BAR = 


统 状 太 栏 窗 
FIRST_SYSTEM_WINDOW; 系统 状态 位 窗口 


TYPE_SEARCH_BAR = 
FIRST_SYSTEM_WINDOW+1; 搜索 条 窗口 


通话 窗口 ， 特 别 是 来 电 通 
TYPE _ PHONE= 话 。 通 常情 况 下 它 位 于 系统 
FIRST_SYSTEM_ WINDOW+2: 状态 栏 之 下 ， 其 他 应 用 程序 
窗口 之 上 





窗 量 N y FI 
TYPE_SYSTEM_ALERT = Alert 窗 口 ， 如 电量 不 足 的 党 


| 


FIRST_SYSTEM_WINDOW+?3; 告 窗口 。 通 常 都 位 于 所 有 其 
他 应 用 程序 之 上 


TYPE KEYGUARD = 
FIRST_SYSTEM_WINDOW+4; 


TYPE_TOAST = ere ene 
FIRST_SYSTEM_WINDOW+5; 短暂 的 提示 框 窗口 


系统 窗 盖 层 窗口 ， 这 种 类 型 
的 窗口 不 能 接收 input 焦 反 ， 
否则 会 与 屏保 发 生 冲突 


TYPE SYSTEM OVERLAY = 
FIRST_SYSTEM_WINDOW+6; 


TYPE PRIORITY PHONE = 电话 优先 窗口 ， 如 屏保 状态 
FIRST_SYSTEM_WINDOW+7; 下 显示 来 电 窗 口 





TYPE_SYSTEM_DIALOG = 比如 RecentAppsDialog 就 是 这 
FIRST_SYSTEM_ WINDOW+8: 种 类 型 的 窗口 


TYPE_KEYGUARD_DIALOG = eee 
FIRST_SYSTEM_WINDOW+9; 屏保 时 显示 的 对 话 框 


TYPE_SYSTEM ERROR = 
FIRST_SYSTEM WINDOW+10; 


TYPE_INPUT_METHOD = 
FIRST_SYSTEM_WINDOW+11; 





TYPE _INPUT_METHOD_DIALOG = 
FIRST_SYSTEM_WINDOW+12; 








输入 法 窗口 之 上 的 对 话 框 式 
窗口 


TYPE WALLPAPER = 
FIRST_SYSTEM_WINDOW+13; 


TYPE_STATUS_BAR_PANEL = eer er eee 
FIRST_SYSTEM_WINDOW+14; 滑动 状态 栏 出 现 的 窗口 


TYPE_SECURE_SYSTEM_OVERLAY= 
FIRST_SYSTEM_WINDOW+15; 
TYPE_DRAG= 
FIRST_SYSTEM_WINDOW+16; 
TYPE_STATUS_BAR_SUB_PANEL= 
FIRST_SYSTEM_WINDOW+17; 
TYPE_POINTER= 
FIRST_SYSTEM_WINDOW+18; 

3 种 类 型 


TYPE_NAVIGATION_BAR = 导航 条 ， 可 以 参见 本 书 应 用 
FIRST_SYSTEM_WINDOW+19; 篇 的 System UI 章节 


TYPE VOLUME_OVERLAY = 
FIRST_SYSTEM_WINDOW+220; 


TYPE_BOOT_PROGRESS = Per 
FIRST_SYSTEM_WINDOW?21; 启动 时 的 进度 条 窗口 


当 导 航 条 隐藏 时 用 于 消耗 触 
摸 事件 的 伪 窗 口 


TYPE HIDDEN_NAV_CONSUMER = 
FIRST_SYSTEM_WINDOW?22; 












TYPE DREAM= 
FIRST_SYSTEM_WINDOW?223; 
TYPE NAVIGATION_BAR_PANEL= 
FIRST_SYSTEM_WINDOW+24; 


TYPE_UNIVERSE_ BACKGROUND = | 在 多 用 户 系 统 中 ， 将 显示 给 
FIRST_SYSTEM_WINDOW3225; 所 有 用 户 


TYPE_DISPLAY_OVERLAY = Oe ee 
FIRST_SYSTEM_WINDOW+26; 用 于 模拟 第 二 个 显示 设备 


有 点 类 似 于 “放大 镜 ” 的 效 
TYPE_MAGNIFICATION_OVERLAY = 
时 果 ， 用 于 放大 显示 某 部 分 内 


FIRST_SYSTEM_WINDOW+?+27; 容 


与 TYPE SYSTEM _DIALOG 
TYPE_RECENTS_OVERLAY = 基本 一 致 ， 区 别 是 
FIRST_SYSTEM_WINDOW+28; TYPE_RECENTS_OVERLAY 

只 显示 在 一 个 用 户 的 屏幕 上 


LAST_SYSTEM_WINDOW = 2999: 系统 窗口 结束 


每 种 子 类 型 后 面 都 有 一 个 数值 ， 代 表 了 它 的 窗口 类 型 值 。 比 如 
TYPE STATUS_BAR= FIRST SYSTEM WINDOW=2000。 三 大 窗口 类 型 的 间隔 


Be. 
Æ: 





Application Window: 1-99 
Sub Window: 1000-1999 
System Window: 2000-2999 


当 某 个 进程 向 WMS 申 请 一 个 窗口 时 ， 它 需要 指定 所 需 的 窗口 类 型 


CER: 除 个 别 特殊 情况 外 应 用 程序 是 不 能 创建 系统 窗口 的 ， 因 为 系统 
会 做 权限 检查 ) 。 然 后 WMS 根据 用 户 申 请 的 窗口 类 型 以 及 当前 系统 中 已 
有 窗口 的 情况 来 给 它 分 配 一 个 最 终 的 “层级 值 ” 这 是 根据 窗口 类 型 值 
计算 出 来 的 ， 后 续 有 详细 说 明 〉。 


系统 在 运行 期 间 ， 很 可 能 会 有 多 个 窗口 属于 同一 种 窗口 类 型 。 比 如 
当前 有 3 个 应 用 程序 在 执行 ， 那 么 类 型 为 TYPE_APPLICATION 的 应 用 程序 
窗口 至 少 就 会 有 3 个 。 因 而 WMS 需要 根据 具体 情况 来 调整 它们 的 最 终 “ 层 
级 值 ”。 数 值 越 大 的 窗口 ， 其 在 WMS 中 的 优先 级 越 高 ， 最 终 在 屏幕 上 显 
示 时 就 越 靠 近 用 户 。 我 们 来 看 看 具体 的 分 配 规则 : 


/*frameworks/base/services/java/com/android/server/wm/WindowManag 
private final void assignLayersLocked(WindowList windows) { 
int N = windows.size(); // 当 前 系统 中 所 有 窗口 的 个 数 
int curBaseLayer = 0;// 根 据 上 面 所 说 的 “窗口 类 型 值 ”计算 出 来 的 ， 后 1 
int curLayer = 0;// 层 值 
int 1; 





for (i=0; i<N; i++) { 
final WindowState w = mWindows.get(1); 
final WindowStateAnimator winAnimator = w.mWinAnimato 
boolean layerChanged = false; 
int oldLayer = w.mLayer; 


if (w.mBaseLayer == curBaseLayer || w.mIsImWindow 
|| (i > 0 && w.mIsWallpaper)) {/* 这 个 窗口 的 “基础 ) 
不 是 一 样 的 */ 


curLayer += WINDOW_LAYER_MULTIPLIER;/* 同 一 “基础 层级 ” 
w.mLayer = CUrLayer ， 

} else {/* 窗 口 的 “基础 层级 ” 值 变 了 */ 
curBaseLayer = curLayer = w.mBaseLayer;/*curBaseLa 
w.mLayer = CUrLayer ， 


if (w.mLayer != oldLayer) { 
layerChanged = true; 
anyLayerChanged = true; 


J 
} 


这 个 函数 的 计算 前 提 是 windows 里 的 所 有 窗口 都 是 按照 mBaseLayer 
有 序 排列 的 。 当 for 循 环 第 一 次 执行 时 ， 因 为 
curBaseLayer=curLayer=0， 所 以 w. mBaseLayer 不 等 于 curBaseLayer， 
从 而 curBaseLayer=curLayer=w. mBaseLayer 。 而 下 一 轮 循 环 中 ， 取 决 于 


该 WindowState 的 mBaseLayer 。 如 果 它 和 上 次 相同 ， 就 证 明 是 同一 种 类 
型 的 窗口 ， 因 而 只 要 curLayer+=WINDOW LAYER_MULTIPLIER 〈 值 为 5。 窗 
口 间 的 间隔 设 为 5， 而 不 是 1， 是 为 后 期 可 能 有 的 effect surface 做 准 
备 ) 即 可 ， 也 就 是 在 原来 Layer 值 的 基础 上 加 上 5; 如 果 不 相 同 的 话 ， 说 
明 又 是 另 一 种 类 型 。 因 而 当前 curBaseLayer 的 值 就 是 w. mBaseLayer， 而 
HcurBaseLayer=curLayer=w. mBaseLayer 如 此 循环 往复 ， 直 到 处 理 
完 windows 中 的 所 有 窗口 。 


那么 mBaseLayer 是 什么 ， 它 和 前 面 所 说 的 “窗口 类 型 值 ” 有 什么 关 
EX? 因为 nBaseLayer 是 WindowState 的 成 员 变 量 ， 我 们 从 它 的 构造 子 数 
AF: 


/*frameworks/base/services/java/com/android/server/wm/windowState 
WindowState(..WindowManager.LayoutParams a, 
if ((mAttrs.type >= FIRST_SUB_WINDOW &&mAttrs. type <= LAST_SU 
mBaseLayer = mPolicy.windowTypeToLayerLw(attachedwindow.m 
WindowManagerService.  TYPE_LAYER_MULTIPLIER+ WindowManagerServic 
mSubLayer = mPolicy.subWindowTypeToLayerLw(a.type); 





} else { 
mBaseLayer = mPolicy.windowTypeToLayerLw(a. type) 
* WindowManagerService.TYPE_LAYER_MULTIPLIER 
+ WindowManagerService.TYPE_LAYER_OFFSET; 
mSubLayer = 0; 


由 上 述 代 码 段 可 知 ， 所 有 类 型 窗口 的 BaseLayer 值 都 可 以 由 以 下 几 
步 取得 。 


Step1. windowTypeToLayerLw， 该 函数 针对 不 同 的 窗口 类 型 做 了 简 
单 的 上 映射。 具体 的 映射 规则 取决 于 该 设备 所 采用 的 
WindowManagerPolicy。 比 如 ，PhoneWindowManager 中 的 映射 如 表 10-4 
所 示 。 


表 10-4 windowTypeToLayerLw 对 照 表 (PhoneWindowManager ) 





WINDOW TYPE LAYER 


~ 


[FIRST_APPLICATION_WINDOW,  |LAST_APPLICATION_WINDOW 
LAST_APPLICATION_WINDOW] 


TYPE WALLPAPER WALLPAPER LAYER 


SEARCH BAR LAYER 
TYPE SYSTEM_DIALOG SYSTEM_DIALOG_LAYER 
PRIORITY_PHONE_LAYER 


TYPE SYSTEM ALERT SYSTEM_ALERT_LAYER 








TYPE _INPUT_METHOD INPUT_METHOD_LAYER 


TYPE INPUT_METHOD_DIALOG INPUT_METHOD_DIALOG_LA* 


TYPE KEYGUARD KEYGUARD_LAYER 


TYPE KEYGUARD DIALOG KEYGUARD_DIALOG_LAYER 


es ee 





imei We 
TYPE STATUS BAR SUB PANEL |ISTATUS_BAR SUB_ PANEL LA 


TYPE_STATUS_BAR STATUS_BAR LAYER 
TYPE STATUS BAR PANEL STATUS_BAR PANEL LAYER 
TYPE VOLUME_OVERLAY VOLUME_OVERLAY LAYER 


TYPE SYSTEM OVERLAY SYSTEM OVERLAY LAYER 














TYPE NAVIGATION_BAR NAVIGATION_BAR_ LAYER 
TYPE NAVIGATION_BAR_ PANEL |INAVIGATION BAR PANEL LZ 
TYPE _ PYPE.SYSTEM ERROR oo ERROR SYSTEM_ERROR_LAYER 
TYPE pYPE DRAG DRAG_LAYER 


TYPE _ TYPE, SECURE. SYSTEM. OVERLAY SYSTEM _OVERLAY|SECURE SYSTEM OVERLAY . 


TYPE BOOT_PROGRESS BOOT_PROGRESS_LAYER 
hyve. pomreR Pronvren Laver 


L 


| | 
TYPE_HIDDEN_NAV_CONSUMER open NAv consumer 1 


对 于 Sub Window 而 言 ， 窗 口 类 型 取决 于 其 父 窗口 的 类 型 。 


Step2， 上 一 步 所 得 的 “映射 值 ” 需 要 乘 以 
TYPE_LAYER_MULTIPLIER(10000) 。 这 是 因为 系统 运行 过 程 中 很 可 能 出 现 
同 种 类 型 的 多 个 窗口 ， 所 以 应 该 有 一 个 足够 大 的 间隔 来 供 分 配 。 


Step3， 最 后 ， 还 要 加 上 偏 移 值 TYPE_LAYER_0FFSET (1000) 。 根 据 代 
码 注释 ， 这 个 偏 移 值 是 为 了 移动 同一 层级 的 一 整 组 窗口 而 设计 的 。 


Step4.， 对 于 子 窗口 类 型 而 言 ， 还 要 特别 计算 mSubLayer 值 。 子 窗口 
与 父 窗 口 有 着 紧密 的 联系 ， 因 而 mSubLayer 其 实 是 用 于 决定 这 个 子 窗口 
应 该 “ 偏 移 ” 父 窗口 的 数值 大 小 。 比 如 TYPE_APPLICAT1ION_PANEL 和 
TYPE_APPL1CATION_ATTACHED_D1AL0G 类 型 的 子 窗口 对 应 的 mSubLayer 都 
是 APPLI1CATION PANEL SUBLAYER=1; 而 TYPE_APPL1CATION_MED1A 类 型 
的 子 窗口 对 应 的 mSubLayer 则 是 APPLI1CATION MEDIA _SUBLAYER=-2。 子 窗 
口 在 显示 时 既 有 可 能 在 父 窗 口 之 上 ， 也 有 可 能 在 其 之 下 。 


10.2.2 窗口 策略 (Window Pol icy) 


前 一 小 节 计 算 windowTypeToLayerLw 时 ， 我 们 曾 提 到 
WindowManagerPol icy. 


那么 ， 什 么 是 Window Policy? 从 字面 来 理解 ， 它 是 “窗口 的 策略 / 
Bet” 。 应 用 到 WMS 中 ， 则 代表 了 Android 显 示 系 统 所 遵循 的 统一 的 窗口 
显示 规则 。 针 对 不 同 的 产品 ， 策 略 通常 是 不 一 样 的 。 


举 个 例子 ， 大 部 分 手机 设备 有 Status Bar; 而 平板 电脑 虽然 没 
Status Bar， 但 有 Comb ined Bar 。 这 些 “再 面 特征 ”构成 了 一 款 特 定 产 
east AU 属性， 因而 有 必要 做 统一 的 控制 一 一 这 就 是 Window Pol icy 
的 作用 。 


Android 系 统 从 设计 之 初 就 不 是 只 面向 单一 类 型 产品 的 。 只 不 过 它 
的 某 些 行为 天 生 的 更 接近 于 某 种 产品 而 已 ， 如 Phone 或 者 Tab let。 换 名 
话说 ， 各 开发 商 完 全 可 以 依据 具体 的 设备 需求 来 定制 出 符合 自己 产品 特 


性 的 Window Policy. 
Android 源 码 实现 中 ， 与 Window Policy 相 关 的 类 主要 有 4 个 ， 即 


WindowManagerPol icy, PhoneWindowManager, Pol icyManager #l 
Policy。 个 人 感觉 这 些 类 的 命名 并 不 是 很 合理 ， 容 易 造 成 误解 。 先 来 看 
PolicyManager 中 提供 的 如 下 两 个 函数。 


e makeNewWindow 


产生 一 个 Window。“ 窗 口 ” 是 一 个 抽象 的 概念 ， 它 表示 一 个 Ul 显示 
的 管理 单元 。 当 前 系统 中 默认 情况 下 产生 的 是 一 个 PhoneWindow， 也 就 
是 针对 手机 设备 的 窗口 。 





e makeNewWindowManager 


这 个 接口 应 该 叫 作 makeNewWindowManagerPolicy， 它 产生 一 个 管理 
Window 的 Policy， 如 图 10-5 所 示 。 


WindowManagerPolicy 


+gelnitialDisplaySize() 
+checkAddPermissiont ) 
+adjustWindowParamsL w() 
+windowTypeToLayerLw() 
+subWindowTypeToLayerLw() 
thasSystemNavBar() 
toetSystemDecorRestLw() 
+ayoutWindowl wọ) 
+ge(ContentInselHint w() 
+finshLayoutLw()} 


[Policy 

















+makeNewWindow() +makeNewWindow() 

+makeNewl ayoutlnflater() +makeNewl ayoutlnflater() 
+makeNewWindowManager() +makeNewWindowManager() 
+makeNewFallbackEventHandler(} +nakeNewFallbackEventHandler(} 


Phone WindowManager 










I 
N 





Coo 
[= 








全 图 10-5 ”Policy 继承 关系 


WindowManagerPolicy 是 窗口 管理 策略 的 接口 类 ， 它 定义 了 一 个 窗 

策略 所 要 遵循 的 通用 规范 以 及 需要 提供 的 相关 接口 ， 如 
aes InsetHintLw，hasSystemNavBar 等 。 因 为 系统 可 能 同时 支持 
多 种 产品 类 别 ， 我 们 有 必要 在 运行 中 指定 具体 采用 的 窗口 和 窗口 管理 策 
略 ， 这 个 工作 由 Pol icy. java 来 完成 。 这 个 类 可 以 看 作 Pol icy 的 生产 
者 ， 它 的 接口 类 是 1Policy。 不 过 通常 我 们 并 不 直接 产生 一 个 Pol icy 对 
象 ， 而 是 利用 PolicyManager 所 提供 的 静态 接口 来 产生 ， 如 
WindowManagerService 中 的 实现 : 


WindowManagerPolicy mPolicy = PolicyManager .makeNewWindowManager ( 


而 在 Pol icyManager. java: 


static { 
// Pull in the actual implementation of the policy at run 


try { 
Class policyClass = Class.forName(POLICY_IMPL_CLASS_N. 
sPolicy = (IPolicy)policyClass.newInstance(); 

} catch (ClassNotFoundException ex) { 


public static WindowManagerPolicy makeNewWindowManager() { 
return sPolicy.makeNewWindowManager (); 

} 

POLICY_IMPL_CLASS_NAME="com.android.internal.policy.impl.Poli 

因而 Pol icyManager 只 是 单纯 地 生成 了 一 个 Pol icy 对 象 ， 然 后 通过 


它 的 makeNewWindow Manager 来 进一步 产生 一 个 具体 的 
略 ”。 在 Android4. 3 中 ， 默 认 的 策略 如 下 所 示 : 


/*frameworks/base/policy/src/com/android/internal/policy/impl/Pol 
public Window makeNewWindow(Context context) { 
return new PhoneWindow(context); 


public WindowManagerPolicy makeNewWindowManager() { 
return new PhoneWindowManager (); 


也 就 是 我 们 前 面 提 到 的 ， 黑 认 情 况 下 系统 采用 的 是 “Phone” 这 一 


产品 的 窗口 和 窗口 管理 策略 。 其 中 “PhoneWindowManager” 这 个 名 称 也 
很 容易 误导 人 ， 如 果 改 为 “PhoneWindowManagerPolicy” 或 许 更 能 让 人 
朗 受 。 关 于 Window 和 WindowManagerPolicy 中 各 接口 方法 的 具体 实现 ， 
我 们 接 下 来 会 再 做 详细 分 析 。 


10. 2.3 ”窗口 属性 (LayoutParams) 

除了 WindowType 外 ，WMS 中 还 牵涉 到 很 多 其 他 的 窗口 属性 。 开 发 者 
可 以 通过 设置 不 同 的 属性 来 使 U1 额 面 显 示 出 各 种 样式 一 一 它们 就 像 窗 口 
用 户 与 WMS 间 的 协议 一 样 ，WMS 就 是 为 了 实现 这 些 用 户 需 求 而 努力 的 。 另 
外 ， 了 解 这 些 属 性 的 含义 也 能 帮助 我 们 更 好 地 理解 WMS 的 内 部 原理 。 


这 些 属性 统一 放置 在 Wi ndowManager. LayoutParams 中 ， 接 下 来 我 们 
分 析 其 中 几 个 重要 的 变量 。 


1. Type 
tie OA, TAAR. 


2. Flags 


窗口 的 标志 ， 默 认 值 是 9。 目 前 Android 4. 3 系统 上 支持 的 flag 标 志 
以 及 含义 如 表 10-5 所 示 。 





只 要 此 窗口 可 见 ， 即 便 朋 


FLAG_ALLOW_LOCK_WHILE_SCREEN_ON 
一 - 一 于 开局 状态 也 允许 锁 屏 


FLAG_DIM_ BEHIND Ei 口 后 面 的 所 有 东西 者 
Hive (dimmed) 





此 窗口 不 获得 输入 焦点 ， 

着 事件 将 发 给 该 窗口 后 再 
FLAG NOT FOCUSABLE 他 窗口 。 在 设置 了 此 标 二 

时 9 

FLAG NOT TOUCH Mí 

也 会 被 同时 设置 








和 上 面 的 标志 类 似 ， 它 未 
窗口 不 接受 任何 触摸 事 人 


FLAG_NOT_TOUCHABLE 


The NRO. tata 

在 该 窗口 区 域外 的 pointel 

FLAG _ NOT TIOUCH MODAL ie 
= “a 将 传 给 它 后 面 其 他 窗口 ， 


是 由 它 自 己 来 处 理 这 些 鞋 











当 设 备 进 入 睡眠 状态 时 ， 
此 标志 可 以 使 你 获得 第 一 
触摸 事件 《因为 这 时 候 禾 
不 知道 他 们 点 击 的 是 屏 帝 
哪个 位 置 ， 所 以 通常 这 一 
是 由 系统 目 动 处 理 的 ) 


FLAG_TOUCHABLE WHEN_WAKING 





FLAG_KEEP_SCREEN_ON REPROD, RR 
E 7 j 着 








窗口 显示 时 不 考虑 系统 汰 
(比如 Status Bar) 


FLAG LAYOUT NO LIMITS 允许 窗口 超过 屏幕 区 域 
[| | 


m 


FLAG_LAYOUT_IN_SCREEN 





隐藏 所 有 的 屏幕 装饰 窗 上 
Status Bar。 这 对 于 视频 提 

FLAG FULLSCREEN a y 
= ZEA DY A BE ALR A H 





FLAG FORCE NOT FULLSCREEN a 标志 相反 


窗口 内 容 被 认为 是 保密 尼 
FLAG SECURE 而 它 不 会 出 现在 截屏 中 ， 
FLAG SCALED 


会 在 不 安全 的 屏幕 上 显 万 
FLAG_IGNORE_CHEEK_PRESSES 


FRR A Se RS B BBA 
伸缩 调整 





有 的 时 候 用 户 和 屏幕 会 见 
近 ， 如 打 电 话 时 。 这 种 悍 
出 现 的 茶 些 事件 有 可 能 是 
意 ” 的 ， 不 应 该 啊 应 








只 能 和 

FLAG_LAYOUT_IN_SCI 
一 起 使 用 。 当 设置 了 “全 | 
示 ” 布 局 时 ， 应 用 窗口 部 
容 仍 然 可 能 会 被 系统 装饰 
oti. WRANKE Se 
T RAKENDA ER N 
所 占 的 区 域 ， 以 防止 上 过 


FLAG SHOW _ WHEN LOCKED 使 窗口 能 在 锁 屏 窗口 之 上 


一 一 一 一 





FLAG_ LAYOUT_INSET_DECOR 








让 壁纸 在 这 个 窗口 之 后 量 
换 句 话说 ， 当 窗口 是 透 丰 
透明 时 就 可 以 看 到 后 面世 


背景 (如 Launcher) 


FLAG_SHOW_WALLPAPER 


FLAG_TURN_SCREEN_ON 
BC EE IK Pi at FY DA PE 


FLAG DISMISS KEYGUARD 锁 ， 只 要 它 不 是 一 个 secu 
lock 
















指明 窗口 是 否 需要 硬件 加 
当然 ， 设 置 了 这 一 标志 并 
FLAG_HARDWARE_ACCELERATED 保证 窗口 一 定 会 得 到 硬 伯 
取决 于 设备 配置 等 一 敌 
系 ) 





可 以 通过 以 下 方法 来 设置 一 个 窗口 标志 : 


Window w = activity.getWindow(); 
w.setFlags(WindowManager .LayoutParams .FLAG_HARDWARE_ACCELERATED, 
WindowManager .LayoutParams.FLAG_HARDWARE_ACCELERATED ) 


3. systemUi1Visibility 


从 名 称 可 以 看 出 ， 这 个 变量 表示 的 是 系统 U1 的 可 见 性 。 如 果 读 者 不 
清楚 哪些 元 素 属于 “系统 U1”， 建 议 先 参 考 阅 读本 书 应 用 篇 中 的 介绍 。 


要 特别 注意 的 是 ，SystemUiVisibility 的 可 选 Flags 值 定义 在 View 
类 中 ， 而 不 是 WindowManager， 具 体 如 表 10-6 所 示 。 


表 10-6 SystemUiVisibility 部 分 标志 释义 


| = | 


SYSTEM UI FLAG VISIBLE View 视 图 请 求 显 刁 


View ta KIA “lov 
Status Bar/Navigati 
常 游戏、 电子 书 席 
需求 


SYSTEM_UI FLAG LOW_PROFILE 


这 个 标志 用 于 请 求 
参见 本 书 应 用 篇 
SYSTEM_UI FLAG HIDE NAVIGATION 标志 经 党 与 FLAG 
FLAG LAYOUT_ 
才能 使 应 用 程序 赃 


整个 View 将 进入 4 
WindowManager.L 
FLAG_FULLSCRI 
不 过 和 Window 提 1 
用 
Window.FEATUR: 
HJActionBar, Sysi 
它 隐藏 。 根 据 经 驶 
求 ， 可 以 采用 
SYSTEM_UI_FLA 
Fe TRAY Te] AY A BF Sn 
Be if (5 Fy Window! 


SYSTEM_UI_FLAG_ FULLSCREEN 





BLAST pa Bf 
SYSTEM_UL FLA 


sySTEM UL FLAG. LAYOUT mpe NAVIGATION} 上 面 标志 的 意义 


SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN 





L | 
SYSTEM UI FLAG LAYOUT STABLE 5 统 将 尽量 保持 U 





由 前 面 的 分 析 可 知 ， 我 们 只 能 对 一 个 View 而 不 是 Window) 设置 它 
的 systemUiVisibility。 如 果 你 希望 某 个 Activity 中 的 整 棵 View 树 都 使 
用 同一 个 systemUiVisibility， 可 以 在 Activity 的 onCreate 中 加 入 类 似 
于 如 下 的 代码 段 〈 在 调用 setContentView 前 ): 


int newVis = View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN 
| View.SYSTEM_UI_FLAG LAYOUT_HIDE_NAVIGATION 
| View.SYSTEM_UI_FLAG LAYOUT_STABLE; 


默认 情况 下 ， 系 统 是 从 StatusBar 下 面 的 部 分 开始 给 应 用 程序 做 U1 
布局 的 。 而 上 述 这 段 代 码 的 目的 就 是 使 Activity 以 整个 屏幕 来 布局 一 一 
最 为 关键 的 是 ， 同 时 还 要 显示 StatusBar 。 显 然 FLAG_FULLSCREEN 不 能 符 
合 这 个 需求 《因为 它 会 隐藏 系统 的 装饰 部 分 ， 包 括 StatusBar) ; 而 
SYSTEM_U1_FLAG_LAYOUT_FULLSCREEN 这 个 标志 会 保留 包括 StatusBar 在 
内 的 系统 窗口 ， 同 时 会 让 View 全 屏 显 示 。 换 句 话 说， 你 的 View 珊 面 布局 
是 从 屏幕 的 〈0, 0) 坐标 开始 的 ， 但 屏幕 上 方 的 一 小 部 分 内 容 会 被 
StatusBar PME Æ., 


那么 ， 在 什么 场景 下 我 们 需要 做 这 样 的 处 理 呢 ? 


举 个 例子 ， 现 在 很 多 定制 手机 的 StatusBar 是 透明 的 。 如 果 应 用 程 
序 按照 正常 的 做 法 从 StatusBar 以 下 的 位 置 开始 布局 ， 那 么 用 户 透 过 
StatusBar 看 到 的 “画面 ”就 是 “ 黑 的 ”; 而 如 果 从 (0,0) 位 置 开 始 布 
局 ， 那 么 用 户 就 可 以 透 过 StatusBar 看 到 应 用 程序 的 部 分 “View” 内 容 
了 。 另 外 ， 有 的 应 用 程序 需要 频繁 地 在 “显示 系统 装饰 窗口 ”和 “隐藏 
系统 装饰 窗口 ” 间 切 换 ， 为 了 让 这 两 种 情况 下 View 本 身 的 布局 保持 不 
变 ， 也 可 以 使 用 这 一 标志 。 


10. 3 A Q 的 添加 过 程 


10.3.1 系统 窗口 的 添加 过 程 


oe “窗口 ”类 型 虽然 很 多 ， 但 只 Ane Em 
用 的 : 其 一 是 由 系统 进程 管理 的 ， 称 之 为 a 统 窗口 ”; 其 二 就 是 应 用 
程序 放生 的 a “应 用 窗口 ”。 接 下 来 的 两 个 小 节 中 ， 
我 们 将 分 别 介绍 这 两 类 窗口 的 添加 过 程 ; 并 通过 这 两 条 线索 ， 把 其 中 涉 
Ray RSA BINGE, 


本 书 应 用 篇 的 SystemU1 章 节 ， 读 者 将 看 到 StatusBar 是 通过 WMS 的 
addView 方 法 最 终 将 自己 添加 到 屏幕 上 进行 显示 的 。 这 一 步 表面 上 显得 
平淡 无 奇 ， 但 其 内 部 实现 还 是 比较 复杂 的 。 本 小 节 我 们 融 以 此 为 入 口 点 
来 讲解 系统 窗 口 的 添加 流程 : 


/*frameworks/base/packages/systemui/src/com/android/systemui/stat 
private void addStatusBarWindow() { 
final int height = getStatusBarHeight();/* 先 获得 状态 栏 的 高 度 。1 
栏 的 默认 高 度 ， 可 以 关注 下 
final WindowManager.LayoutParams lp = new WindowManager .Lay 
ViewGroup.LayoutParams .MATCH_PARENT, // ‘ii 
height, WindowManager.LayoutParams.TYPE_STATUS_BAR, 
WindowManager .LayoutParams.FLAG_NOT_FOCUSABLE 
|WindowManager .LayoutParams.FLAG_TOUCHABLE_WHEN_WAKING 
|WindowManager .LayoutParams.FLAG_SPLIT_TOUCH, 
PixelFormat .TRANSLUCENT);/*LayoutParams 中 的 各 参数 我 们 1 








lp.flags |= WindowManager ,LayoutParams .FLAG HARDWARE_ACCE 

lp.gravity = getStatusBarGravity( ); 

lp.setTitle("StatusBar"); 

lp.packageName = mContext.getPackageName(); 

makeStatusBarView( );/* 准 备 mStatusBarwindow， 这 个 函数 会 先 通过 i 
R.,layout ,super_status_bar 来 产生 一 个 View 对 象 ， 

mwindowManager .addView(mStatusBarwindow，1p);// 将 StatusBai 


} 


上 面 的 代码 段 是 将 StatusBar 显 示 到 终端 屏幕 上 最 关键 的 部 分 。 逊 
ed nab dn ind et ta Hal Ber 站 的 
WindowManager. LayoutParams 属 性 值 ， 包 括 Width，Height， 
WindowType，Gravity，Title，PackageName 以 及 各 种 其 他 标志 。 我 们 
已 经 在 前 面 小 节 详 细 讲 解 过 这 些 属性 值 的 定义 ， 此 处 不 再 玲 述 。 


接着 程序 调用 如 下 语句 将 自己 添加 到 WMS 中 : 


mwindowManager .addView(mStatusBarWindow, lp); 


也 就 是 说 ， 上 面 的 这 些 属性 值 描 述 的 是 
mStatusBarWindow (StatusBarWindowView) 这 个 对 象 。 
StatusBarWindowView 类 本 质 上 是 一 个 FrameLayout 〈 所 以 也 是 一 个 Vi ew 
组 件 ) 。 如 果 大 家 想 更 详细 地 了 解 StatusBar 内 部 的 layout 布 局 ， 可 以 
参考 本 书 SystemU1 章 节 。 我 们 这 里 假设 mStatusBarWindow 已 经 准备 就 
绪 。 


变量 mWindowManager 是 一 个 WindowManager 对 象 ， 它 的 定义 如 下 : 


mWindowManager = (WindowManager )mContext.getSystemService(Context 


WindowManager (WindowManagerService 也 是 同样 的 情况 ) WRAY 
获取 与 存储 虽然 并 不 是 很 难 ， 但 如 果 方 式 不 当 也 会 影响 进程 的 执行 速 
度 。 或 许 也 是 因为 这 个 ，Android 各 个 版 本 中 对 此 都 有 不 小 的 改动 。 目 
前 Android4. 3 的 做 法 是 ， 将 常用 的 一 些 服务 统一 放 在 
SYSTEM SERVICE MAP: 


private static final HashMap<String, ServiceFetcher> SYSTEM_S 
new HashMap<String, ServiceFetcher>(); 


这 个 HashMap 的 String 指 的 是 服务 名 称 ， 如 WINDOW_SERV1CE， 
STORAGE_SERV1CE，TELEPHONY_SERV1CE 等 ;而 ServiceFetcher 则 提供 了 
真正 获取 String 对 应 服务 的 接口 ， 如 我 们 关心 的 WINDOW_SERVI1CE : 


/*frameworks/base/core/java/android/app/ContextImpl.java*/ 


new ServiceFetcher() { 
public Object getService(ContextImpl ctx) { 

Display display = ctx.mDisplay; 

if (display == null) { 
DisplayManager dm = (DisplayManager )ctx.getOuterConte 

Context .DISPLAY_SERVICE) ; 

display = dm.getDisplay(Display.DEFAULT_DISPLAY); 

} 


return new WindowManagerImpl(display); 


由 此 可 知 ， 
mContext. getSystemService (Context.WINDOW_ SERVICE) 返回 的 是 一 个 
Window Manager Imp1 对 象 一 一 注意 它 是 存在 于 本 地 进程 中 的 一 个 对 象 ， 
并 未 与 远 端 WMS 发 生 关 系 。 


值得 一 提 的 是 ，WindowManager1lmp1 继 承 自 WindowManager， 那 么 后 
者 呢 ? 


public interface WindowManager extends ViewManager { 
public Display getDefaultDisplay(); 
public void removeViewImmediate(View view); 
public boolean isHardwareAccelerated(); 


WindowManager 是 一 个 接口 类 ， 而 且 从 其 接口 方法 的 声明 中 可 以 看 
出 和 WMS 并 没有 直接 的 关系 。 可 以 这 么 说 ，WindowManager 更 像 
WindowManagerlmp1 的 约束 协议 ， 而 后 者 也 没有 与 WMS 中 提供 的 服务 一 一 
对 应 。 这 和 我 们 在 ServiceManager 看 到 的 情况 有 一 定 差异 。 不 过 要 记 住 
的 是 ， 不 论 形式 怎么 变 ， 进 程 间 通信 仍然 是 要 通过 Binder 驱 动 以 及 
ServiceManager 进 行 ， 因 而 是 “ 换 汤 不 换 药 ”的 做 法 。 


再 来 看 看 ViewManager : 


/*frameworks/base/core/java/android/view/ViewManager. java*/ 
public interface ViewManager 


{ 
public void addView(View view, ViewGroup.LayoutParams params) 
public void updateViewLayout(View view, ViewGroup.LayoutParam 
public void removeView(View view); 

} 


ViewManager 又 对 WindowManager 提 出 了 另 一 种 约束 。 总 的 来 说 ， 它 
们 几 个 的 关系 如 图 10-6 所 示 。 


+addView() 
+updateViewLayout() 
+remove View() 


第 一 层 约束 


fe — | 
+getDefaultDisplayQ 第 一 层 约束 
+remove Viewlmmediate() 

+isHardwareAccelerated() 


+getDefaultQ) 

+addView() 

+update ViewLayout() 
+remove View() 
+getDefaultDisplay() 
+remove ViewImmediate() 
+isHardwareAccelerated() 





全 图 10-6 WindowManaget 在 本 地 的 实现 类 


我 们 回 过 头 来 看 WindowManagerlmp1 中 是 如 何 具体 实现 addyiew 的 。 
具体 如 下 所 示 : 


/*frameworks/base/core/java/android/view/WindowManagerImpl. java*/ 
public void addView(View view, ViewGroup.LayoutParams params) { 
mGlobal.addView(view, params, mDisplay, mParentWindow) ; 
} 


mG1obal 是 一 个 全 局 变量 ， 同 时 也 是 单 实 例 。 它 提供 的 addView 函 数 
接口 的 实现 如 下 : 


/*frameworks/base/core/java/android/view/WindowManagerGlobal. java 
public void addView(View view, ViewGroup.LayoutParams params, Dis 
ViewRootiImpl root;// 注 意 WindowManagerImpl 和 ViewRoot 在 同一 进 j 
View panelParentView = null; 
synchronized (mLock) {...// 锁 保护 
int index = findViewLocked(view，false);// 以 前 是 否 已 经 沪 
if (index >= 0) {// 已 经 添加 过 ， 禁 止 重复 操作 
throw new IllegalStateException("View " + view 
+ " has already been added to the window 


} 


root = new ViewRootImpl(view.getContext(), display); 
view. setLayoutParams(wparams) ;// 为 这 个 View 对 象 设置 属性 
if (mViews == null) {// 此 进程 是 第 一 次 添加 View 





. .// 源 码 见 后 面 的 Casel. 
} else {// 之 前 已 经 添加 过 View 
, .// 源 码 见 后 面 的 Case2. 
} 
index--; 
mViews[index] = view; 
mRoots[index] = root; 
mParams[index] = wparams; 
} 
try { 


root.setView(view, wparams, panelParentView);// REW” 
} catch (RuntimeException e) { 

, .// 异 常 处 理 
} 




















} 


在 这 个 场景 中 ， 函 数 addView 的 各 参数 分 别 是 ;view 对 应 


mStatusBarWindow，params 对 应 lp，display 是 默认 的 显示 屏 
Sa eritW nidon nl Es 


上 述 代码 段 中 首先 调用 findViewLocked 来 查找 是 不 是 已 经 添加 过 这 
个 view 对 象 。 查 找 过 程 很 简单 ， 即 逐个 对 比 mViews[] 数 组 中 的 元 素 是 否 
4 是 肯定 就 没 必要 重复 添加 了 ， 直接 
抛 出 异常 ;否则 必须 为 此 view 对 象 生成 一 个 对 应 的 ViewRoot Imp1 。 这 里 
特别 说 明 一 下 ，WindowManagerGlobal 中 有 3 个 相关 联 的 成 员 数 组 变量 。 
如 下 : 
private View[] mViews; 


private ViewRootImpl[] mRoots; 
private WindowManager.LayoutParams[] mParams; 


这 3 个 数组 的 大 小 都 是 逐步 扩大 的 ， 而 且 保 持 一 致 。 换 句 话 说， 同 

= 个 index 值 在 3 个 cai 述 的 是 同一 个 对 象 。 我 们 在 后 续 的 ViewRoot 
章节 还 会 详细 论述 

接 下 来 分 为 两 种 情况 

Case1， 如 果 是 第 一 次 添加 View 


此 时 myiews == nul1， 处 理 如 下 : 














index = 1; 
mViews = new View[1]; 
mRoots = new ViewRootImpl[1]; 


mParams = new WindowManager.LayoutParams[1]; 


Case2. 之 前 已 经 至 少 添加 过 一 个 View， 处 理 如 下 : 


index = mViews.length + 1; 

Object[] old = mViews; 

mViews = new View[index]; 

System.arraycopy(old, ©, mViews, ©, index-1); 
old = mRoots; 

mRoots = new ViewRootImpl[index]; 
System.arraycopy(old, ©, mRoots, ©, index-1); 
old = mParams; 

mParams = new WindowManager .LayoutParams[index]; 
System.arraycopy(old, 0, mParams, 0, index-1); 


假设 myiews 为 空 ， 说 明 这 是 它 添加 的 第 一 个 View 对 象 ， 因 而 需要 分 
别 为 nViews 和 mRoots 分 配 该 对 象 的 存储 空间 。 因 为 mViews 中 的 View 数 量 
没有 办 法 预先 估计 ， 为 了 节省 内 存 ， 程 序 在 每 添加 一 个 View 时 都 只 申请 
刚刚 好 的 空间 大 小 〈 即 new View[index] ) ， 然 后 将 之 前 的 数据 复制 到 
数组 的 相应 位 置 。 其 他 两 个 数组 mRoots 和 mParams 也 需要 做 同样 的 处 
理 。 最 后 ， 我 们 把 view，root 和 wparams 这 些 新 增 对 象 分 别 添 加 到 上 述 
三 个 数组 中 。 


芳 数 结尾 处 调用 了 ViewRoot Imp1. setView() 一 一 到 目前 为 止 ， 所 有 
的 操作 都 还 是 在 本 地 进程 中 执行 的 。 那 么 添加 一 个 ViewRoot ， 需 不 需要 
让 WMS 知道 呢 ? 


答案 是 肯定 的 。 为 了 保持 连贯 性 ， 我 们 来 看 看 
ViewRoot1mp1: :setView 的 实现 重点 : 


/*frameworks/base/core/java/android/view/ViewRootIimpl.java*/ 
public void setView(View view, WindowManager.LayoutParams att 
synchronized (this) { 
if (mView == null) { 
mView = View;// 一 个 ViewRootImp1 对 应 一 棵 ViewTree， 因 有 1 


requestLayout( );// 发 起 layout 请 求 


try {... 
res = mWindowSession.addToDisplay(mWindow, mSe 
getHostVisibility(), mDisplay.getDispla 
mAttachInfo.mContentInsets, mInputChann 
} catch (RemoteException e) { 
.…// 出 错 处 理 
} finally { 
// 收 尾 工作 
} 





我 们 知道 ，WMS 才 是 窗口 管理 系统 。 因 而 当 应 用 程序 新 增 了 一 个 顶 
层 View (ViewTree 的 根 ) 时 ， 是 肯定 要 通知 WMS 的 。 在 将 View 树 (在 WMS 
看 来 ， 它 是 一 个 “Window”， 由 WindowState 来 管理 ) 注册 到 WMS 前 ， 需 
要 注意 什么 呢 ? 没 错 ， 必 须 先 执 行 第 一 次 layout， 也 就 是 调用 
requestLayout 一 一 WMS 除 了 窗口 管理 外 ， 还 负责 各 种 事件 的 派发 ， 所 以 
oo “注册 ”前 应 用 程序 要 确保 这 棵 View 树 已 经 做 好 了 接收 事件 的 





ViewRoot 起 到 了 中 介 的 作用 。 作 为 整 棵 View 树 的 e 它 同 
时 也 担负 着 与 WMS 进行 1pPC 通 信 的 重任 具体 而 言 ， 就 是 通 
1WindowSession 建 立 起 双方 的 桥梁 ， 如 图 10-7 所 示 。 


[WindowSession 





全 图 10-7 ViewRoot 与 WMS 的 通信 


这 些 知 识 点 在 前 面 的 WMS、AMS 和 Activity 的 关系 中 已 经 讲解 过 


在 ViewRoot Imp1 的 构造 函数 中 ， 会 通过 getWindowSession 来 打开 一 
个 与 WMS 的 可 用 连接 。 这 个 函数 的 逻辑 很 简单 ， 读 者 可 以 自行 阅读 。 


得 到 1WindowSession 后 ，setView 便 利用 它 来 发 起 一 个 服务 请 求 。 
Bl: 


res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttr 


在 IWindowSession 服 务 端 的 实现 中 (Session. java) , AŽ 
addToDisplay 〈 早 期 版 本 中 ， 这 个 接口 叫 作 add。 大 家 可 以 从 名 称 的 变 
化 中 看 出 Android 系 统 正在 增加 对 多 显示 屏 的 支持 ) 又 直接 调用 了 WMS 中 
的 addWindow: 


/*frameworks/base/services/java/com/android/server/wm/Session.jav 
public int addToDisplay(IWindow window, int seq, WindowManager.La 
int viewVisibility, int displayId, Rect outContentIns 
InputChannel out InputChannel) { 
return mService.addWindow(this, window, seq, attrs, viewVi 
outContentInsets, outInputChannel); 
} 


仔细 分 析 一 下 ViewRoot 提 供给 1WindowSession 的 参数 : 第 二 个 参数 
是 IWindow， 即 WMS 回调 ViewRoot 时 要 用 到 的 。 第 三 个 参数 是 一 个 int 数 
值 ， 有 点 类 似 于 前 一 章节 SurfaceFlinger 中 的 sequence， 是 用 于 WMS 与 


ViewRoot 间 状态 同步 的 。 在 WMS 服务 端 ， 这 个 状态 同步 值 (sequence) 
记录 在 Wi ndowState: :mSeq 中 。 fin aod tna ate te gre 
时 ，sequence 值 有 可 能 会 改变 ， 并 通过 |Window: : 
dispatchSystemUiVisibi | ityChangedix 人 
进行 更 新 。 第 四 个 参数 是 关于 属性 的 ， 后 面 小 节 有 详细 介绍 。 第 五 个 参 
数 是 View 的 可 见 性 等 。 


聪明 的 读者 一 定 发 现 了 其 中 并 没有 View 对 象 或 者 “View 树 ”相关 的 
变量 。 为 什么 呢 ? 


因为 WMS 并 个 关心 View 树 所 表达 的 具体 UI 内 容 ， 它 只 要 知道 各 应 用 
进程 显示 表面 的 大 小 、“ 层 级 值 ”《〈 这 些 信息 已 经 包含 在 
WindowManager.LayoutParams 中 ) 即 可 。 


来 看 看 WMS 中 的 addWi ndow 实 现 : 


/*frameworks/base/services/java/com/android/server/wm/WindowManag 
public int addWindow(Session session, IWindow client, int se 
Params attrs, int viewVisibility, int displayId, Rect outCon 

outInputChannel) { 
int[] appOp = new int[1]; 
int res = mPolicy.checkAddPermission(attrs, appOp);/*Step 


WindowState attachedWindow = nu11;// 适 用 于 Sub Window 的 情况 
WindowState win = null;//WindowState 用 于 记录 一 个 Window 
long origId; 

final int type = attrs.type;// 窗 口 类 型 
synchronized(mWindowMap) { 





if (mWindowMap.containsKey(client.asBinder())) {/*Ste 
Slog.w(TAG, "Window " + client + " is already adde 
return WindowManagerGlobal.ADD_DUPLICATE_ADD; 


} 
if (type >= FIRST_SUB_WINDOW && type <= LAST_SUB_WIND 
attachedWindow = windowForClientLocked(null, attrs 


} 

boolean addToken = false;// 用 来 标识 后 面 是 否 有 添加 Token 的 挡 

WindowToken token = mTokenMap. ee token); 

if (token == null) 4.. 

} else if (type >= FIRST_APPLICATION_WINDOW && type 
<= LAST_APPLICATION_WIND 

} else if (type == TYPE_INPUT_METHOD) 4... 

} else if (type == TYPE_WALLPAPER) {... 





} else if (type == TYPE_DREAM) 4... 
}/*Step4. 根据 不 同窗 口 类 型 ， 检 查 有 效 性 */ 








win = new WindowState(this, session, client, token, a 
seq, attrs, viewVisibility, displayC 
if (win.mDeathRecipient == null){../*Step6. 客户 端 已 经 死 
return WindowManagerGlobal.ADD_APP_EXITING; 
} 


mPolicy.adjustWindowParamsLw(win.mAttrs);/*Step7. 调整 
win.setShowToOwnerOnlyLocked(mPolicy.checkShowToOwner 
res = mPolicy.prepareAddWindowLw(win, attrs); 


res = WindowManagerGlobal.ADD_OKAY; 

origId = Binder.clearCallingIdentity(); 

if (addToken) {/*Step8. 前 面 步骤 中 新 增 了 Token 元 素 */ 
mTokenMap ,put(attrs.token，token);// 把 它 添加 进 nToke 

} 


mwWindowMap.put(client.asBinder()，win);/* 注 意 和 mTokenM 








boolean imMayMove = true; 
/*Step9. 接 下 来 会 将 所 有 Window 按 顺序 进行 排列 */ 
if (type == TYPE_INPUT_METHOD) {... 
} else if (type == TYPE_INPUT_METHOD_DIALOG) {... 
} else { 
addWindowToListInOrderLocked(win, true); 
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if (displayContent.isDefaultDisplay) { 
mPolicy.getContentInsetHintLw(attrs, outContentiInse 
} else { 
outContentInsets.setEmpty(); 
} 


assignLayersLocked(displayContent.getwindowList());/* 





return res; 


} 


Step16addWindow。 首 先 对 用 户 的 窗口 请 求 进行 权限 检查 ， 如 果 窗 
口 的 类 型 是 : 


type < FIRST_SYSTEM_WINDOW|| type > LAST_SYSTEM_WINDOW 


就 直接 返回 ADD_0KAY， 因 为 任何 人 都 有 权限 添加 非 系统 窗口 ; 否则 


说 明 添 加 的 是 系统 窗口 ， 需 要 进一步 细 化 一 一 比如 TYPE_TOAST 虽 然 是 系 
统 窗口 ， 但 是 应 用 程序 也 有 权限 来 创建 。 而 TYPE_PHONE， 
TYPE_SYSTEM_ERROR 等 窗口 类 型 就 需要 相应 的 权限 许可 才能 使 用 ， 即 
android. Manifest. permission. SYSTEM ALERT WINDOW. 


Step2@addWindow. 变量 mWindowMap 是 一 个 《lBinder， 
WindowState》 类 型 的 HashMap， 前 面 的 1Binder 代 表 IWindow。 所 以 
mWindowMap 是 WMS 中 与 此 1Window 相 对 应 的 WindowState 的 映射 。 另 外， 
下 面 还 会 出 现 《<IBinder，WindowToken》 类 型 的 mTokenMap， 读 者 应 注意 
区 分 。 一 个 INWindow 只 允许 添加 唯一 的 窗口 ， 否 则 项 数 会 直接 报错 返 
回 。 当 然 ， 一 个 应 用 进程 中 是 可 以 持 有 多 个 ViewRoot 对 象 的 一 一 意味 着 
它 所 管理 的 ViewTree 理 论 上 并 没有 数量 上 的 限制 。 


除了 避免 重复 添加 外 ， 程 序 还 会 对 用 户 的 窗口 添加 请 求 进行 各 种 其 
他 的 前 期 处 理 ， 包 括 系统 初始 化 条 件 判 断 等 。 如 果 一 切 顺 利 ， 才 能 继续 
往 下 执行 。 

Step36@addWindow。 如 果 要 添加 的 窗口 类 型 为 “ 子 窗口 ”， 还 要 先 
找 出 它 的 “ 父 窗口 ”; 而 且 要 特别 注意 “ 父 窗口 ”本 身 不 能 是 其 他 窗口 
的 “ 子 窗口 ”， 否 则 添加 会 失败 。 具 体 的 函数 实现 是 


windowForGl ientLocked. 





~ Step4@addWindow。 这 里 有 几 个 相似 的 Token 变 量 很 容易 混淆 ， 我 们 
统一 进行 讲解 。 


e token 
类 型 为 Wi ndowToken. 
e attrs.token 


类 型 为 |Binder 。 它 代表 了 这 个 窗口 的 “主人 ”。AMS 为 每 一 个 
Activity 都 分 别 创建 了 一 个 ActivityRecord 对 象 ， 其 本 质 就 是 一 个 
IBinder。 在 启动 Activity 时 ， 这 个 token 会 被 自动 赋值 ， 因 而 开发 人 员 
可 以 不 用 特别 关注 。 


e addToken 


布尔 类 型 ， 用 于 指示 后 续 操作 中 有 没有 新 的 Token 被 添加 。 
我 们 以 图 10-8 来 理 顺 各 Token 的 关系 。 


ViewRootil 
其 他 窗口 使 用 者 









WindowState 





mToken 
Map 























app Token 


Window Token 
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ActivityRecord 





attrs,token 


A token 


全 图 10-8 各 token 的 关系 图 
所 以 这 里 的 有 效 性 检查 逻辑 是 : 


e 如 果 attrs.token 在 mTokenMap 中 找 不 到 对 应 的 WindowToken， 说 明 它 
在 AMS 中 没有 记录 。 此 时 分 为 两 种 情况 : 


(1) 假如 是 以 下 几 种 窗口 类 型 ， 则 必须 在 AMS 中 “有 案 可 询 ”: 


[FIRST_APPLICATION_WINDOW, LAST_APPLICATION_WINDOW] 
TYPE_INPUT_METHOD 
TYPE_WALLPAPER 
TYPE_DREAM 


也 就 是 说 ， 这 些 类 型 的 窗口 必须 事先 已 经 在 mTokenMap 中 添加 了 对 
应 关系 一 一 这 一 步 是 由 AMS 为 它们 自动 完成 的 。 如 果 此 时 找 不 到 ， 很 可 
能 说 明 某 些 步骤 出 现 了 问题 ， 所 以 程序 会 报错 返回 。 


(2) 除 上 述 所 列 之 外 的 窗口 类 型 ， 允 许 在 AMS 中 没有 “备案 ”。 接 
着 程序 会 主动 为 这 个 窗口 生成 一 个 WindowToken， 并 置 addToken 为 





true. 


e 如 果 在 mTokenMap 可 以 找到 对 应 的 WindowToken， 根 据 前 一 种 情况 

的 分 析 ， 只 有 上 面 所 列举 的 那 几 种 窗口 类 型 
(TYPE_INPUT_METHOD 等 ) 才 有 可 能 在 mTokenMap 中 事先 添加 

了 对 应 关系 。 此 时 还 需 做 进一步 检查 : 比如 在 Application Window 的 

清 况 下 ， 还 要 求 token.appWindow Token 也 不 能 为 空 。 除 此 之 外 ， 

ViewRoot 所 指示 的 windowTypel(attrs.type®) 必 须 和 AMS 中 当时 登记 的 类 

型 (token.windowType) 完全 一 致 ， 否 则 就 会 报 

ADD_BAD_APP_ TOKEN 的 错误 。 





Step5@addWindow。 如 果 一 切 顺 利 ，WMS 会 为 这 个 窗口 新 增 一 个 
WindowState: 


win = new WindowState(this, session, client, token, 
attachedWindow, appOp[0], seq, attrs, viewVisibilit 


WindowStatef4is ey SLABA: this 代 表 WMS 自 身 ; session 
是 WMS 提 供给 窗口 使 用 者 的 lwindowSession; client 则 是 lwindow， 即 窗 
口 使 用 者 提供 给 WMS 的 访问 通道 ， token 是 WindowToken 对 象 ; 
attachedWindow 代 表 父 窗口 〈 如 果 存 在 的 话 ) 等 。 这 个 函数 在 前 面 小 节 
已 经 讲解 过 ， 其 中 一 个 重点 就 是 为 窗口 分 配 基础 层级 (mBaseLayer) 。 


Step6@addWindow。 如 果 客 户 端 已 经 死亡 ， 那 么 就 不 需要 继续 往 下 
执行 了 。 这 种 情况 是 有 可 能 发 生 的 ， 如 应 用 进程 异常 Crash。 


Step7@addWindow。 调 用 Policy 进 行 窗口 参数 的 调整 ， 此 时 Policy 
会 对 某 些 情况 进行 约束 。 函 数 adjustWindowParamsLw 很 简单 ， 读 者 可 以 
看 看 。 另 一 个 prepareAddWindowLw 还 是 进行 必要 的 检查 工作 ， 如 某 些 类 
型 的 窗口 在 系统 中 只 允许 同时 有 一 个 存在 等 。 


Step8eaddWindow。 如 果 前 面 几 个 步骤 中 新 增 了 Token 对 象 ， 那 么 此 
时 我 们 需要 把 它 添加 到 全 局 HashMap 中 ， 即 mTokenMap 。 


Step9@addWindow。 因 为 我 们 新 增 一 个 Window， 很 可 能 会 影响 之 前 
已 经 排列 好 的 WindowLi st， 所 以 通过 相应 的 “添加 函数 ” 〈 如 
addWindowToListln0rderLocked) 将 此 新 窗口 按 顺序 添加 到 WindowLi st 
中 。 另 外 ， 如 果 用 户 指定 了 FLAG SHOW WALLPAPER (比如 有 的 应 用 程序 


在 属性 中 指明 需要 以 壁纸 为 背景 ; 或 者 有 的 应 用 程序 部 分 U1 区 域 是 透明 
的 ， 假 如 没有 壁纸 做 底层 背景 的 话 ， 这 块 区 域 就 会 是 黑 的 ) 或 者 本 身 就 
是 壁纸 类 型 的 窗口 ， 还 要 调用 ad justWal lpaper WindowsLocked 进 行 壁 
纸 调整 。 稍 后 我 们 会 详细 分 析 对 窗口 进行 调整 的 函数 
addWindowToListln OrderLocked. 


Step10@addWindow. ee @WgetContent lnsetHintLw 用 于 计算 窗口 的 
Content1nset 区 域 ， 我 们 将 在 窗口 大 小 这 一 小 节 中 进行 分 析 。 


Step11@addWindow. pk Wassi gnLayersLocked# Bl mHE i ndowk& 
级 时 已 经 分 析 过 ， 它 负责 给 上 一 步 已 经 排 好 序 的 WindowLi st 中 的 各 窗口 
一 一 分 配 最 终 的 层级 值 。 


先 来 看 看 addWi ndowToLi st1n0rderLocked 的 实现 。 从 名 称 就 可 以 看 
出 ， 它 需要 将 系统 中 当前 所 有 的 窗口 进行 排列 。 那 么 ， 按 照 什么 顺序 
Ne ? 


private void addWindowToListInOrderLocked(WindowState win, bool 
final IWindow client = win.mClient;//windowState'? 4% J Iwir 
final WindowToken token = win.mToken;// 同 时 还 有 WindowToken 
final DisplayContent displayContent = win.mDisplayContent; 
final WindowList windows = win.getWindowList();//windowsid: 
final int N = windows .size();// 当 前 所 有 窗口 的 数量 
final WindowState attached = win.mAttachedWindow; //% fH (4 
int 工 ;// 用 于 循环 计数 
WindowList tokenWindowList = getTokenWindowsOnDisplay(toke 
if (attached == null) { // 没 有 父 窗口 的 情况 
int tokenWindowsPos = 0; 
int windowListPos = tokenWindowList.size(); 
if (token.appWindowToken != null) 4.. 
} else { // appwindowToken 为 nulL1 的 情况 ， 符 合 我 们 的 场景 
final int myLayer = win.<strong>mBaseLayer</strong 
for (i=N-1; i>=0; i--) {// 寻 找 合适 的 位 置 
if (windows.get(i).mBaseLayer &lt;= myLayer) { 
break;// 找 到 了 
} 


i++; 
windows .<strong>add</strong>(I，win);// 添 加 到 List 中 
mWindowsChanged = true; 




















} 
if (addToToken) { 
token.windows.add(tokenWindowsPos, win); 


} 
} else {..//attached 不 为 空 的 情况 略 





if (win.mAppToken != null && addToToken) { 
win.mAppToken.allAppWindows.add(win); 
J 


i 


这 个 函数 很 长 ， 如 果 直 接 看 代码 相信 不 少 人 都 会 觉得 “ 云 里 雾 
里 ”。 因 此 我 们 按照 本 小 节 的 场景 〈 添 加 StatusBar 窗 口 ) 先 将 它 拆 分 
成 若干 个 分 支 ， 再 逐一 解析 。 


e attached==null 


最 外 围 的 分 支 是 以 attached 是 否 为 空 来 弄 定 的 。 换 名 话说， 是 不 是 
子 窗口 类 型 。 因 为 本 小 节 讲 解 的 Status Bar 是 系统 窗口 ， 所 以 我 们 侧重 
于 attached 为 空 的 情况 。 


e token.appWindowToken != null 


紧 接 着 判断 appWindowToken 是 否 为 空 ， 即 当前 窗口 是 不 是 Activity 
相关 的 。 因 为 SystemU1 实 际 上 是 由 Service 构 成 的 ， 所 以 没 
appWindowToken。 


根据 这 个 场景 ，appWindowToken 不 为 nul1， 所 以 它 的 位 置 受到 
mBaseLayer 的 影响 。 这 个 变量 对 于 Status Bar 类 型 的 窗口 ， 计 算 方 法 如 
下 : 


mBaseLayer = mPolicy.windowTypeToLayerLw(a.type) 
* WindowManagerService.TYPE_LAYER_MULTIPLIER 
+ WindowManagerService.TYPE_LAYER_OFFSET; 


其 中 windowTypeToLayerLw () 返回 值 为 15，TYPE_LAYER_MULTIPLIER 
为 10000，TYPE_LAYER_0FFSET 是 1000 一 -一 所 以 mBaseLayer 为 151000。 按 
照 这 个 值 ， 我 们 来 依次 查找 windows 中 所 有 的 基础 层级 ， 顺 序 是 数组 元 
素 由 大 至 小 一 一 这 样 一 旦 myLayer 大 于 windows 中 某 个 窗口 的 mBaseLayer 
值 ， 那 么 它 一 定 会 大 于 其 下 面 所 有 窗口 的 mBaseLayer 。 所 以 它 的 插入 位 
置 就 是 i++ (因为 它 比 第 i 个 元 素 大 ) 。 当 然 ， 这 并 不 是 这 个 窗口 的 最 终 
layer 值 (最 终 层 级 由 assignLayersLocked 来 分 配 ) 。 从 中 也 可 以 看 


出 ， 同 一 类 型 窗口 的 优先 级 ， 后 创建 的 优先 级 高 。 


这 样 大 家 就 系统 地 学 习 了 添加 System Window (以 Status Bar 为 
例 ) 到 WMS 中 的 流程 。 接 下 来 的 小 节 将 在 此 基础 上 ， 对 比分 析 普 通 应 用 
程序 窗口 的 添加 过 程 。 


10.3.2 Activity 窗口 的 添加 过 程 


对 于 WMS 来 说 ， 它 并 不 会 特别 区 分 窗口 的 使 用 者 是 谁 。 因 而 理论 上 
个 管 是 Act ivity 窗 口 或 者 系统 窗口 ， 在 WMS 中 基本 都 是 一 视 同 仁 ， 只 不 
过 层级 和 权限 会 有 所 差异 。 


当 用 户 启 动 一 个 Activity 时 〈 比 如 通过 startActivity) ，AMS 首 先 
判断 该 Activity 所 属 应 用 程序 进程 是 否 已 经 在 运行 : 如 果 是 就 向 这 个 进 
程 发 送 启 动 指 定 Activity 的 命令 ; 否则 先 创建 该 应 用 进程 ， 运 行 
ActivityThread 主 线程 ， 然 后 处 理 启动 Activity 的 操作 。 这 部 分 知识 在 
ActivityManagerService 章 节 已 经 有 过 详细 介绍 ， 不 清楚 的 读者 可 以 回 
头 复习 下 。 


和 其 他 三 大 组 件 不 同 ，Activity 与 生 俱 来 拥有 显示 U1 宕 面 的 “ 基 
因 ”， 并 且 它 需要 WMS 的 支持 才能 正常 工作 。 当 然 ， 这 并 不 意味 着 
Service 或 者 Broadcast 就 完全 无 法 显示 图 形 再 面 一 一 比如 前 面 小 节 讲 解 
的 Status Bar 的 主体 就 是 一 个 Service。 只 不 过 借助 于 Activity 提 供 的 
各 种 机 制 ， 可 以 为 创建 和 管理 JI 丙 面 带 来 诸多 便利 ， 这 对 于 开发 人 员 来 
说 “ 何 乐 而 不 为 ” 呢 ? 


当 AMS 发 现 一 个 Activity 即 将 启动 时 ， 它 需要 将 相关 信息 “ 告 
41)” WMS: 


/*frameworks/base/services/java/com/android/server/am/ActivitySta 
private final void startActivityLocked(...) 


mService.mWindowManager .addAppToken(addPos, r.appToken, r.ta 
screenOrientation, r.fullscreen, 
(r.info.flags & ActivityInfo.FLAG_SHOW_ON_L 


WMS 会 把 ActivityRecord 记 录 到 我 们 前 面 addWi ndow 中 看 到 的 
HashMap<lBinder，WindowToken>mTokenMap 中 。 根 据 之 前 的 分 析 可 知 ， 
如 果 没 有 这 一 步 ，Activity 应 用 程序 调用 addWindow 就 会 失败 。 


那么 Activity 应 用 进程 在 什么 时 候 会 调用 addyiew， 进 而 由 WMS 来 处 
F#addWi ndowhe ? 


Activity 从 启动 到 最 终 在 屏幕 上 显示 出 来 ， 分 别 要 经 历 onCreate- 
>onStart->onResume 三 个 状态 迁移 。 Hoven AFI 可 见 时 

会 调用 的 ， 紧 接着 ActivityThread 就 会 通过 WindowManager Imp | RHE 
应 用 程序 窗口 添加 到 系统 中 。 B a 


/*frameworks/base/core/java/android/app/ActivityThread.java*/ 
final void handleResumeActivity(IBinder token, boolean clearHide, 
ActivityClientRecord r = performResumeActivity(token, clearH 
ActivityMonResume ty R 


View decor = r.window.getDecorView( );/*DecorVieweActivity ®t 
可 以 参见 下 一 章 的 分 析 */ 

decor.setVisibility(View. INVISIBLE) ;// 可 见 性 
ViewManager wm = a.,getwindowManager();// 得 到 的 实际 上 是 WindowMar 
WindowManager.LayoutParams 1 = r.window.getAttributes();// 获 ] 
a.mDecor = decor; 
1.type = WindowManager.LayoutParams.TYPE_BASE APPLICATION; // 
1.softInputMode |= forwardBit; 
if (a.mVisibleFromClient) { 

a.mWindowAdded = true; 

wm.addView(decor，1);// 将 窗口 添加 到 WMS 中 


值得 一 提 的 是 ， 涵 数 performResumeActivity 将 最 终 调用 Activity 
的 onResume， 不 过 中 间 还 需要 经 过 很 多 处 理 过 程 。 如 果 这 个 Activity 是 
可 见 的 ， 那么 就 需 要 把 它 的 由 窗 口 添 加 到 WMS 中 。 一 个 Activity 对 应 的 
Viowktt #8 Sh Bl Decor iow. 可 以 由 Window. getDecorView() 获取 。 换 名 
话说 ， 开发 人 员 通 常 在 onCreate () HFFA setContentV i ew () 所 设置 
BY “Content” 其 实 只 是 DecorView 中 的 “内 容 ” 部 分 ， 而 不 包括 标题 栏 
村 “Decor”。 这 些 知识 在 下 一 章节 会 有 详细 描述 ， 建议 读者 穿 F fe lie 
Eo 


对 于 一 般 的 应 用 程序 ， 其 窗口 类 型 (Window Type) 是 
TYPE_BASE_APPLICATION， 值 为 1。 这 也 是 “层级 值 ”最 低 的 一 种 窗口 类 
型 。 WindowManager 1mp | 对 象 ( 即 变 量 wm) 则 是 通过 Act ivity. 
getWindowManager 取 得 的 。 


后 我 们 通过 WindowManager Impl. addView 来 把 DecorView 添 加 到 系 


统 中 ， 这 将 导致 WMS 中 的 addWindow 被 调用 一 一 中 间 流 程 和 我 们 在 系统 窗 
口 添加 小 证 的 分 析 是 完全 一 样 的 ， 这 里 不 再 袭 述 。 


那么 ，WMS 添 加 应 用 窗口 和 系统 窗口 相 比 有 何 差 寞 呢 ? 


可 以 说 WindowManagerService. addWindow 处 理 这 两 种 类 型 的 窗口 时 
在 主体 架构 上 没有 任何 区 别 ， 一 般 WMS 都 会 为 它们 生成 一 个 WindowState 
来 管理 窗口 。 不 过 紧 接 着 将 应 用 窗口 添加 到 全 局 窗口 列表 中 的 处 理 流程 
就 有 所 不 同 了 “〈 即 前 一 小 节 Step9 后 的 步骤 ) : 


private void addWindowToListInOrderLocked(WindowState win, boolea 
final IWindow client = win.mClient;//windowState'? 4% J Iwir 
final WindowToken token = win.mToken;// 同 时 还 有 WindowToken 
final DisplayContent displayContent = win.mDisplayContent; 
final WindowList windows = win.getWindowList();//windowsz: 
final int N = windows .size();// 当 前 所 有 窗口 数量 
final WindowState attached = win.mAttachedWindow; //% fH (4 
int 工 ;// 用 于 循环 计数 
WindowList tokenWindowList = getTokenWindowsOnDisplay(toke 
// EARS RS} Ay AA h eC ED, AS 
if (attached == null) { // 没 有 父 窗口 的 情况 
int tokenWindowsPos = 0; 
int windowListPos = tokenWwindowList .size();// 该 应 用 程序 4 
if (token.appWindowToken != null) {// 应 用 程序 的 窗口 符合 这 - 
int index = windowListPos - 1; 
if (index >= 0) {// 第 一 种 情况 ， 该 应 用 程序 已 包含 最 少 一 个 
if (win.mAttrs.type == TYPE_BASE_APPLICATION) 
WindowState lowestWindow = tokenWindowList. 
placeWindowBefore(lowestWindow, win); 
tokenWindowsPos = indexOfWinInWindowList(lo 
} else { 












































} 
} else {// 第 三 种 情况 .应 用 程序 还 没有 其 他 窗口 存在 
.…// 详 细 源 码 抽取 到 后 面 进行 详细 解释 


} 
} else { // appWindowToken 为 hull 的 情况 
} 


} else {..//attached 不 为 空 的 情况 略 
} 














函数 最 前 面 的 一 部 分 内 容 和 系统 窗口 添加 过 程 中 的 情况 完全 一 致 ， 
此 时 不 再 玲 述 。 上 述 代 码 段 的 剩余 内 容 我 们 也 分 为 若干 ase 进行 解析 。 


应 用 程序 窗口 主要 分 为 两 种 情况 : 


。 此 应 用 程序 已 经 拥有 至 少 一 个 窗口 ; 
。 此 应 用 程序 还 没有 其 他 窗口 存在 。 


一 个 应 用 程序 名 下 的 所 有 窗口 ， 都 可 以 通过 token. windows 来 获 
得 。 所 以 当 tokenWindows Pos>=1 时 ， 说 明 应 用 程序 窗口 列表 的 大 小 不 
为 0， 属 于 第 一 种 情况 。 


默认 情况 下 Act ivity 中 添加 的 窗口 类 型 是 
TYPE_BASE_APPLICATION， 等 级 是 最 低 的 ， 因 而 我 们 只 需 把 它 放置 在 此 
应 用 程序 窗口 队列 中 的 最 底 端 就 可 以 ， 即 调用 placeWindowBefore 


(lowestWindow, win). 


假如 应 用 程序 当前 还 没有 其 他 窗口 存在 ， 情 况 会 复杂 一 些 。 我 们 特 
别 把 这 部 分 代码 抽取 出 来 ， 具 体 如 下 所 示 : 


final int NA = mAnimatingAppTokens.size(); 

WindowState pos = null; 

for (i=NA-1; i>=0; i--) {//Stepl .在 所 有 AppWindowTo 
AppWindowToken t = mAnimatingAppTokens.get(i) 
if (t == token) { 


Lees 
break;// 找 到 目标 ， 跳 出 循环 


tokenWindowList = getTokenWindowsOnDisplay(t, 
if (!t.sendingToBottom && tokenWindowList.siz 


pos = tokenwindowList.get(0);// 以 此 为 参考 


} 
if (pos != null) {//Step2. 在 AppWindowToken 中 找到 参 
WindowToken atoken = mTokenMap.get(pos.mClien 
if (atoken != null) { 
tokenWindowList =getTokenWindowsOnDisplay 
win.mDisplayContent ) ; 
final int NC = tokenWindowList.size(); 
if (NC > 0) { 
WindowState bottom = tokenWindowList. 
if (bottom.mSubLayer < 0) { 


pos = bottom; 


i 


} 
placewindowBefore(pos，win);// 放 置 在 参考 物 下 面 
} else {//Step3 在 AppWindowToken 中 没有 找到 参考 位 置 
while (i >= 0) {// 继续 向 下 查找 ， 直 到 第 一 个 有 窗口 处 
AppWindowToken t = mAnimatingAppTokens.ge 
tokenWindowList = getTokenWindowsOnDispla 
final int NW = tokenWindowList.size(); 
if (NW > 0) { 
pos = tokenWindowList.get(NwW-1); 
break; 











i--; 


} 
if (pos != null) {//Step3.1 第 二 个 循环 找到 了 参考 值 
WindowToken atoken = mTokenMap.get(pos.mC 
if (atoken != null) { 
final int NC = atoken.windows.size(); 
if (NC > 0) { 
WindowState top = atoken.windows. 
if (top.mSubLayer >= 0) { 
pos = top; 
} 


} 


placewindowAfter(pos, win); 

} else {//Step3.2 第 二 个 循环 后 仍然 没有 找到 参考 值 
final int myLayer = win.mBaseLayer;// 通 过 E 
for (i=0; i<N; i++) { 

WindowState w = windows.get(1); 

if (w.mBaseLayer > myLayer) { 
break; 

} 


} 
windows .add(i，win);// 最 终 找到 的 合适 的 位 置 ， 
mWindowsChanged = true; 





} 


Step1. WindowManagerService 不 但 有 mTokenMap 这 一 
<IBinder, WindowToken》 类 型 的 HashMap， 而 且 还 单独 将 其 中 
AppWindowToken 部 分 数据 存储 到 mAppTokens 中 。 如 下 : 


final ArrayList<AppWindowToken> mAppTokens = new ArrayList<AppWin 


另外 ， 还 有 一 个 与 mAppTokens 非 常 类 似 的 列表 ， 即 上 面 代码 段 中 的 
mAnimatingAppTokens。 如 果 当 前 没有 animations 在 进行 ， 那 么 它们 是 
完全 相同 的 。 从 源码 实现 上 来 看 ， 函 数 
handleAnimatingStoppedAndTransitionLocked 会 先 清除 
mAnimatingAppTokens， 然 后 把 mAppTokens 的 所 有 元 素 加 载 进去 。 


接 下 来 程序 逆序 查找 mAnimatingAppTokens 中 各 个 AppWindowToken 
元 素 。 一 旦 t==token 就 跳出 循环 ， 而 且 i 自 减 1; 如 果 当 前 元 素 与 token 
不 匹配 ， 且 !t. sendingToBottom &&tokenWindow List. size()> 0, Af 
么 可 以 用 pos 记 录 下 该 AppWindowToken 管 理 所 有 windows 的 第 一 个 ， 即 
tokenWindowList. get (0) 。 这 是 什么 意思 呢 ? 


mAnimatingApp Tok 
WindowState 


SS 


| 


E twindows get(( 





全 图 10-9 Step1 的 查找 示意 图 


图 10-9 描 述 了 Step1 中 的 一 个 查找 范例 。 当 查找 到 第 i+2 个 
AppWindowToken 时 ， 因 为 t1=token， 此 时 这 个 token 对 应 的 windows 不 为 
空 ， 而 且 这 些 window 不 会 被 移动 到 底部 〈sendingToBottom 将 在 
moveAppTokensToBottom 中 被 置 为 true) ， 所 以 我 们 用 pos 来 记录 
tokenWindowList. get (0) ， 作 为 后 续 的 参考 。 当 查找 到 第 i+1 时 ， 刚 好 
t==token， 所 以 会 跳出 循环 ， 而 且 将 i 自 减 1《〈 即 i--) ， 所 以 i 的 最 终 值 
与 t 所 在 位 置 相差 1。 


Step2， 假 如 pos!=nul1， 说 明 我 们 在 前 一 步 又 中 成 功 找 到 了 窗口 插 


入 位 置 的 参考 值 ， 即 pos。 接 下 来 先 从 mTokenMap 中 找到 pos 这 个 窗口 对 
应 的 WindowToken: 


WindowToken atoken = mTokenMap.get(pos.mClient.asBinder()); 


然后 判断 参考 窗口 的 WindowState. mSubLayer 是 否 小 于 0， 如 果 是 ， 
则 pos=bottom。 最 后 ， 将 需要 添加 的 窗口 直接 放置 到 参考 窗口 的 下 面 ， 


即 placeWindowBefore (pos, win) 。 


Step3. 如 果 pos==nul1， 说 明 前 面 Step1 中 没有 找到 参考 位 置 。 原 因 
有 很 多 ， 如 这 个 token 上 面 的 元 素 没 有 窗口 ， 或 者 它们 的 
sendingToBottom 为 true 等 。 此 时 就 需要 “ 退 而 求 其 次 ”， 继 续 查找 
mAnimatingAppTokens 剩 下 的 元 素 中 第 一 个 达 有 窗口 的 那个 token。 当 
然 ， 前 提 必 须 是 ij>=0 一 一 因为 假如 Step1 中 的 循环 已 经 遍历 了 整个 列 
表 ， 那 么 此 时 这 个 循环 就 不 会 被 执行 了 。 


Step3. 1 假如 Step3 中 的 循环 结束 后 pos!=nul1， 那 我 们 就 以 这 个 pos 
为 参考 值 ， 并 且 是 将 位 置 放 在 pos 这 个 窗口 所 属 WindowToken 管 理 的 所 有 
windows 的 最 上 面 。 


Step3. 2 假如 Step3 中 的 循环 结束 后 pos 仍 然 为 空 ， 那 么 就 以 此 窗口 
的 BaseLayer 为 参考 标准 。 具 体 来 说 ， 就 是 在 所 有 窗口 (windows) PS 
找 合 适 的 位 置 进行 插入 。 


10.3.3 窗口 添加 实例 


前 面 两 个 小 节 都 是 从 源码 的 角度 来 分 析 WindowManagerServi ce 对 窗 
口 的 管理 ， 而 本 小 节 将 通过 一 个 具体 的 例子 来 加 深 大 家 的 理解 。 范 例 很 
简单 ， 即 从 Launcher2 中 点 击 Gal lery 图 标 来 启动 这 个 应 用 程序 。 我 们 将 
在 Wi ndowManagerService 的 适当 位 置 中 加 上 调试 Log， 以 方便 读者 了 解 
整个 流程 中 的 各 种 状态 变化 。 


我 们 知道 ， 当 Gal lery 这 个 Activity 即 将 显示 时 ， 它 需要 通过 一 系 
列 的 函数 调用 最 终 进入 WMS 的 addWindow〔 这 一 过 程 就 不 再 歼 述 了 ) 中 。 
这 时 WMS 的 WindowList 中 还 不 存在 Gal1lery 所 对 应 的 WindowState， 如 图 
10-10 所 示 。 





三 ( 

WindowManager 1206, addwindow, before, i=4,w=Window{412529d0 RecentsPanel paused=false},su 
rfacestate=0 

WindowManager 1206, addwindow, before, i=3,w=Window({411£6280 StatusBar paused=false},surfa 
cestate=4 

WindowManager 1206, addwindow, before, i=2,w=Window(412455a0 Keyguard paused=false},surfac 
estate=0 

WindowManager 1206, addwindow, before, i=1,w=Window({413530f0 com.android.launcher/com.andr 
oid. launcher2.Launcher paused=true},surfacestate=4 

WindowManager 1206, addwindow, before, i=0,w=Window({411cf648 com.android.systemui.ImageWal 


lpaper paused=false},surfacestate=4 
全 图 10-10 添加 Gallery 窗 口 前 的 状态 


上 面 这 段 Log 中 ，“addwindow begin” 被 放 在 函数 addWindow 的 开 
头 ; “addwindow, before” 紧 随 其 后 ， 表 示 在 addWindow 执 行 具体 操作 
前 的 情况 。 我 们 依次 打印 出 了 当前 系统 中 所 有 WindowState 的 信息 (te, 
就 是 WindowList 列 表 中 的 所 有 元 素 ) ， 以 及 它们 的 Surface 状 态 。 


Surface 是 窗口 能 真正 显示 到 物理 屏幕 上 的 基础 ， 由 
SurfaceFlinger 管 理 ， 我 们 在 后 续 小 节 会 专门 介绍 。 先 来 看 看 它 有 了 哪些 
状态 ， 具 体 如 表 10-7 所 示 。 


表 10-7 Surface 的 状态 


Surface 已 经 创建 ， 但 窗口 
还 没有 开始 绘制 ， 所 以 
Surface 实 际 上 处 于 隐藏 状 





显示 ， 它 将 在 下 一 次 的 


窗口 已 经 第 一 次 绘制 完 
COMMIT DRAW. PENDINGI2 毕 ， 但 Surface 还 没有 开始 
layout 中 被 显示 出 来 


窗口 绘制 请 求 已 经 提交 ， 
但 还 在 等 待 其 他 因素 。 这 
有 点 类 似 于 进程 已 经 处 于 
Ready 状 态 ， 随 时 等 竺 CPU 





分 配 时 间 片 后 执行 





我 们 以 图 10-11 来 形象 地 表示 上 面 的 Log 信 息 。 


mms RecentsPanel — SurfaceState=NO_ SURFACE 


StatusBar  SurfaceState=HAS DRAWN 


Keyguard SurtaceState=NO_ SURFACE 


Ms launcher? SurfaceState=HAS DRAWN 


ImageWallpaper SurfaceState=HAS DRAWN 





全 图 10-11 未 添加 Gallery 窗 口 前 WindowList 中 的 状态 


从 图 10-11 中 可 以 清晰 地 看 到 ， 当 前 拥有 Surface 的 只 有 3 个 应 用 ， 
即 StatusBar，1auncher2 和 lmageWal1paper; 而 且 此 时 Gallery 还 没有 
分 配 到 WindowState。 


Gallery 执 行 完 addWindow 后 ， 系 统 中 的 Wi ndowState 发 生 了 变化 ， 
如 图 10-12 所 示 。 


cestate=0 

WindowManager 1206, addwindow, end, i=4,w=Window(411£6280 StatusBar paused=false}, surfaces 
tate=4 

WindowManager 1206, addwindow, end, i=3, w=Window(412455a0 Keyguard paused=false},surfacest 
ate=0 

WindowManager 1206, addwindow, end, i=2,w=Window({4122d288 Starting com.android.gallery pau 


sed=false},surfacestate=0 
WindowManager 1206, addwindow, end, i=1, w=Window(413530f0 com.android.launcher/com.android 
.launcher2.Launcher paused=true},surfacestate=4 


WindowManager 1206, addwindow, end, i=0,w=Window(411cf648 com.android.systemui.ImageWallpa 


per paused=false},surfacestate=4 
全 图 10-12 ”添加 Gallery 窗 口 后 的 状态 


上 述 Log 信 息 中 ，“addwindow, end” 加 在 addWindow 函 数 的 末尾 ， 
表示 函数 执行 结束 后 的 变化 情况 。 


我 们 也 用 图 10-13 所 示 的 形式 表示 出 来 。 


f | RecentsPanel SurfaceState=NO SURFACE 


用 户 视 线 方 
[| StatusBar SuraceState=HAS DRAWN 


inn] Keyguard SurfaceState=NO SURFACE 


国 ol Surtacestate=NO SURFACE 


[AL /LL LL A umche SurfaceState-HAS DRAWN 


ROY ImageWallpaper SurfaceState=HAS DRAWN 





全 图 10-13 添加 Gallery 窗 口 后 WindowList 中 的 状态 


Gallery 和 Launcher2，1lmageWal1paper 的 窗口 类 型 属于 同等 级 。 根 
据 前 面 讲解 的 “层级 值 ”分 配 规则 ， 后 启动 的 应 用 程序 优先 级 高 ， 所 以 
gallery 最 终 排 在 了 1auncher2 和 壁纸 的 上 方 。 不 过 这 时 候 它 还 没有 申请 
到 Surface 这 个 工作 要 等 到 用 户 调 用 WMS 中 的 relayoutWindow 时 才 会 





实施 ; 而 且 我 们 要 注意 的 是 gallery 的 这 行 Log， 如 图 10-14 所 示 。 


WindowManager 1206, addwindow, end, i=2,w=Window{4122d288 Starting com.android.gallery pau 


sed=false},surfacestate=0 
A 10-14 gallery 的 这 行 Log 


LAA “Starting com. android. gallery” , JAR? 
为 当 新 窗口 即将 显示 前 注意: 并 不 是 所 有 新 窗口 都 有 启动 窗口 )， 
Android 系 统 会 自动 为 其 加 上 一 个 启动 窗口 ， 目 的 就 是 使 整个 启动 过 程 
sol aaa 从 而 增强 用 户 的 体验 。 我 们 会 在 稍 后 的 小 节 中 做 专门 
YIP Ao 

当 程 序 继续 运行 时 ， 会 进入 relayoutWindow 〈 人 参见 后 续 小 节 的 分 
析 ) 来 申请 Surface。 和 addWindow 中 的 处 理 一 样 ， 我 们 在 函数 
relayoutWindow 的 首尾 加 上 Log 来 进行 比较 。 


进入 relayoutWindow 时 ， 如 图 10-15 所 示 。 


WindowManager | 1206, relayoutWindow, before, i=2,w=Window(4124d458 Starting com.android.gal 


内 sed=fal } f tat -0 


全 图 10-15 进入 relayoutWindow 时 





结束 relayoutWindow 时 ， 如 图 10-16 所 示 。 


WindowManager | 1206,relayoutNindow,end, i=2,w=Window(4124d458 Starting com.android.galler 


y paused=false},surfacestate=1 
全 图 10-16 24 RrelayoutWindow At 


可 以 看 到 ，relayoutWindow 给 gallery 的 启动 窗口 分 配 了 Surface， 
因而 它 的 状态 变 为 DRAW_PENDING; 而 且 随 后 gallery 的 真正 窗口 也 会 通 
过 addWindow 来 申请 窗口 ， 如 图 10-17 所 示 。 


WindowManager | 1206,addwindow, end, i=6,w=Window(4124b848 RecentsPanel paused=false},surfa 
cestate=0 

WindowManager | 1206,addwindow, end, i=5,w=Window(41205cl0 StatusBar paused=false},surfaces 
tate=4 

WindowManager | 1206, addwindow, end, i=4,w=Window(4111c260 Keyguard paused=false},surfacest 
ate=0 

WindowManager | 1206,addwindow, end, i=3,w=Window(4124d458 Starting com.android.gallery pau 
sed=false},surfacestate=4 

WindowManager | 1206,addwindow, end, i=2,w=Window(4111f£120 com.android.gallery/com.android. 
camera.GalleryPicker paused=false},surfacestate=0 

WindowManager | 1206, addwindow, end, i=1,w=Window(410£8628 com.android. launcher/com.android 
.launcher2.Launcher paused=false},surfacestate=4 

WindowManager | 1206,addwindow, end, i=0,w=Window(41250c40 com.android.systemui.ImageWallpa 


per paused=false},surfacestate=4 


A10-17 通过 addWindow 来 申请 窗口 


此 时 整个 系统 中 就 有 7 个 窗口 存在 。 前 面 的 gal1ery 启 动 窗口 这 时 已 
经 显示 出 来 ， 而 新 增 的 gal lery 窗 口 的 Surface 状 态 为 NO_SURFACE。 很 明 
显 ， 它 后 面 也 要 通过 relayoutWindow 来 创建 一 个 可 用 的 Surface， 如 图 
10-18 所 示 。 


weWindow/4124dé58 Starting com.android.g 





全 图 10-18 通过 relayoutWindow 来 创建 一 个 可 用 的 Surface 


那么 ， 启动 窗口 在 什么 情况 下 消失 呢 ? 答案 就 是 当 gallery 的 真正 
BOA GARE 自动 窗口 就 可 以 “光荣 退休 ”了 。 另 外 ， 
我 们 还 可 以 从 这 些 Log 中 注意 到 gal lery 的 前 一 个 应 用 (Bl) |auncher2) 
的 变化 情况 ， 如 图 10-19 所 示 。 





in 


WindowManager | 1206,relayoutWindow begin,client= android.view. IWindow$Stub$Proxy@4131631 
Ar A 
Uc 


WindowManager | 1206,relayoutWindow,before,i=5,w=Window{4124b848 RecentsPanel paused=fals 


e}, surfacestate=0 


WindowManager 1206, relayoutWindow, before, i=4,w=Window({41205cl0 StatusBar paused=false}, 
surfacestate=4 


74.29% 


WindowManager | 1206, relayoutWindow, before, i=3,w=Window(4111c260 Keyguard paused=false},s 
urfacestate=0 

WindowManager 1206, relayoutWindow, before, i=2,w=Window({4111f£120 com.android.gallery/com 
android.camera.GalleryPicker paused=false},surfacestate=4 

WindowManager | 1206,relayoutWindow, before, i=1,w=Window(410f£8628 com.android.launcher/com 





全 图 10-19 gallety 的 前 一 个 应 用 〈 即 launchet2) 的 变化 情况 
图 中 第 一 个 方 框 描述 的 是 relayoutWindow 0 的 第 七 个 参数 ， 即 : 
public int relayoutWindow(Session session, IWindow client, in 
WindowManager.LayoutParams attrs, int requestedwWidth, 
int requestedHeight, int viewVisibility, int flags, 


Rect outFrame, Rect outOverscanInsets, Rect outContent 
Rect outVisibleInsets, Configuration outConfig, Surfac 


各 viewvisibility 的 状态 值 定义 如 表 10-8 所 示 。 


表 10-8 visibility 状态 值 〈 在 View. java 中 定义 ) 


| some | vate | becom | 
VISIBLE 0x00000000 当前 为 可 见 状态 


INVISIBLE |ox00000004 当前 不 可 见 ， 但 它 仍然 占据 空间 
GONE 0x00000008 中 不 可 见 ， 且 不 占据 空间 








此 时 relayoutWindow 执 行 的 是 “GONE” 请 求 ， 具 体 对 象 为 
launcher2。 最 终结 果 如 图 10-20 所 示 。 


WindowManager |1206, relayoutWindow, end, i=2, w=Window{4111f120 com.android.gallery/com.and 
roid.camera.GalleryPicker paused=false},surfacestate=4 
WindowManager | 1206,relayoutWindow, end, i=1,w=Window({410£8628 com.android.launcher/com.an 


| | atoid.launcher2,Launcher paused=false},surfacestate-0 00, 





全 图 10-20 结果 图 


可 见 ， 当 gallery 窗 口 显示 出 来 时 ，1auncher2 的 Surface 就 被 
destroy 掉 了 。 因 为 launcher2 此 时 已 经 完全 被 gallery 履 盖 ， 没 有 必要 
占用 Surface 资 源 。 


本 小 节 通 过 一 个 简单 的 例子 ， 向 读者 展示 了 应 用 程序 切换 过 程 中 
WMS 里 各 窗口 状态 的 变化 ， 还 包括 了 Surface 的 状态 变迁 。 建 议 读者 结合 
前 两 个 小 节 的 源码 来 综合 理解 。 


10.4 Surface t# 


通过 前 一 小 节 的 范例 ， 读 者 应 该 对 Surface GER: 这 里 说 的 是 
Java 层 的 Surface 类 ， 以 区 别 于 0penGL ES 的 本 地 窗口 Surface) 有 了 初 
步 的 印象 。 接 下 来 我 们 要 解决 如 下 问题 : 


e Surface 与 Window 的 区 别 ; 
e Surface 的 管理 ; 
e Surface 的 内 部 实现 。 


10.4.1 ”Surface 申请 流程 (relayout) 


WMS 原则 上 只 负责 管理 “窗口 ”的 层级 和 属性 ， 而 SurfaceFlinger 
才 是 真正 将 窗口 数据 合成 并 最 终 显 示 到 屏幕 上 的 系统 服务 。 由 此 可 见 ， 
WMS 在 对 窗口 〈 比 如 大 小 、Z-0rder) 做 出 调整 的 同时 ， 也 必须 要 通知 
SurfaceFlinger， 这 样 才能 把 正确 结果 及 时 地 呈现 给 “观众 ”。 


根据 SurfaceFlinger 中 学 习 过 的 知识 ，UI 丙 面 的 绘制 需要 有 “H 
板 ”， 即 BufferQueue 的 支持 。 所 以 无 论 是 系统 窗口 ， 还 是 应 用 窗口 ， 
都 必须 向 SurfaceF1inger 申 请 相应 的 Layer， 进 而 得 到 图 形 缓冲 区 的 使 
用 权 。 


那么 这 一 切 的 起 点 在 哪里 呢 ? 没 错 ， 还 是 在 ViewRoot 中 。 


当 ViewRoot 进 行 performTraversals 时 ， 会 向 WMS 申请 一 个 
Surface: 


/*frameworks/base/core/java/android/view/ViewRootIimpl. java*/ 
private void performTraversals() {.. 
relayoutResult = relayoutWindow(params, viewVisibility, inset 


} 

private int relayoutWindow(WindowManager.LayoutParams params, int 

boolean insetsPending) throws RemoteException {... 

int relayoutResult = mWindowSession.relayout ( 

mwWindow, mSeq, params, 
(int) (mView.getMeasuredwidth() * appScale + 0.5f), 
(int) (mView.getMeasuredHeight() * appScale + 0.5f) 
viewVisibility, insetsPending ? WindowManagerGlobal 


mWinFrame, mPendingOverscanInsets, mPendingContentI 
mPendingConfiguration, mSurface) ; 


当 ViewRoot 在 performTraversals 时 ， 如 果 发 现 是 第 一 次 执行 这 个 
郧 数 〈 或 者 窗口 的 可 见 性 、 大 小 等 属性 发 生 了 变化 ) ， 那 么 它 就 会 调用 
relayoutWindow。 从 名 称 可 以 看 出 ， 这 个 函数 会 “重新 布局 ”窗口 一 一 
简 而 言 之 ， 就 是 应 用 进程 通过 IWindowSession. relayout 来 让 WMS 辣 ] 
SurfaceF1inger 申 请 “画板 ”， 然 后 通过 上 述 代 码 段 中 的 mSurface 变 量 
将 结果 值 返 回 。 


要 特别 注意 这 个 mSurface 变 量 ， 实 际 上 在 ViewRoot 中 已 经 分 配 了 一 
个 初始 的 Surface 对 象 。 


private final Surface mSurface = new Surface(); 
既然 如 此 ， 为 什么 还 要 通过 WMS 再 分 配 一 次 呢 ? 


因为 初始 时 得 到 的 Surface 是 “ 空 达 ”。 换 名 话说， 其 内 部 没有 承 
载 UI 数据 的 “ 男 板 ”， 所 以 如 果 直 接 使 用 它 来 绘图 是 无 效 的 。 只 有 经 过 
relayout () 重新 赋值 后 ， 它 才 有 意义 。 


那么 ， 如 何 让 WMS 为 应 用 进程 分 配 一 个 有 效 的 Surface 呢 ? 


大 家 应 该 还 记得 在 SurfaceF1inger 章 节 中 ， 我 们 曾经 分 析 过 
GraphicBuffer 是 如 何在 应 用 进程 和 SurfaceFlinger 进 程 中 保持 高 度 一 
致 的 。 这 里 的 情况 类 似 ， 只 不 过 前 者 是 C++ 语言 实现 的 ， 而 后 者 则 是 通 
过 Java 语 言 编 写 的 。Java 层 的 Binder 服 务 通常 使 用 aidl 来 描述 ， 如 
IWindowSession. aid1。 其 中 relayout 的 函数 声明 如 下 : 


int relayout(IWindow window, int seq, in WindowManager .La 
int requestedWidth, int requestedHeight, int viewVisi 
int flags, out Rect outFrame, out Rect outOverscanIns 
out Rect outContentInsets, out Rect outVisibleInsets, 
out Configuration outConfig, out Surface outSurface); 


可 以 看 到 ，outSurface 这 个 参数 前 面 有 一 个 out 标 志 ， 说 明 它 是 一 
个 函数 出 参 。 一 旦 aidl 发 现 了 这 个 out 属 性 ， 它 就 会 做 特殊 处 理 。 具 体 
而 言 ， 就 是 当 aid1 工 具 生 成 java 文 件 时 ， 会 为 应 用 端的 proxy 和 服务 端 
的 Stub 考 虑 此 参数 的 parcable 因 素 。 具 体 如 下 所 示 。 


(1) Stub: 


android.view.Surface _arg11; 
_argii = new android.view.Surface(); // 新 建 一 个 Surface 对 象 
int _result = this.relayout(_arg0, _arg1, _arg2, _arg3, _arg4, a 

















if ((_argii!=null)) {// 对 _arg11( 即 Surface 对 象 ) 进 行 处 理 
reply.writeInt(1); 

_argii.writeToParcel(reply, android.os.Parcelable.PARCELABLE_WRITE 
} 


从 上 面 的 代码 片段 可 以 看 出 ， 服 务 器 首先 在 其 进程 空间 中 新 建 了 一 
个 Surface 对 象 ， 然 后 调用 WMS 来 为 这 个 对 象 赋值 。 但 是 这 个 对 象 和 客户 
端 最 终 收 到 的 对 象 并 不 是 同一 个 一 一 奥妙 在 函数 末尾 ， 也 就 是 我 们 调用 
了 _arg11 (BllSurface) 中 的 writeToParcel 方 法 。 这 也 同时 告诉 我 们 ， 
如 果 一 个 Class 类 希望 作为 aid1 函 数 中 的 out 参 数 ， 它 就 必须 要 继承 自 
Parcelable 并 实现 writeToParce1 这 一 关键 方法 。 对 于 Surface 来 说 ， 它 
对 这 个 接口 方法 的 实现 是 在 JNI 层 的 ， 即 android_view_Surface. cpp 
中 。 


(2) 与 上 面相 对 应 ， 客 户 端 就 必须 要 实现 readFromParcel 了 。 如 
TS: 


Proxy: 
public int relayout(.., android.view.Surface outSurface) throws an 


android.os.Parcel _reply = android.os.Parcel.obtain(); 
mRemote. transact (Stub. TRANSACTION _relayout, _data, _reply, 0);//xz 
if ((@!=_reply.readiInt())) { 


outSurface.readFromParcel(_reply) ;//i# M244 RE 
} 





至 于 两 边 的 Surface 对 象 又 是 如 何 保持 一 致 性 的 ， 其 基本 原理 和 
SurfaceFlinger 中 的 GraphicBuffer 类 似 ， 后 续 小 节 也 有 详细 解释 。 


接 下 来 我 们 深入 relayoutWindow 的 源码 实现 来 一 探究 竟 。 这 个 函数 
很 长 ， 大 家 重点 关注 它 对 Surface 对 象 的 处 理 。 根 据 上 面 的 分 析 ， 我 们 
能 推测 出 它 的 工作 分 为 两 种 情况 。 





。 viewVisibility 4 VISIBLE BY lf J 


这 种 情况 下 ， 用 户 请 求生 成 一 个 用 于 显示 的 有 效 Surface 如 前 一 
小 节 范 例 中 的 gallery) 。 





。 viewVisibility 为 GONE 的 情况 


这 种 情况 通常 意味 着 窗口 即将 退出 显示 ， 因 而 就 要 销毁 用 户 已 经 持 
有 的 Surface 《如 前 一 小 节 范 例 中 的 launcher2) 。 


本 小 节 集 中 分 析 viewVisibility 为 VISIBLE 的 情况 : 


public int relayoutWindow(Session session, IWindow client, in 

WindowManager.LayoutParams attrs, int requestedWidth, 
int requestedHeight, int viewVisibility，// 窗 口 可 见 性 请 
int flags, Rect outFrame, Rect outOverscanInsets, Rec 
Rect outVisibleInsets, Configuration outConfig, Surfa 

boolean toBeDisplayed = false;// 此 窗口 是 否 要 显示 ， 由 多 个 因素 决 

boolean inTouchMode; 

boolean configChanged;// 配 置 是 否 发 生 了 变化 

boolean surfaceChanged = false;//Surface 是 否 发 生 了 变化 

boolean animating; 























synchronized(mWindowMap) {// 访 问 到 共享 资源 ， 注 意 同步 
WindowState win = windowForClientLocked(session, clien 


WindowStateAnimator winAnimator = win.mWinAnimator ;//# 

if (win.mRequestedwidth != requestedwidth|| win.mReque 
win.mLayoutNeeded = true;// 尺 寸 发 生变 化 ， 需 要 重新 layou 
win.mRequestedwidth = requestedWidth; 
win.mRequestedHeight = requestedHeight; 


} 
…// 对 于 窗口 属性 等 因素 的 调整 ， 代 码 省 略 
if (viewVisibility == View.VISIBLE && (win.mAppToken == 
|| !win.mAppToken. clientHidden)) { 
toBeDisplayed = !win,isVisibleLw();// 假 如 已 经 是 可 见 状 














if (toBeDisplayed) {// 如 果 最 终 的 判断 结果 是 需要 显示 
if (win.isDrawnLw() && okToDisplay()) { 

winAnimator.applyEnterAnimationLocked( ) ; 
} 











} 


try { 


if (!win.mHasSurface) { 
surfaceChanged = true; 


} 

SurfaceControl surfaceControl = winAnimator.cr 

if (surfaceControl != null) { 
outSurface.copyFrom(surfaceControl) ;//4Eh 

} else { 


outSurface ,release();// 生 成 Surface 失 败 
} catch (Exception e) 4.. 
} 
} 
} else {..//viewVisibility 不 是 VISIBLE 的 情况 
} 


per formLayoutAndPlaceSurfacesLocked(): 





这 


设想 一 下 这 个 函数 将 会 遇 到 的 情况 : 





。 首先 它 需 要 判断 这 个 窗口 是 否 要 显示 。 这 既 取 决 于 入 参 中 
viewVisibility 的 具体 请 求 ， 同 时 也 取决 于 这 个 窗口 状态 是 否 适 合 
visible 状 态 以 及 当前 是 否 已 经 为 visible(isVisibleLw)。 最 终 的 判断 结果 
由 toBeDisplayed 表 示 。 

。 如 果 是 要 显示 的 窗口 ， 那 么 它 就 得 有 合法 的 Surface。 因 而 如 果 这 个 
窗口 之 前 还 未 持 有 Surface 或 者 Surface 的 属性 已 经 发 生 了 改变 ， 那 就 
要 重新 申请 。 最 终 的 判断 结果 由 surfaceChanged 来 表示 。 

。 除 此 之 外 ， 它 还 要 判断 配置 是 否 变 更 ， 以 configChanged 来 表示 。 

。 如 果 当 前 正在 进行 动画 ， 情 况 又 会 稍微 不 同 ，animating 用 于 记录 这 
种 情况 。 

e。 函数 参数 中 ，tequestedYidth 和 tequestedHeight 表 示 用 户 请 求 的 宽 
高 ， 这 将 影响 它 申 请 到 的 Surface 的 属性 。 最 后 几 个 以 “out 开头 的 
变量 表明 它们 也 是 出 参 ， 如 outFrame，outSurface 等 。 

















ek re layoutWindowky 4M mW i ndowMap# ER E Scl ient 对 应 的 
WindowState 对 象 ， 即 调用 windowForClientLocked 国 数 。 在 判断 窗口 是 
否 visible 时 ， 主 要 的 依据 是 Surface 状 态 、 是 否 正在 进行 退出 动画 等 。 


注意 如 果 窗 口 当 前 已 经 是 visible 就 不 用 再 显示 了 ， 因 而 toBeDi splayed 
是 取 反 操作 。 


假如 当前 窗口 正在 执行 退出 动画 ， 或 者 它 已 经 进入 destroy 列 表 ， 
就 要 撤销 这 些 操 作 。 另 外 ， 如 果 之 前 的 状态 是 GONE， 我 们 还 要 执行 一 个 
进入 动画 。 这 一 部 分 工作 由 WindowStateAnimator 来 全 权 负 责 ， 每 一 个 
WindowState 中 都 有 一 个 mWinAnimator 来 处 理 这 些 动画 效果 。 我 们 将 在 
后 面 小 节 专 门 介绍 其 中 的 实现 细节 。 


如 果 确 定 窗口 即将 要 显示 ， 还 需要 执行 一 系列 前 期 的 准备 操作 ， 如 
显示 数据 是 否 准备 好 、 屏 幕 是 否 开 启 、 配 置 是 否 有 变化 等 ; 而 且 假如 图 
形 格 式 改变 ， 即 便 之 前 已 经 有 可 用 的 Surface 也 要 重新 创建 一 一 这 种 情 
况 下 必须 先 destroy 老 的 Surface， 然 后 设置 surfaceChanged 为 true。 
形 格式 由 android. graphics. PixelFormat 定 义 ， 默 认 是 OPAQUE (表示 不 
需要 alpha 通 道 ) 。 


整个 函数 用 于 配置 和 判断 的 内 容 占 了 很 大 一 部 分 篇 幅 ， 真 正 的 核心 
操作 如 下 。 


e 生成 Sutface。 

。 分配 层 值 (如果 需 要 的 话 ) 。 有 两 种 窗口 可 能 会 导致 层级 值 的 重新 
分 配 ， 即 JIM 窗口 和 壁纸 窗口 。 

e performLayoutAndPlaceSurfacesLocked (后 面 小 节 有 专门 介绍 ) o 


WMS 并 没有 在 内 部 直接 生成 可 用 的 Surface 对 象 ， 而 是 在 
WindowStateAnimator 中 提供 了 create SurfaceLocked 这 个 接口 ; 同 
理 ，Destroy Surface 的 接口 也 必定 在 这 个 类 中 ， 即 


destroySur faceLocked: 





/*frameworks/base/services/java/com/android/server/wm/windowState 
Surface createSurfaceLocked() { 


if (mSurfaceControl == null) {.. 
mDrawState = DRAW_PENDING;// 状 态 改变 了 
try 


{ 
if (DEBUG_SURFACE_TRACE) {//DEBUG 时 走 这 个 分 支 


} else { 
mSurfaceControl = new SurfaceControl(mSession 
attrs.getTitle().toString(),w, h, format, 


mwWin.mHasSurface = true; // 已 经 有 可 用 的 Surface 了 
} catch (SurfaceControl.OutOfResourcesException e) { 


} catch (Exception e) { 





} 
Surface.openTransaction();// 开始 一 个 Transaction， 后 续 小 : 
try { 

try { 

..//Transaction 的 中 间 过 程 

} catch (RuntimeException e) { 
} finally { 

Surface.closeTransaction();//Transaction# R 
} 


return mSurface; 


} 


和 我 们 的 预想 不 一 样 的 地 方 是 : createSurfaceLocked 也 没有 直接 
与 SurfaceFlinger 产 生 交集 。 从 罗 辑 上 来 分 析 ， 这 个 函数 做 了 两 件 事 : 


e new Surface; 


e openTransaction/closeTransaction. 


看 来 所 有 的 秘密 都 包含 在 这 两 个 步骤 中 ， 我 们 将 在 下 一 小 节 继 续 分 
析 。 


10.4.2 ”Surface 的 跨 进 程 传递 


在 Android 的 GU1 系 统 中 ， 与 Surface 相 关 的 类 有 很 多 ， 如 
Surface. cpp, Surface. java、1|surface、|1|GraphicBufferProducer 
等 。 我 们 在 SurfaceFlinger 章 节 曾 专门 针对 这 些 类 做 过 比较 ， 希 望 读者 
可 以 区 分 清楚 。 


对 于 Java 层 的 应 用 程序 来 说 ，Surface. java 是 它们 直接 使 用 的 绘 
“画板 ”一 一 而 这 个 Java 层 的 Surface 对 象 则 需要 间接 调用 底层 接口 
来 完成 功能 ， 包 括 Surface (C++) 、1SurfaceComposer 等 与 
SurfaceFlinger 交 互 沟通 的 地 方 都 是 在 本 地 层 实现 的 ， 如 图 10-21 所 
/小 。 


根据 “Surface 申 请 流程 ”中 的 分 析 ，Surface (Java) 对 象 在 两 个 地 
方 会 被 创建 。 即 : 


e ViewRootImpl 


对 应 的 是 ViewRoot1mp1 的 成 员 变 量 mSurface， 而 且 它 在 一 开始 就 分 
配 了 一 个 “ 空 ” 的 Surface 对 象 。 


Java Surface 


INI _ 
android view Surface 
| 
ee Surface SurfaceF linger 
| 


全 图 10-21 Sutface 的 实现 重点 





e WindowStateAnimator 


当 WMS 调 用 Wi ndowStateAnimator AcreateSurfaceLockedB}, J$ 
成 一 个 真正 有 效 的 Surface 对 象 ， 且 由 其 成 员 变 量 mSurfaceControl 管 
下: 


那么 ， 为 什么 说 ViewRootImp1 初 始 生成 的 Surface 对 象 是 “ 空 ” 的 
We? 要 明白 这 个 问题 ， 就 得 从 Surface 的 初始 化 入 手 。Surface 的 构造 函 
数 主要 有 如 下 3 种 形式 : 


(1) public Surface () ; 
(2) public Surface (SurfaceTexture surfaceTexture) ; 


(3) private Surface (int nativeOb ject) 。 


其 中 ViewRoot Imp1 为 mnSurface 初 始 化 时 采用 的 是 第 一 种 ， 即 完全 不 
带 参 数 的 情况 : 


private final Surface mSurface = new Surface(); 


而 Wi ndowStateAnimator 中 采用 的 则 是 通过 SurfaceControl1 间 接生 
成 Surface 的 方式 : 


mSurfaceControl = new SurfaceControl(mSession.mSurfaceSession, 
attrs.getTitle().toString(),w, h, format, fl 


这 两 者 最 大 的 区 别 ， 融 是 后 一 个 构造 函数 还 会 同时 调用 名 称 
为 “nativeCreate” 的 本 地 方法 这 其 实 就 是 Surface 与 
SurfaceFlinger 建 立 联系 的 入 口 。 而 Java 层 的 Surface 类 充其量 只 是 一 
个 “ 壳 ”， 它 的 所 有 功能 都 是 通过 JN1 调 用 各 种 本 地 类 来 实现 的 : 


/*frameworks/base/core/jni/android_view_SurfaceControl.cpp*/ 
static jint nativeCreate(JNIEnv* env, jclass clazz, jobject sessi 
jstring nameStr, jint w, jint h, jint format, jint flags) 
ScopedUtfChars name(env, nameStr); 
sp<SurfaceComposerClient> client(android_view_SurfaceSession_ 
sp<SurfaceControl> surface = client->createSurface(String8(na 
w, h, form 





surface->incStrong((void *)nativeCreate); 
return int(surface.get()); 


这 里 出 现 了 我 们 熟悉 的 SurfaceComposerClient 它 是 
SurfaceFlinger 派 出 的 “代表 ”。 不 论 是 0penGL ES 还 是 本 小 节 的 
Surface， 都 可 以 在 这 个 类 的 协助 下 有 序 地 申请 和 访问 各 Buffer 缓 冲 





区 。 


上 述 代 码 段 中 直接 利用 android view SurfaceSession getCl ient 
来 获取 到 client 对 象 ， 这 说 明 在 其 他 地 方 已 经 创建 了 这 个 对 象 ， 并 且 通 
过 JNI 将 其 保存 在 了 Java 层 中 。 具 体 过 程 是 当 addWi ndow 被 调用 时 ，WMS 
会 为 窗口 建立 一 个 WindowState， 并 将 Session 保 存 到 它 的 成 员 变 量 
mSession 中 。 紧 接着 WindowState. attach (被 调用 ， 此 时 mSession 就 通 
过 windowAddedLocked 来 进一步 生成 mSurfaceSession; 当 WindowState 
构造 时 ， 它 同时 生成 内 部 的 mWinAnimator， 妈 WindowState Animator. 
后 者 在 构造 时 也 将 Session 对 象 保存 在 mSession 成 员 变量 中 。 这 个 变量 
将 在 createSurfaceLocked 中 传递 给 Surface 的 构造 国 数 。 这 其 中 的 关系 
有 点 杂乱 ， 我 们 特别 扩充 本 节 开 头 的 实现 图 以 完整 理解 ， 具 体 如 图 10- 
22 所 示 。 


通过 这 个 图 再 来 理解 nativeCreate， 相 信 读 者 就 清楚 多 了 。 


大 家 可 能 还 有 个 疑问 : 既然 ViewRootImp1 中 的 mSurface 一 开始 
是 “ 空 ” 的 ， 那 么 后 来 又 是 如 何 变 成 可 用 的 呢 ? 回答 这 个 问题 需要 结合 
前 一 小 节 relayoutWindow 中 的 分 析 。 前 面 已 经 看 到 ， 当 WMS 端 生 成 一 个 
Surface 后 ， 它 会 通过 writeToParce1 写 入 回复 reply 中 。 这 样 当 
ViewRoot 在 读 取 结 果 值 时 ， 就 可 以 利用 readFromParce1 再 把 它 还 原 出 
来 。Surface (Java) 的 readFromParce1 将 进一步 调用 JN1 方 法 
nativeReadFromParcel, BJ: 


/*frameworks/base/core/jni/android_view_Surface.cpp*/ 
static jint nativeReadFromParcel(JNIEnv* env, jclass clazz, jint 
Parcel* parcel = parcelForJavaObject(env, parcelObj); 


sp<Surface> self(reinterpret_cast<Surface *>(nativeObject)); 
sp<IBinder> binder (parcel->readStrongBinder()); 


sp<Surface> sur; 
sp<IGraphicBufferProducer>gbp(interface_cast<IGraphicBufferPr 
if (gbp != NULL) { 
sur = new Surface(gbp);// 本 地 的 Surface 对 象 与 TGraphicBufferP 
sur ->incStrong(&sRefBaseOwner ) ; 


} 
return int (sur .get());// 这 个 最 终 返 回 的 Surface(C++) 对 象 就 是 有 效 的 


这 样 客 户 端的 Surface 与 一 个 lgraphicBufferProducer 就 成 功 地 建 
立 了 关系 ， 而 后 者 就 是 Buffer 的 管理 者 ， 所 以 后 续 在 此 Surface 基 础 上 
的 U1 操作 最 终 可 以 通过 SurfaceF1inger 显 示 到 屏幕 上 。 


mSurfaceSession mSession 


mWinAnimator 


Send rol 


mNativebject 


mNativeClient 





A 10-22 Surface 关 系 详 图 


10.4.3 Surface 的 业务 操作 


在 前 两 个 小 节 分 析 WindowStateAnimator. createSurfaceLocked () 
时 ， 我 们 发 现 这 个 函数 的 末尾 在 对 SurfaceControl1 进 行 操作 前 ， 首 先是 
openTransaction， 最 后 结束 时 再 closeTransaction。 这 部 分 代码 摘录 
如 下 : 


SurfaceControl.openTransaction(); 


mSurfaceControl.setLayerStack(mLayerStack); 
mSurfaceControl.setLayer(mAnimLayer ); 
mSurfaceControl.setAlpha(0O) >... 
SurfaceControl.closeTransaction()j; 


那么 ， 这 样 做 的 目的 是 什么 ? 


SurfaceControl 提 供 的 这 两 个 方法 都 分 别 调用 了 对 应 的 native 本 地 
方法 ， 它 们 的 实现 在 JN1 层 : 


/*frameworks/base/core/jni/android_view_SurfaceControl.cpp*/ 

static void nativeOpenTransaction(JNIEnv* env, jclass clazz) { 
SurfaceComposerClient: :openGlobalTransaction(); 

} 


static void nativeCloseTransaction(JNIEnv* env, jclass clazz) { 
SurfaceComposerClient: :closeGlobalTransaction(); 
} 


其 中 openGl1obalTransaction 的 调用 流程 是 : 


SurfaceComposerClient::openGlobalTransactionComposer::openGlobalT 
Composer::getIinstance().openGlobalTransactionImpl: 
void Composer::openGlobalTransactionImpl() { 
{ // scope for the lock 
Mutex: :Autolock _1(mLock); 
mTransactionNestCount += 1; 


而 SurfaceComposerClient: :closeGlobal Transaction () 最 核心 的 
语句 是 其 在 函数 末尾 调用 了 1surface 
Composer : :setTransactionState () 这 个 接口 。 换 名 话说 ， 对 于 


openGlobal Transaction#llcloseGlobal Transaction 之 间 的 所 有 设置 

Surface 属 性 的 操作 ， 如 setSize，setLayer，setPosition 等 ， 都 不 是 
及 时 生效 的 ， 而 是 要 等 到 业务 关闭 后 才 统 一 告知 SurfaceF1inger。 对 于 
频繁 变更 属性 的 地 方 ， 这 样 做 一 方面 可 以 提高 效率 ， 另 一 方面 可 以 避免 
属性 的 过 快 更 新 带 来 一 些 负面 影响 ， 如 画面 不 稳定 。 


10.5 performLayoutAndP | aceSur facesLocked | nner 


前 面 我 们 在 分 析 relayoutWindow 时 ， 还 有 一 个 重要 函数 没有 讲解 ， 
就 是 performLayoutAnd 
PlaceSurfacesLockedlnner (performLayoutAndPlaceSurfacesLocked 
最 终 会 调用 这 个 函数 ) 。 可 以 说 这 是 整个 WindowManagerService 中 行 数 
最 长 、 最 难 理解 ， 却 也 是 最 核心 的 一 个 函数 ， 所 以 有 必要 专门 用 一 个 小 
节 来 对 它 做 详细 解析 。 


从 函数 名 大 概 可 以 猪 出 它 的 设计 意图 ， 即 Perform Layout 和 Place 
Surface。Layout 在 这 里 侧重 表达 的 是 “尺寸 大 小 ”的 意思 ， 即 每 个 窗 
口 所 占 的 空间 ; 后 者 则 与 SurfaceF1inger 有 关 一 一 WMS 是 “导演 ”， 它 
需要 将 自己 的 意图 告诉 “摄影 机 ” (SurfaceFlinger) 。 换 句 话 说， 观 
众 最 终 看 到 的 画面 是 由 SurfaceFlinger 呈 现 出 来 的 ， 从 中 才能 领悟 

“导演 ”的 “思想 ”。 大 家 可 以 体会 下 这 其 中 的 因果 关系 。 


按照 惯例 ， 我 们 先 将 函数 的 “骨架 ” 列 出 来 : 


/*frameworks/base/services/java/com/android/server/wm/WindowManag 
private final void performLayoutAndPlaceSurfacesLockedInner( bool 
SurfaceControl.openTransaction(); //Fia/KAWASM VE I) 2 


try 4.. 
int repeats = 0; 
do { V*Step1， 第 一 个 循环 ， 处 理 pendingLayoutChangeSs*/ 
repeatst++; 
if (repeats > 6) {// 最 多 尝试 次 数 
displayContent.layoutNeeded = false; 
break; 


} 


if (repeats < 4) {/*Step2., 计 算 窗 口 大 小 ， 如 果 需 要 的 话 */ 
performLayoutLockedInner (displayContent, repe 
} else { 
Slog.w(TAG, "Layout repeat skipped after too m 


} 
/*Step3. 将 Policy 应 用 到 各 窗口 */ 
if (isDefaultDisplay) { 
mPolicy.beginPostLayoutPolicyLw(dw, dh); 
for (i = windows.size() - 1; i >= 0; i--) { 
WindowState w = windows.get(i); 
if (w.mHasSurface) { 
mPolicy.applyPostLayoutPolicyLw(w, w. 


i; 


displayContent.pendingLayoutChanges |= 
mPolicy.finishPost 


} 
} while (displayContent.pendingLayoutChanges != 0); 


final int N = windows .size();// 所 有 窗口 的 数量 
for (i=N-1; i>=0; i--) { /*Step4. 动画 相关 */ 


} 
} catch (RuntimeException e) { 


} finally { 
SurfaceControl.closeTransaction();// 上述 的 各 计算 结果 统一 
} 


/***** 接 下 来 就 是 收尾 工作 了 ***/ 
//Step5. 执行 应 用 间 切 换 (app transition) 
//Step6. 销毁 所 有 不 再 可 见 的 窗口 


//Step7 ， 是 否 需 要 移 除 已 经 退出 的 tokens? 














//Steps. 是 否 需要 移 除 退 出 的 应 用 程序 ? 


scheduleAnimationLocked()， 


整个 函数 逻辑 分 为 两 部 分 : 其 中 try…catch 中 的 代码 是 对 窗口 的 变 
更 进行 计算 ， 并 通过 SurfaceControl1 应 用 到 SurfaceFlinger 中 的 过 程 ; 
剩余 部 分 代码 则 是 做 些 收尾 工作 ， 使 WMS 中 的 窗口 状态 与 当前 系统 保持 
一 致 ， 如 移 除 某 些 无 用 的 窗口 、 移 除 相应 的 token 等 。 


Step1-3@performLayoutAndPlaceSurfacesLockedlnner 。 这 个 


do... whi le 循环 的 判断 条 件 是 : 


displayContent.pendingLayoutChanges != 0 


也 就 是 说 ， 它 在 执行 完 一 轮 操作 后 ， 会 根据 pendingLayoutChanges 
来 得 出 当前 是 否 还 有 “pending” “未 处 理 ) BY “Layout 
Chanages” 一 一 是 的 话 就 继续 循环 (但 最 多 不 超过 6 次 。 至 于 为 什么 是 6 
次 ， 估 计 是 源码 作者 的 经 验 之 谈 ) ; 否则 就 结束 循环 。 


而 pendingLayoutChanges 在 每 轮 循环 的 末尾 将 由 
mPol icy. finishPostLayoutPol icyLw 重 新 赋值 。 这 其 中 涉及 很 多 细节 问 
题 ， 我 们 将 在 后 续 小 节 解 释 窗口 大 小 的 计算 过 程 时 统一 讲解 。 


Step4@performLayoutAndPlaceSurfacesLockedlnner。 动 画 相 关 的 
计算 与 判断 ， 我 们 将 在 后 续 小 节 专 门 介绍 。 


Step5-8@performLayoutAndPlaceSurfacesLockedlnner， 收 尾 工 
作 。 这 部 分 内 容 比较 简单 ， 读 者 可 以 自行 阅读 。 


最 后 ， 函 数 末 尾 通 过 scheduleAnimat ionLocked 来 安排 动画 的 执 
行 。 因 为 Project Butter 规 定 珊 面 刷新 要 以 VSYNC 为 标准 ， 动 画 的 实施 
也 不 例外 它 提 供 了 一 个 mAnimator. mAnimation Runnable 来 监听 
VSYNC 信 和 号。 关于 窗口 动画 的 更 多 细节 ， 可 以 参考 后 续 小 节 。 





10.6 窗口 大 小 的 计算 过 程 


这 一 小 节 我 们 以 Activity 的 窗口 为 例 ， 完 整地 分 析 窗 口 大 小 的 计算 
过 程 ， 如 图 10-23 所 示 。 


在 Android 系 统 中 ， 通 常 在 终端 屏幕 上 看 到 的 页面 除了 应 用 程序 本 
身 的 内 容 外 ， 至 少 还 可 能 有 以 下 两 个 元 素 ， 如 图 10-23 所 示 。 


= New message 
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全 图 10-23 状态 栏 、 输 入 法 窗口 与 应 用 窗口 的 关系 (短信 编辑 ) 
e。 状态 栏 


如 果 应 用 程序 没有 特别 指明 需要 全 屏 显 示 ， 则 状态 栏 默认 是 存在 
的 。 这 也 就 意味 着 对 于 一 块 width#he ight 的 物理 屏幕 ， 实 际 上 可 以 分 配 
给 应 用 程序 的 空间 尺寸 肯定 是 要 小 于 (或 者 等 于 ) 这 个 范围 的 。 


。 输 入 法 窗口 


开发 人 员 在 配置 Activity 的 AndroidManifest. xm| 时 ， 可 以 特别 指 
定 输入 法 窗口 出 现时 ， 应 用 程序 本 身 的 表面 是 否 要 “缩小 ”， 以 腾 出 相 
应 的 位 置 来 容纳 输入 法 键盘 。 这 个 属性 称 为 windowSoft1nputMode， 如 
下 : 


<activity ..android:windowSoftInputMode=["stateUnspecified", "state 
"stateHidden", "stateAlway 

"stateVisible", "stateAlwa 

"adjustUnspecified", "adjustResize", "adj 


</activity> 


windowSoft1nputMode 属 性 的 可 选 值 分 为 两 类 一 一 以 state 开 头 的 部 
分 表示 当 activity 成 为 焦点 时 软 键盘 是 隐藏 或 者 可 见 ; 以 adjust 开 头 的 
值 则 表示 如 何 调整 activity 窗 口 以 容纳 软 键盘 。 所 以 这 两 种 类 型 的 配置 
值 是 “或 ”的 关系 ， 如 表 10-9 所 示 。 


表 10-9 windowSoftlnputMode 的 可 选 参 数 


stateUnspecified 





adjustUnspecified 


输入 法 软 键盘 的 状态 没有 特别 指定 。 这 意味 
者 系统 将 目 动 选择 合适 的 状态 值 ， 或 者 依赖 
于 主题 设置 


软 键盘 状态 取决 于 它 上 一 次 保存 的 值 


设置 这 个 值 ， 软 键盘 会 在 菜 些 场景 下 隐藏 





(比如 当 用 户 启动 了 activity， 而 不 是 因为 退 
出 男 一 个 activity 后 从 ActivityStack 返 回 的 情 
况 ) 


没有 指定 activity 窗 口 是 否 要 腾 出 空间 来 容纳 
EX ETL 系统 会 日 动 选择 合适 的 模式 。 如 果 
窗口 内 容 可 以 滚动 〈 滚 动 条 ) ， 即 在 很 小 的 


空间 里 也 能 浏览 所 有 内 容 ， 那 么 窗口 大 小 会 
被 重新 设置 


口 总 是 会 被 重新 设置 大 小 ， 以 容纳 





Activity 窗 口 大 小 不 会 改变 ， 但 窗口 内 容 需 要 
做 适当 调整 ， 以 保证 用 户 可 以 及 时 看 到 自己 
的 输入 结果 





由 上 面 的 分 析 可 知 ， 状 态 栏 和 输入 法 窗口 都 会 影响 应 用 程序 窗口 大 
小 的 计算 。 前 者 所 占 的 区 域 相对 固定 ; 输入 法 窗口 的 表现 则 取决 于 
Activity 属 性 的 设置 。 大 家 可 以 试 着 对 比 上 一 个 “短信 编辑 窗口 ”和 下 
面 的 “通讯 录 编辑 窗口 ”， 如 图 10-24 所 示 。 
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AW 10-24 输入 法 窗口 覆盖 了 应 用 窗口 的 部 分 区 域 (通讯 录 编 辑 ) 


窗口 大 小 从 理论 上 讲 只 有 宽 和 高 两 个 参数 。 不 过 从 程序 设计 的 角度 
来 考虑 ，ViewRoot1mp1 还 包括 了 如 表 10-10 所 示 的 相关 变量 。 


表 10-10 ViewRoot1mp1 中 与 窗口 大 小 相关 的 变量 





me 





int mWidth; 当前 真实 的 宽 和 高 
int mHeight; 


当 Activity 的 窗口 大 小 需要 改变 时 ， 
Rect mWinFrame; WMS 通过 W.resized 接 口 通知 客户 端 ， 
mWinFrame 就 用 于 记录 WMS 提供 的 宽 高 


Rect 同上 。 也 是 WMS 提供 的 ， 用 于 表示 可 见 
mPendingVisibleInsets | 中 区域 


Rect 同上 。 也 是 WMS 提供 的 ， 用 于 表示 内 容 
mPendingContentInsets}[X sk 


HesiredWindowWiath | 中 间 值 ， 用 于 表示 "期 望 "的 宽 高 值 ， 所 
以 和 最 终 的 值 可 能 有 差异 。 后 面 我 们 还 
aides tare 

desiredWindowHeight 





Contentlnsets 通 俗 地 讲 是 用 于 显示 应 用 窗口 “内 容 ” 的 区 域 ; 而 
Visiblelnsets 就 是 应 用 窗口 “可 见 ” 的 部 分 。 一 般 情 况 下 ， 二 者 是 一 
致 的 。 不 过 既然 ViewRoot 把 它们 分 为 两 个 变量 ， 就 说 明 它 们 肯定 并 非 完 
全 等 同 。 比 如 前 面 “ 短 信 编 辑 ” 珊 面 ， 当 输入 法 窗口 出 现时 应 用 窗口 便 
减 小 自身 尺寸 来 容纳 软 键盘 ， 所 以 内 容 和 可 见 区 域 是 一 样 的 ，“ 通 讯 录 
编辑 ”的 情况 则 正好 相反 。 应 用 窗口 选择 不 改变 原来 大 小 ， 所 以 它 
的 “内 容 ” 区 域 没有 变化 ， 只 是 软 键盘 覆盖 了 它 的 部 分 可 见 区 域 ， 此 时 
二 者 的 值 就 不 一 致 了 。 


ViewRoot1mp1 会 在 应 用 程序 运行 过 程 中 多 次 调用 
performTraversals 《后 一 章节 有 详细 介绍 ) ， 这 同时 也 是 计算 应 用 窗 
口 大 小 的 起 点 。 假 如 是 第 一 次 调用 这 个 函数 (mFirstAtrue) ， 那 么 
desiredWindowWidth/desiredWindowHeight 的 默认 值 就 是 物理 屏幕 大 小 
或 者 状态 栏 的 配置 大 小 〈 如 果 窗 口 类 型 为 TYPE_ STATUS BAR PANEL) 。 


此 时 程序 会 调用 host. f itSystemWindows (mF itSystem Windows|nsets) 
来 设置 4 个 内 边 距 ， 其 中 mF itSystemWindowslnsets 的 取 值 来 源 于 
mAttachlnfo. mContentlnsets， 后 者 和 mPendingContentlnsets 表 达 的 
是 同一 个 含义 ， 只 不 过 它 是 当前 窗口 的 真实 值 。 


疯 数 fitSystemWindows 被 用 来 通知 一 个 窗口 的 content inset 发 生 
了 改变 ， 以 使 View 有 机 会 来 适应 最 新 的 变化 。 它 会 沿 着 View Tree 由 上 
往 下 传递 给 各 View 对 象 。 通 常情 况 下 ， 开 发 人 员 并 不 需要 针对 这 一 变化 
做 特别 处 理 ， 但 使 用 以 下 两 个 属性 除外 : 


SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN 
SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION 


为 什么 呢 ? 我们 知道 ，View 组 件 可 以 通过 
setSystemUiVisibility (int) 来 决定 系统 U1 (包括 状态 栏 、 导 航 栏 等 ) 
的 显示 状态 。 其 中 有 两 对 容易 混淆 的 值 : 


SYSTEM_UI_FLAG_FULLSCREEN/SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN SYSTEM 


从 名 称 来 看 ， 它 们 只 相差 “LAY0UT” ， 但 实际 含义 却 有 很 大 不 同 。 
前 者 〈 不 带 LAYOUT) 的 值 表 示 用 户 要 求全 屏 
(SYSTEM UI FLAG FULLSCREEN) 或 者 隐藏 导航 栏 
(SYSTEM_UI_FLAG_HIDE_NAVIGATION) ， 这 样 最 终 的 界面 中 就 会 是 全 屏 
或 者 不 显示 导航 栏 。 在 这 种 情况 下 ， 应 用 程序 的 “内 容 区 域 ” 就 要 扣除 
这 些 系统 窗口 所 占 的 位 置 ; 而 后 者 则 只 “假设 ”当前 已 经 是 全 屏 
(SYSTEM UI FLAG LAYOUT FULLSCREEN) 或 者 已 经 隐藏 了 导航 栏 
(SYSTEM UI FLAG LAYOUT HIDE NAVIGATION) 。 


对 比如 图 10-25 所 示 。 


从 图 中 应 该 能 想到 ， 使 用 SYSTEM_U1_FLAG_LAYOUT_FULLSCREEN 标 志 
有 可 能 导致 部 分 应 用 帘 面 被 遮挡 一 一 而 有 了 时候 这 就 是 我 们 想 要 的 效果 。 
比如 状态 栏 是 半 透 明 的 ， 或 者 部 分 区 域 全 透明 ， 那 么 设置 这 个 属性 就 可 
以 让 用 户 透 过 状态 栏 看 到 后 面 的 UI 珊 面 ; 否则 状态 栏 中 透明 的 那 部 分 区 
域 就 会 是 黑色 的 ， 从 而 影响 用 户 体验 。 
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全 图 10-25 SYSTEM_UI_FLAG_FULLSCREEN feSYSTEM_UI_FLAG_LAYOUT_FULLSCREEN 


对 于 不 希望 界面 被 遮挡 的 应 用 程序 ， 我 们 就 需要 改写 
View. fitSystemWindows ( 以 避免 出 现 类 似 情况 。View 内 部 通过 
mPaddingLeft, mPaddingTop，mPaddingRight 和 mPaddingBottom 来 记录 
内 容 区 域 。 


我 们 再 回 到 performTraversals 函 数 的 分 析 中 。 假 如 当前 不 是 第 一 
次 调用 这 个 国 数 (mFirst 为 false) ， 那 么 desiredWindowWidth 和 
desi redWindowHei ght 就 分 别 等 于 mWinFrame. width () 和 
mWinFrame. height () 。 换 句 话说 ， 这 两 个 变量 表达 的 是 WMS 
的 “desire”。 一 旦 “期 望 值 ”与 当前 的 mWidthymHei ght 不 一 致 ， 那 么 
mFul |RedrawNeeded, mLayoutRequested#iwindowS i zeMayChangeRL a #& 





置 为 true， 这 将 影响 到 后 面 的 程序 流程 。 


水 数 performTraversal ( 中 有 一 个 核心 的 判断 ， 基 于 如 下 几 个 条 
件 : 


if (mFirst || windowShouldResize || insetsChanged ||viewVisibilit 


这 几 个 条 件 有 任何 一 项 满足 ， 就 说 明 窗口 的 尺寸 或 者 关键 属性 发 生 
了 变化 ， 此 时 就 需要 向 WMS 传 递 这 一 消息 ， 即 先 调用 
relayoutWindow() ， 然 后 进一步 调用 : 
int relayout(IWindow window, int seq, in WindowManager.LayoutPara 
int requestedWidth, int requestedHeight, int viewVisibi 
int flags, out Rect outFrame, out Rect outOverscanInset 


out Rect outContentInsets, out Rect outVisibleInsets, 
out Configuration outConfig, out Surface outSurface); 


这 个 函数 的 最 后 几 个 参数 是 出 参 ， 也 就 是 WMS 的 计算 结果 。 包 括 : 


outFrame: WMS 得 出 的 应 用 窗口 大 小 ， 对 应 ViewRootlmp1 中 的 成 员 
变量 mWinFrame 。 


outOverscanInsets: WMS 得 出 的 “过 扫描 ”区 域 ， 我 们 在 后 续 小 节 
会 做 详细 解释 。 


outContentInsets: WMS 得 出 的 content insets， 对 应 
ViewRoot1mp1 中 的 成 员 变 量 mPending Contentlnsets。 


outVisiblelnsets: WMS 得 出 的 visible insets， 对 应 
ViewRoot1mp1 中 的 成 员 变 量 mPending Visiblelnsets。 


outConfig: WMS 得 出 的 窗口 配置 信息 ， 对 应 ViewRoot1lmp| 中 的 成 员 
变量 mPending Configuration. 


outSurface: WMS 申请 的 有 效 的 Surface 对 象 ， 对 应 ViewRoot Imp I} 
的 成 员 变 量 mSurface。 


根据 前 面 小 节 的 分 析 ，1WindowSession. relayout () 最 终 会 导致 WMS 
中 的 relayoutWindow 被 调用 ， 这 个 函数 中 针对 窗口 大 小 的 一 系列 计算 流 


三 | 
TÆ: 


per formLayoutAndP | aceSur facesLocked () per formLayoutAndP | aces 
Layout AndPlaceSurfacesLockedInner () 。 其 中 最 后 这 个 函数 在 前 一 小 
节 已 经 讲解 过 ， 我 们 再 把 与 Layout 相 关 的 源码 摘录 出 来 : 


/*frameworks/base/services/java/com/android/server/wm/WindowManag 
private final void performLayoutAndPlaceSurfacesLockedInner ( 
SurfaceControl.openTransaction(); 

try {... 
int repeats = 0; 
do {// 退 出 循环 的 条 件 是 displayCcontent .pendingLayoutChar 
repeats++; 
if (repeats > 6) {// 循 环 的 最 多 次 数 
Slog.w(TAG, "Animation repeat aborted after 
displayContent.layoutNeeded = false; 
break; 





} 


if (isDefaultDisplay && (displayContent.pendingL 
& WindowManagerPolicy.FINISH_LAYOUT_REDO_ 
if (DEBUG_LAYOUT) Slog.v(TAG, "Computing new 
if (updateOrientationFromAppTokensLocked(tru 
displayContent.layoutNeeded = true; 
mH .sendEmptyMessage(H.SEND_NEW_CONFIGURA 
}/* 重 新 计算 config*/ 


if ((displayContent.pendingLayoutChanges 
& WindowManagerPolicy.FINISH_LAYOUT_RED 
displayContent.layoutNeeded = true;/*#2mH 





} 
if (repeats < 4) {/* 这 个 函数 最 多 被 调用 4 次 */ 
performLayoutLockedInner(displayContent, r 
false /*updateInp 
} else { 
Slog.w(TAG, "Layout repeat skipped after to 


} 
displayContent.pendingLayoutChanges = 0; 
if (isDefaultDisplay) { 
mPolicy.beginPostLayoutPolicyLw(dw, dh); 
for (i = windows.size() - 1; i >= 0; i--) 
WindowState w = windows.get(i); 
if (w.mHasSurface) { 
mPolicy.applyPostLayoutPolicyLw(w, 
} 


displayContent.pendingLayoutChanges |= 
mPolicy.finishPostL 


} 
} while (displayContent.pendingLayoutChanges != 0 


先 来 看 看 pendi ngLayoutChanges 的 可 选 值 ， 如 表 10-11 所 示 。 


表 10-11 pendingLayoutChanges 可 选 参 数 


Layout 状 态 可 能 已 经 
FINISH _ LAYOUT REDO LAYOUT= ae $ 
g = = 改变 ， 所 以 还 要 发 起 


0x0001 va 


FINISH_LAYOUT_REDO_CONFIG = jConfiguration 可 能 已 经 


0x0002 


FINISH_LAYOUT_REDO_WALLPAPER 
= 0x0004 





FINISH_LAYOUT_REDO_ANIM = 
0x0008 





从 表 中 可 知 ， 各 可 选 参数 值 是 “或 ”的 关系 。 


在 do…whi le 循环 中 ， 核 心 工作 都 是 围绕 pendi ngLayoutChanges 展 
开 的 。 Bll: 


As AdisplayContent. pendingLayoutChanges == 0， 也 就 是 当前 
已 经 没有 需要 处 理 的 Layout Changes， 或 者 循环 次 数 超 限 ， 循 环 才 会 退 
出 。 不 过 根据 do…whi le 的 语法 ， 它 至 少 会 执行 一 次 do 循环 体 。 在 对 
Layout Change 进 行 处 理 的 过 程 中 : 


(1) 如 果 pendingLayoutChanges 中 带 有 
FINISH_LAYOUT_REDO_CONF1G， 那 么 就 通过 mHI 引 WMS 的 消息 队列 中 发 送 一 
个 SEND_NEW_CONF1GURATION， 以 重新 计算 Configuration。 


(2) 如 果 pendingLayoutChanges 中 带 有 
FINISH_LAYOUT_REDO_LAYOUT， 就 将 layout Needed 置 为 true (如 果 这 个 
变量 为 false， 后 续 调 用 performLayoutLockedlnner 就 会 直接 返回 ) 。 


一 旦 repeats 次 数 小 于 4， 程 序 将 调用 performLayoutLockedlnner 。 
核心 源码 如 下 : 
private final void performLayoutLockedInner(final DisplayContent 


if (!displayContent.layoutNeeded) {// 如 果 此 变量 为 false， 什 么 
return; 





} 

displayContent.layoutNeeded = false;// 已 经 执行 了 本 次 的 layout 
WindowList windows = displayContent.getwindowList();// 窗 口 
boolean isDefaultDisplay = displayContent.isDefaultDispla 
DisplayInfo displayInfo = displayContent.getDisplayInfo( ) 
final int dw = displayInfo.logicalwidth; //i¥#s8 3, TJ feH H 
final int dh = displayInfo,1ogicalHeight;// 逻 辑 高 度 ， 可 能 比 4 








final int N = windows.size();// 系 统 中 所 有 窗口 数量 
int 羡 ;// 用 于 循环 计数 

WindowStateAnimator universeBackground = null; 
mPolicy.beginLayoutLw(isDefaultDisplay, dw, dh, mRotation 








int seq = mLayoutSeq+1;// 用 于 与 客户 端 同步 
if (seq < 0) seq = 0;// 当 seq 值 超过 范围 时 ， 重 新 从 9 开始 循环 使 用 
mLayoutSeq = seq;// 将 mLayoutSeq 更 新 为 当前 的 seq 值 


int topAttached = -1; 
for (i = N-1; i >= 0; i--) {/* 先 计算 root windows( 即 没有 atta 
那些 窗口 )*/ 
final WindowState win = windows .get( 工 ) 
final boolean gone = (behindDream && mPolicy.canBeFor 
|| win,isGoneForLayoutLw() ;/* 假 如 这 个 窗口 不 可 见 ， 
退出 动画 ) ， 那 就 不 浪费 








if (!gone || !win.mHaveFrame || win.mLayoutNeeded/*mH 
wits 

|| (win.mAttrs.type == TYPE_KEYGUARD && win.i 

|| win.mAttrs.type == TYPE_UNIVERSE_BACKGROUN 

if (!win.mLayoutAttached) {// 为 true 说 明 这 个 窗口 是 子 管 


mPolicy.layoutWindowLw(win, win.mAttrs, null) 
win.mLayoutSeq = seq; 
} else { 
if (topAttached < ©) topAttached = 工 ;/* 记 录 最 上 
供 下 一 步 使 用 














a 


/* 接 下 来 开始 计算 attached window 的 情况 ， 这 些 窗口 和 它们 的 父 窗口 关系 
for (i = topAttached; i >= 0; i--) {/* 直 接 从 上 一 步 中 记录 的 tol 
中 的 第 一 个 attached 窗 口 ) 开 女 
final WindowState win = windows.get(i); 

if (win.mLayoutAttached) 4... 

if ((win.mViewVisibility != View.GONE && win.mRel 
|| !win.mHaveFrame || win.mLayoutNeeded) 

mPolicy.layoutWindowLw(win, win.mAttrs, win.mA 

win.mLayoutSeq = seq; 








} 
} 
mPolicy.finishLayoutLw( );/* 结 束 layout*/ 
从 整体 逻辑 来 看 ， 浮 数 分 为 两 部 分 。 


e Root Windows 


程序 首先 会 处 理 Root Window， 也 就 是 没有 依附 于 其 他 窗口 的 那些 
窗口 。 因为 下 一 步 中 子 窗口 的 计算 需要 建立 在 它们 父 窗 口 的 基础 上 ， 所 
以 需要 优先 处 理 。 


e Attached Windows 


接着 处 理子 窗口 ， 步 骤 和 Root Window 基 本 一 致 ， 不 过 在 调用 
|ayoutWindowLw 时 会 传 入 win. mAttachedWindow 作 为 计算 时 的 参考 值 。 


从 流程 上 看 ， 窗 口 大 小 的 计算 过 程 如 下 : 


° mPol icy. beginLayoutLw 初 始 化 ; 


e mPol icy. layoutWindowLw 执 行 计算 过 程 ; 


。 mPol icy. fini shLayoutLw 清 理工 作 。 

为 什么 分 为 这 3 个 步骤 呢 ? 

打 个 比方 ， 某 人 上 婚恋 网 站 交友 ， 系 统 为 其 做 “匹配 ”的 流程 是 : 
° 注册 者 添加 自己 的 个 人 资料 ， 如 职业 、 爱 好 等 ; 


° 系统 将 根据 这 些 个 人 资料 以 及 “匹配 算法 ”来 计算 出 与 其 最 合 
AA; 


° 推荐 结果 等 后 续 操 作 。 


从 这 个 例子 中 可 以 发 现 ， 系 统 的 “匹配 算法 ”在 某 个 时 期 内 是 固定 
不 变 的 ， 但 是 它 要 针对 的 对 象 “ 注 册 者 ) 却 是 千变万化 的 一 一 这 其 中 的 
关键 就 是 个 人 资料 ， 因 为 每 个 人 都 有 其 特定 属性 。 

Android 系 统 也 不 例外 。 它 致力 于 兼容 多 种 设备 ， 因 而 在 设计 的 过 
程 中 一 方面 会 提取 产品 的 “共性 ”; 另 一 方面 要 降低 不 同 产品 间 切 换 的 
代价 。 成 员 变 量 mPolicy 就 是 一 个 实例 ， 它 是 针对 不 同 产品 〈 如 Phone， 
Tablet 等 ) 而 制定 的 窗口 策略 。 窗 口 大 小 的 计算 也 属于 “Window 
Policy” 的 职责 之 一 。 


下 面 我 们 逐一 介绍 这 3 个 重要 接口 。 
1. beginLayoutLw 


在 解释 这 个 函数 之 前 ， 先 要 了 解 PhoneWindowManager 中 与 窗口 大 小 
相关 的 一 系列 核心 变量 ， 如 表 10-12 所 示 。 


表 10-12 PhoneWindowManager 中 与 窗口 大 小 相关 的 核心 变量 


Overscan EIS JAHH”. AE 
示 屏 (比如 电视 〉 可 能 存在 
失真 现象 ， 且 越 靠 近 边 缘 越 











Pe. ON SEF IX MEA ER 
陷 ”， 不 少 广 商都 把 扫描 调整 
到 画面 的 5% 一 10%。 这 样 造 
成 的 结果 就 是 画面 很 可 能 显 





int mOverscanLeft = 0; 示 不 全 ， 损 失 的 部 分 称 

int mOverscanTop = 0; 为 “Overscan”。 与 Overscan 相 
int mOverscanRight = 0; 关 的 变量 是 在 新 系统 版 本 中 
int mOverscanBottom = 0; 加 入 的 《由 此 也 可 看 出 ， 


Android 正 在 进军 更 多 的 领 

域 ， 包 括 传统 家 电 ) ， 分 别 

代表 了 Overscan 区 域 离 屏幕 边 

缘 的 左 、 上 、 右 、 下 边 距 
(注意 : 是 “ 边 距 >， 如 图 所 

IR) 

mOverscanXX 代 表 的 是 边 距 


intmOverscanScreenLeft, 

int mOverscanScreenTop; 屏幕 真实 大 小 ， 包 括 了 
int mOverscanScreenWidth, Overscan X ak 

int mOverscanScreenHeight; 


int RestrictedOverscanScreenLeft, FI T moverse reei AB 


RestrictedOverscanScreenTop, 适当 的 时 候 可 以 移动 到 
mRestrictedOverscanScreenWidth, 
Overscan X Ex 


mRestrictedOverscanScreenHeight; 


int mUnrestrictedScreenLeft, 屏幕 的 真实 大 小 ， 不 管 当前 
mUnrestrictedScreenTop, 状态 栏 是 否 可 见 ， 但 不 包括 








mUnrestrictedScreenWidth, 


i , Overscan X + 
mUnrestrictedScreenHeight; x 





intmRestrictedScreenLeft, = awe se 
mRestrictedScreenTop, 屏幕 大 小 ， 如 果 状 态 栏 不 能 


mRestrictedScreenWidth, 隐藏 ， 它 和 上 述 几 个 变量 是 
mRestrictedScreenHeight; 不 同 的 


int mSystemLeft, mSystemTop, = 7 E 
IRE EA x ja 
mSystemRight, mSystemBottom; 所 有 可 见 的 系统 UI 元 素 区 域 


int mCurLeft, mCurTop, 包括 状态 栏 、 输 入 法 窗口 在 
rR ENE, 内 的 外 围 尺寸 


mCurBottom; 


int mContentLeft, mContentTop, 
mContentRight,mContentBottom; 


int mDockLeft, mDockTop eee 
i : 3 X til 
mDockRight, mDockBottom; 输入 法 窗口 区 域 





beginLayoutLw 的 作用 就 是 对 上 面 这 些 变量 进行 初始 化 。 比 如 
mDockLeft 、mContentLeft、mCurLeft 和 mDockTop 、mContentTop、 
mCurTop 的 原始 值 是 0，mDockRight、mContentRight、mCurRight 是 屏幕 
宽度 ， 而 mDockBottom、mContentBottom、mCurBottom 是 屏幕 高 度 。 换 
句 话 说， 它们 都 被 设置 成 了 “ 满 屏 ”。 


接 下 来 的 过 程 分 为 两 部 分 ， 即 是 否 有 导航 栏 以 及 状态 栏 。 


要 注意 导航 栏 的 摆 放 位 置 是 根据 实际 的 屏幕 属性 来 决定 的 。 假 如 导 
航 栏 不 能 移动 且 为 罕 屏 ， 那 么 导航 栏 在 屏幕 底 端 ， 否 则 为 横 屏 ， 导 航 栏 
会 被 显示 在 右 侧 。 这 样 做 的 目的 很 简单 ， 融 是 方便 用 户 的 操作 。 


状态 栏 的 大 小 是 相对 固定 的 ， 可 以 通过 
mStatusBar. computeFrameLw (pf, df, vf, vf) 计算 具体 的 值 。 如 果 当 
前 状态 栏 可 见 ， 那 么 很 多 变量 就 需要 进行 调整 以 防止 再 面 被 “遮挡 ”， 
包括 mContentTop，mCurTop 和 mDockTop。 当 然 ， 这 只 是 初始 化 值 ， 后 面 


还 需要 根据 用 户 的 配置 做 进一步 调整 


2. layoutWindowLw 


初始 化 完成 后 ， 各 个 变量 就 处 于 默认 状态 了 。 接 下 来 程 


前 的 具体 配置 进行 细 化 ， 以 满足 用 户 的 各 种 需求 : 


序 会 根据 当 


/*frameworks/base/policy/src/com/android/internal/policy/impl/Pho 
public void layoutWindowLw(WindowState win, WindowManager .LayoutP 
if (win == mStatusBar || win == mNavigationBar) {// 状 态 栏 和 ! 


return; // AB [Al 
} 


final int fl = attrs.flags;// 窗 口 属性 





final int sim = attrs.softInputMode;// 输 入 法 模式 ， 前 面 分 析 过 了 
final int sysUiFl = win. getSystemUiVisibility();//ARUIND 
final Rect pf = mTmpParentFrame; // 父 窗口 大 小 


final Rect df 
final Rect cf 
final Rect vf 


mTmpDisplayFrame;// 屏 幕 大 小 
mTmpContentFrame;// 内 容 区 域 
mTmpVisibleFrame;// 可 见 区 域 


final boolean hasNavBar = (isDefaultDisplay && mHasNavigat 
&& mNavigationBar != null && mNavigationB 


if (attrs.type == TYPE_INPUT_METHOD) { 
.…// 输 入 法 窗口 的 情况 比较 简单 ， 大 家 上 自行 分 析 
} else { 











if ((fl & (FLAG_LAYOUT_IN_SCREEN | FLAG_LAYOUT_INSET_D 


== (FLAG_LAYOUT_IN_SCREEN | 
//Case 1. 


} else if (((f1 & FLAG_LAYOUT_IN_SCREEN) != 0 
& (View.SYSTEM_UI_FLAG_LAYOUT_FULLSCRE 
| View. SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVI 


//Case 2. 

} else if (attached != null) { 
//Case 3. 

} else { 
//Case 4. 

} 


} 


win.computeFrameLw( pf， df, cf, vf);// 通 


I 
因为 导航 栏 与 状态 栏 窗口 比较 特殊 且 相对 固定 ， 


过 4 个 临时 变量 


FLAG_LAYOUT_INSET_ 


|| (sysu 


FR s 计算 出 上 





PhoneWindowManager 会 在 其 他 地 方 进行 处 理 ， 所 以 如 果 是 这 两 种 类 型 窗 
口 1ayoutWindowLw 就 直接 返回 。 输 入 法 窗口 大 小 的 处 理 也 比较 简单 ， 读 
者 可 以 自行 分 析 。 


对 于 其 他 类 型 的 窗口 ， 总 共 又 分 为 4 种 情况 ， 如 上 述 代码 段 中 
的 “CaseXXX” 所 示 。 需 要 特别 指出 的 是 ，1ayoutWindowLw 这 个 函数 只 
负责 计算 pf、df、cf 和 vf 4 个 临时 变量 ， 最 终 的 结果 还 需要 由 
win. computeFrameLw(pf，df，cf，vf) 来 确认 。 


Case 1. 1% SFLAG LAYOUT_IN SCREEN, 
FLAG _LAYOUT_ INSET DECOR H @487EFLAG_ FULLSCREEN 
View. SYSTEM_UI_ FLAG FULLSCREEN 


这 是 应 用 窗口 的 典型 情况 。 此 时 U1 界面 需要 考虑 包括 状态 栏 在 内 的 
系统 元 素 ， 这 样 才能 避免 被 “挡住 ”。 又 分 为 两 种 情况 : 


e Case 1.1 子 窗口 


如 果 是 子 窗口 ， 那 么 各 变量 的 值 与 其 父 窗口 是 一 致 的 ， 我 们 可 以 调 
用 setAttachedWindow Frames 来 执行 实际 操作 。 


e Case 1.2 非 子 窗口 
又 可 以 分 为 3 种 情况 。 


e Case 1.2.1TYPE_ STATUS _ BAR_PANETL 或 者 
TYPE STATUS BAR SUB_ PANEL 


这 两 者 是 唯一 可 以 在 状态 栏 上 方 显示 的 窗口 类 型 ， 受 到 StatusBar 
Service 的 权限 保护 。 


° Case1. 2. 2 普通 的 应 用 程序 窗口 (FIRST_APPLICATION_WINDOW 
~LAST_SUB_WINDOW) ， 并 且 明 确 指 定 了 
FLAG_LAYOUT_IN_OVERSCAN， 说 明 它 希望 占据 overscan 的 区 域 。 某 
些 情况 下 这 个 标志 很 有 用 ， 如 游戏 场景 。 


Case1. 2. 3 普通 的 应 用 程序 窗口 (FIRST_APPLICATION WINDOW 
~ LAST_SUB WIN DOW) ， 并 且 明 确 指定 了 View 标 志 


SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION 


AJAn, SYSTEM Ul FLAG LAYOUT HIDE NAVIGATION3ea. hy Fe 
序 “ 假 设 ” 了 当前 导航 栏 是 隐藏 的 ， 因 而 此 时 部 分 内 容 区 域 有 可 能 会 被 
SBS 


e Case 1.2.4 其 他 情况 的 处 理 
以 上 这 几 种 情况 都 会 受到 softlnputMode 的 影响 。 


Case 2， 指 定 了 窗口 标志 FLAG LAYOUT_IN_SCREEN， 或 下 面 两 个 
View 标 志 的 任何 一 个 : 
View. SYSTEM UI| FLAG LAYOUT FULLSCREENView. SYSTEM UI FLAG LAYOUT 


这 种 情况 说 明 应 用 窗口 希望 满 屏 显 示 (可 能 是 没有 系统 U1 元 素 的 满 
屏 ， 也 可 能 是 有 系统 U1 的 满 屏 ) 。 此 时 又 根据 不 同 的 窗口 类 型 细 化 为 多 
种 情况 ， 如 TYPE_STATUS_BAR_PANEL、TYPE_NAVIGATION_BAR、 
TYPE_SECURE_SYSTEM_OVERLAY 等 ， 不 过 处 理 过 程 大 同 小 异 。 


Case 3，attached1=nul1， 说 明 是 子 窗口 的 情况 。 根 据 前 面 的 分 
析 ， 直 接 调 用 setAttachedWindow Frames 即 可 。 


Case 4 假如 上 面 的 情况 均 不 满足 ， 那 么 就 进入 这 一 分 支 。 此 时 只 
有 两 种 子 情况 ， 即 窗口 类 型 是 否 为 TYPE_STATUS_BAR_PANEL。 我 们 说 
ee oe ered eee 
ET Yo 


通过 上 面 几 种 情况 的 计算 得 出 的 of ，df，cf 和 vf， 还 需要 通过 
computeFrameLw 进 行 最 终 确认 。 此 时 得 到 的 才 是 WindowState 中 的 
mParentFrame, mDisplayFrame、mContentFrame 丰 mVisibleFrame。 


3. finishLayoutLw 


这 个 函数 目前 直接 返回 ，， 因 而 是 一 个 空 实现 ， 大 家 可 以 直接 略 
iw. 


经 过 这 一 系列 的 函数 调用 后 ，Wi ndowManagerServi ce. 
relayoutWindow 才 算 真 正 结 束 了 。 它 会 负责 将 计算 结果 值 通过 陶 数 的 几 
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10.7 启动 窗口 的 添加 与 销毁 
10.7.1 启动 窗口 的 添加 


从 图 10-26 中 我 们 知道 ， 当 一 个 新 的 Activity 局 动 时 系统 可 能 会 
显示 一 个 启动 窗口 这 个 窗口 会 等 到 Activity 的 主 界面 显示 出 来 以 后 
age 这 样 做 可 以 转移 用 户 的 注意 力 ， 对 于 启动 时 间 较 长 的 应 用 程序 

Hiio 


很 显然 这 个 窗口 的 启动 与 销毁 是 由 系统 来 管理 的 ， 涉 及 了 
ActivityManagerService 和 WindowManagerService。 我 们 在 本 小 节 会 详 
细 分 析 其 中 的 流程 。 


当 AMS 在 处 理 startActivity 时 ， 它 会 调用 内 部 的 
ActivityStack. startActivityLocked (可 以 参见 AMS 章 节 的 描述 ) 。 如 
变量 NH>0， 说 明 我 们 正在 切换 到 一 个 新 的 Task 或 者 男 一 进程 ， 这 时 就 
会 准备 启动 一 个 Preview Window。 不 过 会 受到 以 下 两 个 因素 的 制约 。 





e SHOW_APP_STARTING_PREVIEW 


ActivityStack 中 的 一 个 boolean 变 量 ， 代 表 是 否 要 局 动 预览 窗口 ， 
默认 是 true。 


e doShow 


这 个 变量 默认 为 true。 假 如 要 局 动 的 Activity 是 在 一 个 新 的 Task 
中 ， 且 设置 了 FLAG_ACTIVITY_RESET_TASK_IF_NEEDED， 那 么 我 们 就 要 在 
必要 的 时 候 执 行 reset ( 即 resetTask1f NeededLocked) ， 然 后 判断 这 
个 Activity 是 否 在 mHistory 最 顶端 (并 且 不 在 finishing， 也 没有 
delayedResume) 。 只 有 这 些 条 件 都 满足 ，doShow 才 会 是 true， 否 则 也 
不 需要 添加 启动 窗口 。 


一 旦 确认 需要 添加 启动 窗口 ，ActivityStack 紧 接着 调用 
WindowManagerService. SetApp StartingWindow， 由 WMS 来 安排 具体 的 
窗口 创建 过 程 。 


WindowManager PhoneWindow |] Window 
Service Manager |} Managerhmpl ViewRoollmp! 








| | | | | | | 
uti Locked | | : | | | 
| setAppStarting | | | | | | 
Window | | | | | 
| | | | | | | 
| | | | | | 
| ADD STARING | | | | 
| | | | | | | 
| | Sang | | ] 
| | | Window | | | 
| | | | | 
| | | | | | 
| | tnakeNew Window | | 
| 
| | | | | | 
| | | | | | 
| | | | | | 
| | | | | | | 
| | | | addView | | | 
| | | | | 
| | | | | | | 
: | | | Window : 
| | | | Session.add | 
| | | | 
| | 
| | 
| | addWindow 
| | 
| | | 
| | 


全 图 10-26 启动 窗口 的 添加 流程 


从 函数 名 称 可 以 知道 ， 它 用 于 设置 局 动 窗口 的 各 种 参数 。 主 要 代码 


框架 如 下 : 


/*frameworks/base/services/java/com/android/server/wm/WindowManag 
public void setAppStartingWindow(IBinder token, String pkg, 

Compatibili tyInfo compatinfo, CharSequence nonLocalizedLabel, in 

int windowFlags, IBinder transferFrom, boolean createIfNeeded) { 


synchronized (mWindowMap) { 


} 
} 











/*Stepl. 再 次 验证 是 否 需要 显示 启动 窗口 */ 
AppWindowToken wtoken = findAppwindowToken(token) ;// 应 用 
if (wtoken == null) { 
Slog.w(TAG, "Attempted to set icon of non-existing 
return; 


} 
if (!okToDisplay()) {// 屏 幕 的 状态 是 否 允 许 显 示 ? 比如 屏幕 forzel 
return; 








} 
if (wtoken.startingData != null) {// 用 于 存储 与 启动 窗口 相关 和 
return; 








} 
if (transferFrom != null) {// 是 否 有 相关 联 的 启动 窗口 做 参考 ? 


} 
if (!createIfNeeded) { /* 假 如 不 存在 关联 的 启动 窗口 ， 且 调用 者 又 
那么 操作 就 可 以 结束 了 ， 直 接 返 回 */ 








return; 
J ; 
if (theme != 0) {//Activity 的 主题 不 为 空 


} 


mStartingIconInTransition = true; 

wtoken.startingData = new StartingData(pkg, theme, comp 
labelRes，icon，windowFlags );// 与 启动 窗口 有 关 的 信息 

Message m = mH.obtainMessage(H.ADD_ STARTING, wtoken); 

mH .sendMessageAtFront0ofQueue(m);// 将 消息 投递 入 栈 ， 以 进入 下 一 





首先 WMS 会 再 次 判断 是 否 需要 添加 局 动 窗口 ， 它 考虑 的 因素 和 AMS 不 


同 。 包 括 : 


e AppWindowToken 


因为 是 Activity 的 局 动 窗口 ， 那 么 它 的 AppWindowToken 一 定 不 能 为 
空 。 所 以 当 findAppWindowToken (token) 时 ， 我 们 必须 得 到 与 token 相 对 
应 的 AppWindowToken。 


。 当前 屏幕 状态 
如 果 显 示 屏 处 于 frozen 或 者 disabled 状 态 ， 又 或 者 屏幕 背光 没有 完 
那么 WMS 认为 不 适合 执行 启动 窗口 ， 此 时 就 会 直接 中 止 操作 直 
ža E. 


e startingData 


AppWindowToken 中 的 startingData 用 于 描述 与 启动 窗口 相关 的 所 有 
言 息 ， 如 packageName，theme，icon，windowFlags 等 。 这 些 因 素 将 决 
定局 动 窗口 的 最 终 效果 。 


让 


假如 wtoken. startingData l= nul1， 说 明 这 个 Activity 已 经 处 理 
过 启动 窗口 ， 在 这 种 情况 下 就 不 会 再 继续 往 下 执行 了 。 


接 下 来 函数 出 现 了 分 支 ， 如 图 10-27 所 示 。 


transterFrom'=null createl{Needed==true 


以 transferFrom AAE new StartineData 


Case |.| Case 1.2 
HADD STARTING 





全 图 10-27 创建 启动 窗口 的 处 理 分 支 


Case 1: 


如 果 transferFrom 不 为 空 ， 那 么 我 们 会 以 此 为 参照 物 来 设置 启动 窗 
口 。 在 这 种 情况 下 同样 要 求 transferFrom 的 AppWindowToken 不 为 空 。 如 
下 所 示 : 


AppWindowToken ttoken = findAppWindowToken(transferFrom); 
然后 又 可 以 分 为 以 下 两 种 具体 的 case。 
e Case 1.1 ttoken.startineWindow FF Æ 


startingWindow 是 一 个 WindowState， 说 明 transferFrom 的 启动 窗 
口 还 没有 被 WMS 移 除 。 在 这 种 情况 下 要 做 的 工作 就 是 把 startingWindow 
移交 给 新 的 Activity， 包 括 参 数 的 转移 ;从 WMS 中 移 除 
startingWindow; 以 及 transferFrom 本 身 状 态 的 清理 〈 因 为 此 时 这 个 局 
动 窗口 已 经 不 属于 它 了 ) 。 另 外 ， 就 是 把 移交 后 的 startingWindow 通 过 
addWindowToList1ln0rderLocked 重 新 添加 到 WMS 中 ， 并 使 用 


performLayoutAndPlaceSurfacesLocked 把 它 真 正 显示 出 来 。 
e Case 1.2 ttoken.startingData != null 


如 果 startingWindow 不 存在 ， 但 是 描述 启动 窗口 的 数据 不 为 空 ， 那 
么 同样 可 以 用 来 作为 参考 。 不 过 和 上 面 的 Case 相 比 ， 它 最 后 还 需要 向 
WMS 发 送 ADD_STARTING 指 令 来 完成 启动 窗口 的 具体 创建 与 添加 。 这 点 和 
Case 2. 2 一 样 。 


Case 2: 


假如 transferFrom 为 空 ， 则 意味 着 我 们 没有 参照 物 。 此 时 分 为 两 种 


e Case 2.1 createlfNeeded==false 


既然 没有 可 参考 的 对 象 ， 而 调用 者 (ActivityStack) 又 不 同意 构 
造 一 个 新 的 窗口 ， 那 么 操作 中 止 ， 直 接 返 回 。 


e Case 2.2 createlf{Needed==true 


意味 着 要 从 头 构 造 一 个 新 的 局 动 窗口 。 另 外 ， 这 时 还 要 先 通 过 
Activity 本 身 的 主题 来 判断 是 否 适合 显示 启动 窗口 。 假 如 设置 了 
windowlsTranslucent，windowlsFloating 或 者 windowShow 
Wallpaper 〈 且 mWallpaperTarget 不 为 空 ) 中 的 任何 一 种 属性 ， 那 么 同 
样 中 止 操作 。 而 如 果 一 切 顺 利 ， 程 序 会 通过 发 送 一 个 名 为 ADD_STARTING 
的 消息 来 促使 MMS 进入 下 一 步 操作 。 


因为 在 将 ADD_STARTING 入 栈 时 ， 使 用 的 是 
sendMessageAtFront0fQueue， 所 以 这 个 消息 将 在 下 轮 Message Loop 时 
就 被 处 理 ， 以 保证 启动 窗口 可 以 及 时 地 显示 出 来 。WMS 中 处 理 
ADD_STARTING 的 核心 语句 如 下 : 


view = mPolicy.addStartingWindow(wtoken.token, sd.pkg, sd.theme, 
sd.nonLocalizedLabel, sd.labelRes, sd.icon 


变量 mPol icy 是 一 个 WindowManagerPolicy 的 final 对 象 ， 初 始 化 时 
由 PolicyManager. makeNew WindowManager () 赋值 。 根 据 前 面 几 个 小 节 
的 分 析 ， 我 们 知道 makeNewWindowManager 创 建 的 是 一 个 


PhoneWindowManager : 


/*frameworks/base/policy/src/com/android/internal/policy/impl 
public View addStartingWindow(IBinder appToken, String packag 
CompatibilityInfo compatInfo, CharSequence nonLocaliz 

int icon, int windowFlags) {... 
try {.. 
Window win = PolicyManager .makeNewWindow(context );//4 


Resources r = context.getResources(); 

win.setTitle(r.getText(labelRes, nonLocalizedLabel) ); 
win.setType( WindowManager .LayoutParams.TYPE_APPLICAT 
win.setFlags(...);// 设 置 各 种 窗口 标志 。 启 动 窗口 是 比较 特殊 的 ， 比 











win.setLayout (WindowManager .LayoutParams .MATCH_PARENT 
WindowManager .LayoutParams.MATCH_PARENT );/*}- 

final WindowManager.LayoutParams params = win.getAttr 

params.token = appToken; 

params.packageName = packageName; 

params.windowAnimations = win.getWindowStyle().getRes 
com.android.internal.R.styleable.Window_windo 
/* 动 画 类 型 */ 


params.setTitle("Starting ”+ packageName); 
WindowManager wm = 
(WindowManager )context.getSystemService(Co 
View view = win.getDecorView(); 


wm.addView(view，params);// 添 加 一 个 窗口 ， 我 们 在 前 几 个 小 节 作 
return view.getParent() != null ? view : null; 
} catch (WindowManagerImpl.BadTokenException e) { 
} catch (RuntimeException e) { 
} 
r 


eturn null; 


} 

和 Activity 窗 口 类 似 ， 启 动 窗口 也 需要 在 “本 地 ”建立 一 个 Window 
对 象 ， 用 于 描述 即将 显示 表面 的 外 部 “框架 ”。 从 上 面 轴 数 可 以 看 出 ， 
这 个 Wi ndow 的 属性 如 下 。 

。 窗口 大 小 


友和 高 都 是 MATCH_PARENT， 所 以 是 满 屏 显示 《〈 因 
H) . 


Ss 
o} 
并 
SH 
i 
m} 


“窗口 类 型 
毋庸 置疑 ， 就 是 TYPE_APPL1CATI1ON_STARTING。 
。 窗口 标题 

由 getText (labelRes, nonLocal izedLabel) 计算 得 到 。 
。 窗口 标志 


这 是 一 个 临时 性 的 窗口 ， 所 以 不 应 该 是 touchable 或 者 focusable 
的 。 


和 普通 的 Activity 窗 口 一 样 ， 我 们 需要 将 启动 窗口 注册 到 WMS 中 ， 
后 由 后 者 在 SurfaceFlinger 中 申请 一 个 Surface 来 承载 U1 数据 ， 以 使 
ey eal 代码 如 下 : 


wm.addView(view, params); 


接 下 来 的 步骤 融和 Activity 窗 口 的 添加 流程 完全 一 致 ， 此 处 不 再 吾 


10.7.2 启动 窗口 的 销毁 


正常 情况 下 ， 一 旦 应 用 程序 的 主 窗口 显示 出 来 ， 与 之 相关 联 的 启动 
窗口 就 会 被 销毁 。 另 外 ， 系 统 在 某 些 特殊 情况 下 也 会 考虑 移 除 启动 窗口 

i 么 原因 引起 的 启动 窗口 的 销毁 ， 都 会 发 送 消息 给 WMS 进 行 
处 理 ， 如 REMOVE_STARTING 或 者 FINISHED _STARTING。 以 前 者 为 例 ， 其 流 
程 如 图 10-28 所 示 。 
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从 图 10-28 移 除 启动 窗口 流程 
这 个 流程 虽然 看 上 去 比较 复杂 ， 但 概括 起 来 只 有 3 个 方面 。 
1. 窗口 的 拥有 者 
窗口 的 拥有 者 通过 WindowManager Imp1 来 管理 它 名 下 的 所 有 


Window。 具体 而 言 ， 就 是 mViews，mRoots 和 mParams 3 个 成 员 数 组 。 局 
动 窗口 从 这 个 角度 来 讲 与 普遍 窗口 并 没有 本 质 区 别 ， 只 不 过 拥有 者 的 身 


份 有 差异 ， 所 以 当 它 被 移 除 时 就 自然 要 考虑 到 窗口 拥有 者 内 部 信息 的 更 
新 。 当 WMS 处 理 REMOVE_STARTING 消 息 时 ， 它 首先 调用 
PhoneWindowManager. removeStarting Window， 紧 接着 就 由 
WindowManagerlmp1 来 执行 removeView。 


清理 工作 分 为 两 部 分 ， 即 ViewRoot1mp1. die 和 removeltem。 


消 数 die 带 有 一 个 boolean 参 数 ， 表 示 是 否 马 上 人 处理 die 事 件 。 如 果 
回答 是 肯定 的 〈true) ， 那 么 直接 调用 doDie; 否则 将 一 个 MSG_D1E 消 息 
入 栈 ， 排 队 处 理 : 


/*frameworks/base/core/java/android/view/ViewRootIimpl.java*/ 
void doDie() { 
checkThread( ) ;// 当 前 线程 是 否 可 以 操作 UI 元 素 
synchronized (this) { 
if (mAdded) { 
dispatchDetachedFromwindow( ) ; 
} 


mAdded = false; 


} 


Android 系 统 中 的 U1 刷新 遵循 一 条 规则 ， 即 只 有 创建 UI 元素 的 线程 
才能 使 用 它 。 因 而 在 做 应 用 程序 开发 时 ， 工 作 线 程 通 常 需要 向 主线 程 发 
送 消息 来 间接 完成 刷新 因 面 的 操作 。 这 里 的 情况 也 类 似 ，checkThread 
会 首先 检查 执行 doDie 的 线程 是 否 和 创建 ViewRoot1mp1 的 线程 一 致 。 


成 员 变 量 mAdded 表 示 ViewRoot1mp1 当 前 是 否 有 关联 的 View。 只 有 当 
true 的 时 候 ， 我 们 才 需 要 进一步 调用 di spatchDetachedFromWindow， 并 
将 此 变量 置 为 false。 


2. Surface 


一 旦 窗口 被 移 除 ， 那 么 与 之 相对 应 的 数据 缓冲 区 也 就 没有 存在 的 必 
要 了 。 在 dispatchDetached FromWindow 中 ， 会 通过 mSurface. release 
来 释放 这 个 窗口 的 Surface。 


3. WMS 中 的 WindowState 


Wi naowst atc NOIRE IE 于 记录 窗口 状态 的 ， 因 而 移 除 局 动 窗 口 同 
样 要 更 新 这 一 信息 。 在 dispatchDetachedFromWindow 中 ， 会 通过 
sWindowSession. remove (mWindow) 来 调用 WMS 的 删除 窗口 服务 。 变 量 
sWindowSession 是 一 个 IWindowSession， 服 务 端 由 Session. java 实 现 ， 
这 个 “中 介 ” 将 直接 调用 WMS 的 removeWindow 来 执行 具体 操作 ， 并 在 最 
后 通过 performLayout AndPlaceSurfacesLocked 来 调整 当前 系统 的 窗口 
界面 ， 以 使 这 一 变化 能 真实 地 体现 在 终端 屏幕 之 上 。 


以 上 这 3 个 方面 所 涉及 的 代码 逻辑 与 局 动 窗口 的 添加 流程 类 似 ， 读 
者 可 以 自行 详细 分 析 其 中 的 源码 实现 。 


10.8 窗口 动画 


上 一 小 节 我 们 理解 了 启动 窗口 的 显示 与 消失 过 程 ， 但 这 还 不 是 
Activity 窗 口 切换 的 全 部 。 事 实 上 当 从 Act ivity1 过 渡 到 Activity2 的 过 
程 中 ， 还 可 能 涉及 窗口 动画 。 


窗口 的 切换 动画 可 以 分 为 两 类 : 


e 讲 入 动画 (Enter Animation) ; 
e 退出 动画 (Exit Animation) 。 


理论 上 这 些 动 画 是 可 以 定制 的 。 比 如 可 以 设计 一 种 飞 入 效果 ， 让 新 
局 动 的 Activity 窗 口 从 屏幕 左边 以 一 定 的 速率 进入 用 户 视 角 ; REBAR 
寸 渐变 的 形式 由 小 而 大 地 显示 出 新 窗口 。 


和 局 动 窗口 不 同 的 是 ， 窗 口 动 画 并 不 需要 创建 额外 的 Wi ndow 为 
了 理解 其 中 的 缘由 ， 我 们 首先 要 清楚 动画 的 实现 原理 。Animation 的 定 
义 是 : 





“Animation is the rapid display of a sequence of images 
to create an illusion of movement” 


动画 的 本 质 是 通过 连续 不 断 地 显示 若干 图 像 来 产生 “ 动 ”起 来 的 效 
果 。 举 个 前 面 的 “窗口 飞 入 动画 ”的 例子 ， 就 是 在 一 定 的 时 间 段 内 ， 以 
恰当 的 速率 研究 表明 ， 图 像 的 更 新 速率 必须 达到 12 帧 / 秒 以 上 ， 才 能 
让 人 了 眼 和 大 脑 觉得 这 是 一 个 平滑 的 动画 ) 每 隔 若干 时 间 在 屏幕 上 更 新 一 
次 这 个 窗口 的 最 新 位 置 。 


“尺寸 淘 变 ”的 效果 也 类 似 。 了 唯一 的 区 别 在 于 前 者 是 位 置 的 变换 ， 
而 这 里 则 指 “ 尺 寸 ” 的 变化 ; 同 理 ， 还 会 有 其 他 属性 变更 所 引起 的 动画 
特效 。 从 线性 数学 的 角度 来 讲 ， 包 括 : 


e 平移 (Translate) ; 
e 旋转 (Rotate) ; 
e 缩放 (Scale) ; 

e HJ% (Alpha) o 


很 显然 ， 这 几 种 属性 的 变化 并 不 是 孤立 的 ， 它 们 可 以 被 组 合 起 来 使 
用 。 比 如 在 “ 飞 入 ”的 同时 还 能 搭配 “尺寸 ” 淘 变 ， 或 者 旋转 一 一 不 论 
怎样 的 组 合 方式 ， 我 们 都 可 以 统一 用 Matirx 运 算 来 实现 。 因 为 从 技术 实 
现 的 角度 来 讲 ，Matr ix 是 动画 的 核心 。 


理解 了 以 上 基础 知识 ， 我 们 应 该 就 明白 为 什么 不 需要 额外 的 窗口 来 
执行 动画 过 程 了 。 任 何 类 型 的 动画 效果 ， 都 可 以 分 解 为 “窗口 本 
身 ”+“ 特 定时 间 点 的 Matr ix 变 换 和 矩阵 ”+“ 一 个 代表 Alpha 变 换 的 float 
类 型 值 ”。 
10. 8.1 窗口 动画 类 型 

随 着 Android 版 本 的 不 断 更 迭 换 代 ， 加 入 的 窗口 动画 类 型 也 越 来 越 
多 ， 整 个 逻辑 架构 显得 比较 凌乱 。 因 而 我 们 有 必要 先 对 它们 进行 分 类 与 
归 整 。 最 新 版 本 的 系统 至 少 有 如 下 3 种 核心 窗口 动画 管理 者 : 


e AppWindowAnimator}; 
e WindowStateAnimator ; 


e ScreenRotationAnimation. 


从 源码 的 角度 来 看 ， 它 们 又 分 属于 表 10-13 所 示 的 对 象 (Owner) 


表 10-13 Animator 


AppWindowToken 中 的 成 员 变 量 
AppWindowAnimator “|mAppAnimator 即 代表 了 此 应 用 程序 所 属 的 
AppWindowAnimator2)) H} 












WindowManagerService 记 录 了 所 有 窗口 的 
WindowState， 其 中 
WindowState.mWinAnimator 是 一 个 
WindowStateAnimator 对 象 。 它 和 上 面 的 















WindowStateAnimator 





AppWindowAnimator 一 样 都 是 可 以 由 应 用 
开发 人 员 上 自行 定制 的 ， 后 续 小 节 有 详细 分 
析 








屏幕 旋转 动画 。WindowManagerService 中 
的 mAnimator 是 一 个 WindowAnimator 类 型 


ScreenRotationAnimationl 的 对 象 ， 其 中 
WindowAnimator.mScreenRotationAnimation 


即 屏 幕 旋转 动画 





接 下 来 主要 以 AppWindowAnimator 和 WindowStateAnimator 的 分 析 为 
主 ， 其 他 类 型 的 动画 原理 也 是 一 样 的 ， 读 者 可 以 作为 练习 自行 阅读 。 


这 两 种 类 型 的 动画 还 可 以 进一步 细 分 成 若干 子 类 型 ， 如 表 10-14 和 
表 10-15 所 示 。 


表 10-14 与 Window 相 关 的 动画 类 型 〈 定 义 在 WindowManagerPol icy. java) 


fansteewren | wa 到 屏幕 上 


Starting window 退 出 ， 以 显示 真正 
的 窗口 


















TRANSIT_HIDE 














TRANSIT _PREVIEW_DONE 






I] 


3210-15 E App Window (Transition) 相关 的 动画 类 型 (定义 在 AppTransition. java) 


TRANSIT_ UNSET 未 初始 化 
TRANSIT_ NONE 没有 设置 动画 


一 个 新 的 Activity 被 同一 个 task 中 
的 男 一 Activity 打 开 ， 此 时 的 

PRANSIT_ACTIVITY_OPEN [Wyindow 动 画 就 应 该 是 这 种 类 型 
的 (属于 ENTER 动 画 的 一 种 ) 





处 于 栈 顶 的 Activity 关 闭 后 ， 将 
重新 显示 其 下 的 Activity， 此 时 
TRANSIT_ACTIVITY_CLOSHE| 窗 口 动画 以 这 种 类 型 曲 去 〈 属 于 
EXIT 动 画 的 一 种 ) 


Activity 将 在 新 的 task 中 被 打开 
TRANSIT_TASK_OPEN (属于 ENTER 动 画 ) 


Activity 关 闭 后 ， 将 重新 显示 前 
WE E 一 个 Activity〈 不 同 的 task 栈 ) 





虽然 细 分 的 种 类 比较 多 ， 但 它们 都 可 以 理解 为 进入 或 者 退出 动画 的 
一 种 。 比如 : 
public static final int TRANSIT_ACTIVITY_OPEN = 6 | TRANSIT_E 


public static final int TRANSIT_ACTIVITY_CLOSE = 7 | TRANSIT_ 
public static final int TRANSIT_TASK_OPEN = 8 | TRANSIT_ENTER 


public static final int TRANSIT_TASK_CLOSE = 9 | TRANSIT_EXIT 


TRANS1T_ENTER_MASK 和 TRANS1T_EX1T_MASK 分 别 取 值 0x1000 和 
0x2000， 这 样 可 以 有 足够 的 位 数 来 容纳 各 种 动画 类 型 ; 同时 ， 也 可 以 通 
ao IT 是 否 带 有 这 两 种 MASK 来 鉴别 它们 所 属 的 是 进入 或 者 退出 
动画 。 


上 述 第 一 个 表 中 的 TRANS1T_ENTER，TRANSI1IT_EX1T， 
TRANSIT_SHOW，TRANSIT_HIDE 和 TRANSIT_PREV1IEW_DONE 五 种 动画 类 型 是 
与 窗口 相关 的 ， 由 WindowStateAnimator 来 管理 ; 剩余 部 分 则 由 
AppWindowAnimator 来 管理 ， 我 们 将 在 接 下 来 的 小 节 中 分 别 解释 。 


10.8.2 ”动画 流程 跟踪 一 一 WindowStateAnimator 


我 们 知道 ， 当 一 个 新 的 Activity 启 动 时 ， 它 需要 间接 调用 WMS 提 供 
的 relayoutWindow 来 申请 一 个 Wi ndow: 


/*frameworks/base/services/java/com/android/server/wm/windowM 
public int relayoutWindow(...int viewVisibility...) {... 
if (toBeDisplayed) {// 即 将 显示 
if (win.isDrawnLw() && okToDisplay()) { 
winAnimator.applyEnterAnimationLocked( ) ; 
} 


需要 注意 的 是 ，relayoutWindow 既 可 用 于 申请 Window， 同 时 还 可 移 
除 一 个 Window， 这 取决 于 函数 入 参 viewVisibi1ity 的 具体 值 。 对 于 窗口 
进入 动画 ，viewVisibi1ity 的 值 必然 是 View. V1SIBLE， 即 客户 请 求 显示 
Fo 


变量 toBeDi splayed 用 于 表示 窗口 是 否 需要 显示 ， 它 通过 
isVisibleLw 来 判断 。 如 果 当 前 窗口 还 没有 Surface， 或 者 正在 进行 退出 
动画 《随后 便 会 移 除 Surface) ， 或 者 它 的 app token 被 隐藏 ， 那 么 
isVisibleLw 都 会 返回 fal se。 另 外 ， 我 们 还 需要 判断 窗口 是 否 有 合法 的 
Surface、 是 否 已 经 完整 地 绘制 过 U1， 而 且 当 前 屏幕 处 于 okToDisplay 的 
状态 一 一 只 有 这 些 条 件 都 满足 ， 才 能 最 终 开 始 执 行进 入 动画 ， 即 调用 


winAnimator. app1yEnterAnimationLocked () 。 





WindowStateAnimator 是 从 旧版 本 中 的 WindowState 分 离 出 来 的 ， 专 
门 用 于 动画 流程 的 跟踪 以 及 和 Surface 相 关 的 若干 操作 : 


/*frameworks/base/services/java/com/android/server/wm/windowState 
void applyEnterAnimationLocked() { 
final int transit; 
if (mEnterAnimationPending) { 
mEnterAnimationPending = false; 
transit = WindowManagerPolicy.TRANSIT_ENTER; 
} else { 
transit = WindowManagerPolicy.TRANSIT_SHOW; 


applyAnimationLocked(transit, true); 
} 


从 上 面 这 个 函数 的 实现 可 以 看 出 ， 进 入 动画 分 为 两 种 一 一 
TRANS1IT_ENTER 和 TRANS1IT_SHOW。 人 ag | purena i hi 
true 时 执行 的 ， 表 示 窗 口 处 于 “从 无 








。addWindow 
此 时 Window 隐 被 添加 ， 当 然 是 “从 无 到 有 
。oldVisibility == View.GONE 
E 之 前 的 状态 是 GONE， 现 在 变 为 VISIBLE， 也 可 以 认为 是 “从 无 到 
假如 mEnterAnimationPending 为 true， 程 序 执行 TRANS1T_ENTER 动 
， 否 则 就 只 是 TRANS1T_SHOW。 我 们 来 看 看 它们 有 什么 区 别 |: 


boolean applyAnimationLocked(int transit, boolean isEntrance) 
if (mLocalAnimating && mAnimationIsEntrance == isEntrance) 
// 如 果 当 前 正在 执行 的 动画 类 型 与 ijsEntrance 是 一 致 的 ， 那 么 系统 就 不 重 


return true; 





if (mService.okToDisplay()) {// 当 前 屏幕 处 于 可 以 显示 的 状态 

int anim = mPolicy.selectAnimationLw(mWin, transit);//iz 
int attr -1; 
Animation a = null; 
if (anim != 0) { 

a = AnimationUtils.loadAnimation(mContext, anim);// 
} else {//anim 为 9 的 情况 下 ， 使 用 默认 动画 资源 

switch (transit) { 

case WindowManagerPolicy .TRANSIT_ENTER: 
attr = com.android.internal.R.styleable.Wind 








terAnimation; 
break; 
case WindowManagerPolicy.TRANSIT_EXIT: 
attr = com.android.internal.R.styleable.Wind 
Animation; 
break; 


} 
if (attr >= 0) { 
a = mService.mAppTransition.loadAnimation(mWin. 
} 
} 
if (a != null) { 


setAnimation(a); 
mAnimationIsEntrance = isEntrance; 


} else { 

clearAnimation(),;// 屏 幕 当 前 状态 不 适合 显示 ， 清 除 动画 
} 
return mAnimation != null; 


} 
上 述 代码 段 分 为 如 下 几 个 步骤 ， 如 图 10-29 所 示 。 





TRANSIT ENTER wmdowEnterAnimation 
TRANSIT EXIT — windowExitAnimation 
TRANSIT SHOW  windowShowAnmation 





全 图 10-29 动画 的 选择 过 程 
1. 获取 对 应 的 动画 id 


特殊 类 型 的 窗口 如 StatusBar 和 NavigationBar， 它 们 的 进入 /退出 





动画 和 普通 窗口 是 有 差别 此 它们 将 由 

en ee 否则 也 就 是 上 述 代 码 
段 中 an im 为 0 的 部 分 ) 就 需要 先 根 据 transit 类 型 来 获取 对 应 的 属性 id， 
a 画 效果 id 值 。 如 TRANSIT_ENTER 对 应 的 属性 id 值 


com.android.internal.R.styleable.WindowAnimation_windowEnterAnima 


而 TRANS1T_EX1T 对 应 的 属性 id 值 为 : 


com.android.internal.R.styleable.WindowAnimation_windowExitAnimat 





这 样 程序 通过 windowEnterAnimation 和 windowExitAnimation 这 两 
个 id 属性 的 具体 配置 就 可 以 获取 动画 id 了 。 


2. 加 载 动画 


加 载 动画 使 用 的 接口 是 AnimationUtil1s. 1oadAnimation。 需 要 提醒 
大 家 的 是 ，selectAnimationLw 返 回 的 值 就 是 动画 id， 所 以 可 以 直接 通 
过 AnimationUtils. loadAnimation 来 加 载 。 其 他 情 况 下 首先 需 要 得 到 的 
是 attr 值 ， 因 而 调用 的 接口 是 
mService. mAppTransition. loadAnimation 不 过 可 以 猜测 到 后 者 的 
贸 数 内 部 也 一 定 会 再 调用 AnimationUtils. loadAnimation, = 
mService 就 是 Window ManagerService 自 身 ， 而 mAppTransition 是 一 
AppTransition 对 象 。 如 下 所 示 : 





fa 


Animation loadAnimation(WindowManager.LayoutParams lp, int an 
int anim = 0; 
Context context = mContext; 
if (animAttr >= 0) { 
AttributeCache.Entry ent = getCachedAnimations(lp); 
if (ent != null) { 
context = ent.context; 
anim = ent.array.getResourcelId(animAttr, 0);//i8W 


} 


} 
if (anim != 0) { 

return AnimationUtils.loadAnimation(context, anim);// 
} 


return null; 


既然 是 通过 属性 id 来 动态 获取 动画 id， 而 不 是 由 系统 直接 指定 一 个 
默认 值 ， 就 意味 着 我 们 可 以 根据 自己 的 需求 来 定制 动画 效果 。 基 于 
Activity 的 应 用 程序 可 以 在 自 定 义 的 theme 中 提供 窗口 动画 ， 或 者 直接 
使 用 系统 中 预 安装 的 主题 动画 。 


下 面 是 SystemU1 应 用 中 的 一 个 实例 : 


<style name="Animation.RecentPanel"> 
<item name="android:windowEnterAnimation">@* android: anim/grow 
<item name="android:windowExitAnimation">@*android:anim/shrin 
</style> 


上 述 windowEnterAnimation 指 定 的 是 名 
为 “grow fade_in from bottom” 的 动画 ， 也 同样 由 xm| 文 件 来 描述 ， 
可 以 参照 本 书 应 用 篇 中 对 Android 资 源 管 理 的 分 析 。 


我 们 将 “grow_fade_in_from_bottom” 的 部 分 核心 语句 摘录 如 下 : 


<set xmlns:android="http://schemas.android.com/apk/res/android" a 
<scale android:interpolator="@interpolator/decelerate_quint" 
android: fromxXScale="0.9" android: toxXScale="1.0" 
android: fromYScale="0.9" android: toYScale="1.0" 
android: pivotxX="50%" android: pivotY="100%" 
android: duration="@android:integer/config_activityDefaultDur 
<alpha android: interpolator="@interpolator/decelerate_cubic" 
android: fromAlpha="0.0" android: toAlpha="1.0" 
android: duration="@android: integer/config_activitySho 
</set> 


从 名 称 可 以 看 出 来 ， 这 个 进入 动画 希望 实现 的 效果 
是 “grow”+“fade in” + “from bottom”。 分 解 到 实现 层面 ， 就 是 由 
scale 与 alpha 两 个 属性 组 成 的 动画 。 上 面 xm| 文 件 中 的 各 属性 解释 如 
下 : 


interpolator: 动画 的 “变化 率 ”。 打 个 比方 ， 如 果 规 定 在 10 秒 内 
跑 完 100 米 ， 那 么 实际 在 执行 时 既 可 以 匀速 地 跑 〈 即 10 米 / 秒 ) ; 也 可 以 
一 开始 跑 快 点 ， 然 后 慢 慢 减速 ; 也 可 以 一 开始 跑 慢 点 ， 然 后 慢 慢 加 速 。 
= “10 秒 内 跑 完 100 米 ”规定 的 ， 有 具体 选 择 哪 种 就 看 实 
mfo 


fromXScale/fromYScale: 也 就 是 Scale 变化 的 “起 点 ”， 包 括 x 和 vy 


轴 ，1. 0 表示 没有 变化 。 


toXScale/toYScale: scale 变 化 的 “终点 ”， 同 样 的 1. 0 代表 没 


pivotX/pivotY: scale 操 作 需 要 有 一 个 “核心 参考 点 ”， 它 既 可 以 
是 图 形 的 正中 心 ， 也 可 以 自行 指定 。 


Duration: 按照 上 面 的 例子 ， 就 是 指 “ 多 长 时 间 ” 跑 完 100 米 。 
fromAlpha/toAlpha: alpha 变 化 的 “起 点 ”和 “终点 ”。 


这 样 我 们 就 自 定 义 了 一 个 窗口 的 “进入 动画 ”效果 ， 并 通 
过 “android:windowEnterAnimation” 属 性 告知 了 系统 。 


3. 设置 动画 


遂 数 app1yAnimationLocked 最 后 会 通过 setAnimation 来 将 一 个 
Animation 对 象 设 置 到 WindowStateAnimator 中 。 代 码 如 下 : 


public void setAnimation(Animation anim) {... 
mAnimating = false; 
mLocalAnimating = false; 
mAnimation = anim;// 记 录 Animation 对 象 
mAnimation.restrictDuration(WindowManagerService.MAX_ANIM. 
mAnimation.scaleCurrentDuration(mService.mWindowAnimation 


} 


可 以 看 到 ， 这 个 函数 将 动画 对 象 (Animation) 保存 在 mAnimation 
成 员 变 量 中 ， 并 做 初始 化 动作 。 不 过 需要 特别 注意 的 是 ， 此 时 并 没有 真 
正 执行 动画 效果 ， 而 只 是 对 动画 相关 的 各 元 素 进 行 了 设置 一 一 后 续 小 节 
会 专门 介绍 整个 “动画 ”是 如 何在 VSYNC 组 织 下 有 序 地 “ 动 ” 起 来 的 。 


10.8.3 AppWindowAnimator 


当局 动 一 个 新 的 Activity 时 ，AMS 会 根据 当前 的 实际 情况 来 判断 是 
否 为 应 用 程序 设置 AppWindowAnimator 以 及 动 男 的 类 型 。 和 上 一 小 节 类 
似 ， 这 里 的 动画 类 型 指 的 是 TRANS1T_ACTIVITY_OPEN,， 
TRANSIT_ACTIVITY_CLOSE 等 ， 而 具体 的 动画 实现 也 是 可 以 由 开发 者 定制 


的 。 比 如 在 TRANS1T_ACTIVITY_OPEN 的 情况 下 会 优先 考虑 应 用 程序 通过 
android:activityOpen EnterAnimation/ activityOpenExitAnimation 
属性 设置 的 动画 资源 一 一 对 应 的 源码 实现 体现 在 ActivityStack. java 
中 ， 它 通过 WMS 提 供 的 prepareAppTransition 接 口 来 为 应 用 程序 设置 
AppWindow Animation。 这 个 动画 将 由 该 应 用 程序 在 WMS 中 的 token， 即 
AppWindowToken 中 的 mAppAnimator 成 员 变 量 来 管理 。 其 流程 如 图 10-30 
所 示 。 


ActivityStack WindowManagerService AppWindowAnimator 


| 

| 
X | 
prepareApp [ransition | 
| 
| 
| 


APP TRANSITION TINEQUT 
| 
| 


performLayoutAndPlaceSurfacesLockedInner 
| 









| 
handleAppTransitionReadyLocked 


Sa Ke SL Oe 


| 
| 
applyAnimationLocked 


| 
| 
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| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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| 
| sctAnimation 
| 

| 

| 
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| 
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我 们 来 看 看 app1yAnimat ionLocked 的 实现 : 


/*frameworks/base/services/java/com/android/server/wm/WindowManag 
private boolean applyAnimationLocked(AppWindowToken wtoken, 
WindowManager.LayoutParams lp, int transit, boolean ent 
if (okToDisplay()) {//3X Ph BEERS RS, AIR 
DisplayInfo displayInfo = getDefaultDisplayInfoLocked( ) 
final int width = displayInfo.appWidth; 
final int height = displayInfo.appHeight; 
Animation a = mAppTransition.loadAnimation(lp, transit, 


// 加 载 动画 资源 


atoken.mAppAnimator.setAnimation(a, width, height) ;//%! 
} else { 

atoken.mAppAnimator.clearAnimation(); 
} 


return atoken.mAppAnimator.animation != null; 


这 个 函数 做 了 两 件 事 ， 即 : 


mAppTransition.loadAnimation(lp, transit, enter, width, height) #l 
atoken.mAppAnimator.setAnimation(a, width, heigh;t) 


窗口 动画 在 Android 各 版 本 中 改动 较 大 ， 因 而 遗留 了 不 少 “ 历 史 痕 
迹 ”。 比 如 对 于 loadAnimation 这 个 函数 ， 在 最 sare ince rot 
我 们 在 Wi ndowStateAnimator 中 看 到 的 1oadAnimation 和 上 面 代 
suit loadAnimat ion 就 是 同名 不 同 参 的 两 个 函数 实现 ， 读 者 要 特别 

主意 辨别 : 





/*frameworks/base/services/java/com/android/server/wm/AppTransiti 
Animation loadAnimation(WindowManager.LayoutParams lp, int t 
int appWidth, int appHeight) { 
Animation a; 
if (mNextAppTransitionType == NEXT_TRANSIT_TYPE_CUSTOM) { 
} else if (mNextAppTransitionType == NEXT_TRANSIT_TYPE_SC 
} else if (mNextAppTransitionType == NEXT_TRANSIT_TYPE_TH 
mNextAppTransitionType == NEXT_TRANSIT_TYPE_THUMBN. 
} else { 
int animAttr = 0; 
switch (transit) { 
case TRANSIT_ACTIVITY_OPEN: 


animAttr = enter? WindowAnimation_activityOpe 
: WindowAnimation_activityOpenExitAni 





break; 
…// 其 他 transit 的 处 理 是 类 似 的 ， 代 码 省 略 
} 
a = animAttr != 0 ? loadAnimation(lp, animAttr) : nul 
t 
return a; 


J 


变量 mNextAppTransitionType 反 映 了 当前 App Transit ionf BW 
制 类 型 ， 由 Activity0ptions 提 供 定 义 。 包 括 : 


e ANIM_NONE 
默认 值 ， 即 上 述 代码 段 中 的 el se 分 支 。 
e ANIM_CUSTOM 


Activity PA—FBWN “overridePendingTransition” Aye 
数 ， 应 用 开发 者 可 以 通过 重 载 它 来 定制 自己 的 App Transition. XAA 
数 对 应 的 WMS 端 实现 是 overr idePendingAppTransition， 此 时 
mNextAppTransitionType 就 会 被 设置 为 ANIM_CUSTOM。 另 外 ， 当 我 们 通 
过 startActivity (Intent intent, Bundle options) 来 启动 一 个 新 的 
Activity 时 ， 其 中 第 二 个 参数 实际 上 是 Activity0ptions， 所 以 也 可 以 
指定 App Transition 的 类 型 〈 只 不 过 通常 不 这 样 做 ) 。 


e ANIM_SCALE_UP 


和 上 一 个 参数 类 似 ， 在 调用 startActivity (Intent intent, 
Bundle options) 时 ， 我 们 可 以 给 第 二 个 参数 指定 ANIM_SCALE_UP。 从 名 
称 就 可 以 看 出 来 ， 这 种 动画 是 指 了 画面 尺寸 “从 小 而 大 ”的 一 种 动画 效 
果 ， 对 应 的 是 WMS 中 的 overridePendingAppTransitionScaleUp 实 现 。 


e ANIM_THUMBNAIL| ANIM_THUMBNAIL_DELAYED 


指定 这 两 种 ANINM 的 方式 和 前 面 是 一 致 的 。 它 们 表示 在 启动 目标 
Activity Window 前 先 从 某 个 指定 位 置 Scale Up 一 幅 thumbnai | ER. m 
DELAYED 则 表示 在 此 之 前 是 否 还 需要 一 定时 间 的 延 时 。 


无 论 是 上 述 的 哪 一 种 类 型 ， 它 们 的 处 理 逻 辑 都 是 类 似 的 ， 即 采用 适 
当 的 手段 来 加 载 各 类 型 所 指定 的 动画 资源 。 比 如 在 ANIM_SCALE_UP 的 情 
况 下 通过 createScaleUpAnimat ionLocked 来 产生 一 个 Animat ion; 
ANIM_THUMBNAIL 和 ANIM_THUMBNAIL_DELAYED 则 对 应 的 是 
createThumbnai |AnimationLocked; 而 ANIM_NONE 则 是 依靠 读 取 应 用 程 
序 的 属性 来 加 载 动画 。 


最 后 ， 这 些 加 载 的 动画 都 会 被 存储 到 AppWindowAnimator 中 ， 以 期 
人 
Fo 
10.8.4 动画 的 执行 过 程 

前 面 两 个 小 节 分 析 了 窗口 动画 的 各 种 类 型 、 创 建 和 设置 过 程 ， 那 么 
这 些 动画 是 如 何 执 行 起 来 的 呢 ? 先 来 思考 一 下 ， 窗 口 动画 的 执行 需要 哪 
些 元 素 的 支持 。 

。 触发 源 


动画 是 在 某 段 时 间 内 的 连续 动作 ， 显 然 每 隔 一 段 时 间 都 需要 有 一 
个 “主动 ”的 触发 事件 ， 才 能 保证 动画 的 正常 执行 。 


。 整合 所 有 动画 
既然 有 这 么 多 种 类 的 动画 存在 ， 则 意味 着 同一 个 时 刻 系统 中 很 可 能 
人 
J? 
e 5SurfaceFlinger ty # 0 


WMS 只 是 窗口 的 管理 者 ， 并 不 会 直接 影响 屏幕 的 界面 显示 。 因 而 动 
画 的 执行 过 程 一 定 需要 SurfaceFlinger 的 支持 ， 如 图 10-31 所 示 。 


Choreographer | | AnimationRunnable | | WindowAnimator | | AppWindowAnimator | |SereenRotationAmmation| | WindowStateAnimator 
| | | 





VSYNC | | | | 
| | | | | | 
tul 
| | | | | 
iL. 
animate | | open Transaction | | 
updateWindowsppsAndRolationAnimalonsl ocked | | 
| We | | | | 
| 8 9 | | | | 
| stepAnimationLocked | | | | 
| | | | | 
| | | | | 
| stepAnimationLocked | | | 
| | | | | 
| | | | | 
| | | | | 
| a PerformAnimalionsLocked | | | 
| | | | | 
| | | | | 
| W a | | | 
| | | | | 
| slepAnimationl ,ocked | | ! 
| | | | | 
| |, capes ees 2 | | | 
| prepare Surfacel .acked | 
| | | | 
| | | we, setSurfaceBoundaries 
| | | | 
| selPosition | 
| | | selSize | 
| selWindowCrop | 
| | | | 
| | | | 
| | | set Alpha 
\ | setLayer | 
| | | setMatnx | 
| | | | 
| | | | 
| | close lransaction | | 
| 
| | | | | | 
| | | | | | 
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WindowManagerService 中 有 一 个 AnimationRunnable 类 型 的 成 员 变 
量 mAnimationRunnable， 我 们 以 此 为 入 口 来 看 看 它 对 窗口 动画 的 组 织 方 


式 。 


AnimationRunnable 继 承 自 Runnable， 所 以 重 载 了 run () Ask, Fil] 
稍 后 会 详细 分 析 这 个 函数 。WMS 会 在 需要 执行 动画 时 通过 
scheduleAnimationLocked 来 设置 一 个 “触发 源 ”， 源 代码 如 下 : 


void scheduleAnimationLocked() { 
if (!mAnimationScheduled) { 
mAnimationScheduled = true; 
mChoreographer . postCallback(Choreographer .CALLBACK_. 
mAnimationRunn 


J 


布尔 变量 mAnimationScheduled 用 于 指示 当前 是 否 已 经 在 schedule 
animation， 这 个 值 在 AnimationRunnable. run 中 会 被 重新 复位 为 
false。 上 述 代码 段 的 核心 是 mchoreographer 一 一 这 个 变量 是 “线程 唯 
一 ”的 ， 即 在 同一 线程 中 是 单 实例 。 根 据 我 们 在 SurfaceF1inger 章 节 中 
讲解 的 “黄油 计划 ”，Android 系 统一 定 会 以 VSYNC 为 信号 来 刷新 U1。 那 
么 对 于 应 用 程序 〈 在 这 个 场景 中 ，WMS 也 是 应 用 程序 ) 来 说 ， 它 们 是 如 
何 获知 VSYNC 的 呢 ? 


这 就 是 Choreographer 的 设计 初 袁 。 从 字面 来 解释 ， 它 表达 的 
是 “ 编 舞 者 ”， 所 以 形象 地 反映 出 了 Choreographer 作 为 “有 序 动作 管 
理 者 ”所 担负 的 职责 。 关 于 这 个 类 的 更 多 解释 ， 我 们 后 续 还 会 有 介绍 ， 
这 里 暂时 把 它 理解 为 “VSYNC” 的 接收 者 即 可 。 


现在 就 比较 清楚 了 ，VSYNC 信 号 就 是 动画 的 触发 源 。 这 样 的 设计 无 
ee es 同时 也 保证 了 画面 的 流 
， 值 得 借鉴 。 


Choreographer 一 方面 需要 接收 VSYNC 信 号 ， 另 一 方面 要 将 这 一 事件 
转发 给 感 兴 趣 的 人 ， 所 以 希望 监听 VSYNC 事 件 的 对 象 都 需要 在 
Choreographer 中 注册 ， 如 图 10-32 所 示 。 






postCallback 


Choreographer 


postCallback 
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Choreographer 4 PA Ast Aes A Input, Animation, 
Traversal (layout, draw) 3 个 类 别 ， 存 储 在 其 内 部 的 一 个 Queue 数 组 
(CallbackQueue[] mCallbackQueues) 中 。 在 这 个 场景 中 ， 动 画 对 应 
的 是 CALLBACK_ANIMATION。 


所 以 当 VSYNC 信 和 号 产生 后 ，mAnimationRunnable 中 的 run 函 数 将 被 触 


` 


/*frameworks/base/services/java/com/android/server/wm/Window 
mAnimationRunnable = new Runnable() { 
@Override 
public void run() { 
synchronized (mService.mWindowMap) { 
mService.mAnimationScheduled = false;//AIKHE 
animateLocked( );// 各 种 动画 的 “ 单 步 执行 "要 开始 了 





}; 


首先 将 mAnimationScheduled 复 位 为 false， 代 表 本 次 的 动画 
schedule 请 求 已 经 接受 。 作 为 窗口 动画 的 统一 管理 者 ，mAnimator 由 WMS 
在 构造 消 数 中 创建 。 核 心 洱 数 如 下 : 


/*frameworks/base/services/java/com/android/server/wm/WindowA 
private void animateLocked() 
if (!mInitialized) {/* 是 否 已 经 成 功 初 始 化 */ 
return; 


mCurrentTime = SystemClock.uptimeMillis();// 当 前 时 间 
mBulkUpdateParams = SET_ORIENTATION_CHANGE_COMPLETE; 
boolean wasAnimating = mAnimating;// 记 录 上 一 次 的 动画 状态 ， 用 于 ; 
mAnimating = false;// 先 置 为 false 
SurfaceControl.openTransaction();/* 业 务 开始 ， 先 本 地 记录 下 所 有 对 
统一 提交 给 SurfaceFlinger。 原 因 我 们 在 前 面 小 节 都 已 经 详细 论述 过 了 */ 
SurfaceControl.setAnimationTransaction(); 
try { 
updateAppWindowsLocked();/*Step1. 执行 App Window 动 画 */ 
final int numDisplays = mDisplayContentsAnimators.size( 
for (int i = 0; i < numDisplays; i++) {// 分 别处 理 每 个 Disp 
final int displayId = mDisplayContentsAnimators. key. 
DisplayContentsAnimator displayAnimator = mDisplayC 
/*Step2. 处 理 屏幕 旋转 动画 */ 
final ScreenRotationAnimation screenRotationAnimati 
displayAnimator .mScreenRotationAnimation; 
if (screenRotationAnimation != null && screenRotati 
if (screenRotationAnimation.stepAnimationLock 
mAnimating = true;// 动 画 还 未 结束 ， 下 一 轮 还 需 于 
} else {..// 动 画 结 束 
} 
} 
performAnimationsLocked(displayId);/*Step3. 更 新 Wind 


















































中 的 动画 */ 
final WindowList windows = mService.getWindowListLo 
final int N = windows.size(); 
for (int j = 0; j < N; j++) { 
windows.get(j).mWinAnimator.prepareSur faceLocke 
} 


} 
.…// 其 他 类 型 的 动画 处 理 过 程 是 类 似 的 ， 省 略 代码 
} catch (RuntimeException e) { 
Log.wtf(TAG, "Unhandled exception in Window Manager", 
} finally { 
SurfaceControl.closeTransaction();/*Step5. 统一 提交 给 Su 
} 


if (mAnimating) {// 接 下 来 是 否 还 需要 再 执行 动画 
mService.scheduleAnimationLocked();// 是 的 话 就 schedule 下 - 
} else if (wasAnimating) {// 这 是 动画 的 最 后 一 次 “ 单 步 ” 
mService.requestTraversalLocked();//#ktraversal, Fel} 
} 


} 


首先 要 说 明 的 是 ， 不 论 AppWindowAnimator， 
ScreenRotationAnimation 或 者 是 WindowState Animator， 在 每 次 更 新 
动画 了 时 被 调用 的 接口 都 是 stepAnimationLocked。 这 个 函数 表达 了 “ 步 
进 ” 的 意思 ， 即 每 隔 特定 时 间 点 动画 的 最 新 变化 。 


Step1@WindowAnimator. animateLocked。 这 一 步 专门 处 理 
AppWindowAnimator 中 的 动画 ， 也 就 是 AppTransition 中 设置 的 那些 动 
E 

















Step2@WindowAnimator. animateLocked。 这 一 步 专门 处 理 屏 幕 旋 转 
相关 的 动画 《比如 用 户 将 屏幕 横着 看 ， 或 者 竖 着 看 ) 。 


Step3@WindowAnimator. animateLocked。 几 种 类 型 动画 的 处 理 过 程 
是 相似 的 ， 我 们 只 选取 这 一 步 ， 即 Wi ndowStateAnimator 动 画 的 操作 流 
程 来 做 重点 分 析 。 


疯 数 performAnimationsLocked 很 简单 ， 它 分 别 调用 了 
updateWindowsLocked 和 updateWallpaperLocked (值得 一 提 的 是 ， 在 前 
几 个 Android 系 统 版 本 中 ， 这 两 个 函数 其 实 统称 为 
updateWindowsAndWal lpaperLocked 一 一 这 应 该 也 是 历史 遗留 下 来 的 产 
物 ， 使 得 取 名 和 远 辑 显得 稍微 有 点 杂乱 。 但 在 最 新 版 本 中 ， 这 些 混乱 被 


慢 慢 纠正 过 来 了 ) 。 


来 看 看 updateWindowsLocked 的 实现 : 


private void updatewindowsLocked(final int displayId) { 
++mAnimTransactionSequence; 
final WindowList windows = mService.getWindowListLocked(di 

















for (int i = windows.size() - 1; i >= 0; i--) {// 逐 个 处 理 所 和 
WindowState win = windows.get(i); 
WindowStateAnimator winAnimator = win.mWinAnimator; 
final int flags = winAnimator.mAttrFlags; 
if (winAnimator.mSurfaceControl != null) { 
final boolean wasAnimating winAnimator .mWasAnima 
final boolean nowAnimating winAnimator.stepAnima 





我 们 并 不 知道 系统 中 当前 需要 执行 “动画 步 进 ”的 
WindowStateAnimator 有 多 少 。 换 句 话 说， 目前 的 源码 实现 中 没有 把 它 
们 单独 列 出 来 管理 。 所 以 上 述 代 码 段 通过 循环 遍历 mWindows 中 的 所 有 
WindowStateAnimator， 有 再 通过 stepAnimati 自行 决 
定 是 否 进 行动 画 (并 不 是 每 个 WindowStateAnimator 都 有 动画 ) ， 以 及 
如 何 进行 动画 。 


整个 函数 虽然 很 长 ， 不 过 最 核心 的 语句 只 有 一 句 ， 即 : 


winAnimator .stepAnimationLocked(mCurrentTime); 


执行 此 WindowStateAnimator 的 “ 单 步 ”动画 


/*frameworks/base/services/java/com/android/server/wm/windowState 
boolean stepAnimationLocked(long currentTime) { 

mWasAnimating = mAnimating;// 先 保存 上 一 次 的 状态 ， 供 WMS 比较 使 用 

if (mService.okToDisplay()) {// 屏 幕 是 否 允 许 显 示 

if (mWin.isDrawnLw() &&mAnimation != null) {... 

if (!mLocalAnimating) {// 第 一 次 step 这 个 动画 ， 需 要 做 些 请 
mAnimation.initialize(mWin.mFrame.width(), mWin. 
mAnimDw, mAnimDh) ;7 动画 初 交 




















mAnimation,setStartTime(currentTime);// 设 置 当 前 时 让 
mLocalAnimating = true;// 已 经 执行 过 一 次 且 初 始 化 完成 ， 
mAnimating = true;// 当 前 正在 执行 动画 





if ((mAnimation != null) && mLocalAnimating) { 


if (stepAnimation(currentTime)) {// 计 算 当 前 的 动 
return true;//true 表 示 动 画 还 没 结 束 ， 因 而 直接 返 
} 





} 
} 


} else if (mAnimation != null) { 
mAnimating = true; 








} 

/* 一 旦 执行 到 这 里 ， 说 明 当 前 这 个 动画 结束 了 ， 或 者 有 其 他 异常 */ 

if (!mAnimating && !mLocalAnimating) {/* 当 前 不 在 动画 ， 且 没有 
return false; 


t 
/** 以 下 是 清理 工作 ， 省 略 **/ 








return false ;//false 表 示 动 画 结 


} 
这 个 函数 中 涉及 几 个 命名 相近 的 变量 ， 我 们 先 做 下 集中 的 比较 。 


boolean mLocalAnimating: 用 于 指示 一 个 动画 的 第 一 次 step。 当 
我 们 设置 了 一 个 新 的 动画 后 ， 这 个 变量 是 false; 而 一 旦 成 功 地 执行 了 
一 次 step 后 ， 这 个 值 就 是 true 了 。 专 门 设计 这 个 变量 的 原因 是 第 一 次 执 
行动 画 时 有 额外 的 步骤 要 执行 。 比 如 给 Animat ion 初 始 化 

(mAnimation. initialize) ， 设 置 起 始 时 间 
(mAnimation. setStartTime) =. 


boolean mAnimating: 当前 正在 执行 动画 中 。 


boolean mWasAnimating: 记录 上 一 次 的 mAnimating， 这 个 变 


与 其 他 条 件 一 起 作为 执行 动画 的 参考 值 。 


A 
ZS 


fala 


boolean mHasLocal Transformation: WindowStateAnimator Æ 
computeShownFrameLocked 时 ， 需 要 考虑 到 3 种 Transformation， 即 
selfTransformation，attachedTransformation 和 
appTransformation。 其 中 第 一 个 是 由 mHasTransformation 变 量 决 定 
的 ; 其 余 两 个 则 代表 了 此 Window 所 依附 窗口 所 市 的 Transformation， 以 
及 应 用 程序 本 身 所 设置 的 Transformation。 


假如 是 第 一 次 step 动 画 ， 即 mLocalAnimating 为 false， 那 么 需要 先 
给 Animation 设 置 尺 寸 大 小 和 开始 时 间 等 参数 。 要 特别 注意 的 是 ， 并 不 
是 每 个 WindowStateAnimator 当 前 都 有 动画 在 执行 ， 因 而 需要 判断 


mAnimation 是 否 可 用 。 只 有 在 mAnimation!=nul1 且 mLocalAnimating 为 
true 的 情况 下 ， 才 能 调用 stepAnimation 来 计算 动画 状态 。 这 个 函数 的 
返回 结果 代表 当前 动画 是 否 已 经 完成 true 说 明 没 有 完成 ， 因 而 还 需 
下 一 次 的 step， 这 时 就 可 以 直接 返回 ; false 表 示 当 前 的 动画 已 经 结束 
了 ， 此 时 还 要 做 一 些 清理 收尾 工作 。 


最 后 来 看 看 stepAn imat ion 是 如 何 执行 一 次 “ 单 步 ”的 : 


private boolean stepAnimation(long currentTime) { 
if ((mAnimation == null) || !mLocalAnimating) {// 没 有 动画 对 
return false; 





‘yE Px 


mTransformation.clear();// 先 清空 
final boolean more = mAnimation.getTransformation(current 
return more; 


} 


本 节 的 开头 我 们 曾 概 括 了 动画 的 4 个 要 素 ， 即 缩放 、 平 黎 、 旋 转 和 
透明 度 。 前 三 者 由 一 个 矩阵 Matrix 表 示 ， 最 后 一 项 则 由 float 变 量 表 
示 ， 它 们 都 封装 在 同一 个 类 中 ， 即 Transformation。 而 Animation 是 对 
动画 本 身 的 描述 ， 如 起 点 、 终 点 、 时 长 、 速 率 等 属性 。 这 两 个 类 是 动画 
的 核心 ， 而 且 一 个 是 “静态 ”的 描述 ， 另 一 个 则 是 “动态 ”的 计算 。 上 
面 的 stepAnimation， 首 先 判断 动画 是 否 合 法 ， 即 mAn imat ion 必 须 可 
用 ， 而 且 已 经 正确 初始 化 。 然 后 对 Transformation 进 行 清空 ， 这 是 因为 
随后 的 getTransformation 将 直接 根据 当前 的 时 间 和 Animat ion 设 置 的 起 
始 时 间 计 算得 出 一 个 新 的 变换 值 ， 并 不 需要 依赖 上 一 次 的 结果 ; 同时 ， 
这 个 函数 返回 的 值 nore 指 示 了 动画 是 否 已 经 结束 ， 通 常 就 是 指定 的 时 间 
已 经 到 了 或 者 动画 的 最 终 效 果 已 经 完成 。 有 兴趣 的 读者 可 以 自行 分 析 下 
这 个 函数 的 实现 。 


Step4@WindowAnimator. animateLocked。 经 过 上 述 几 种 动画 的 “ 步 
进 ” 计 算 ， 才 只 完成 了 WMS 中 的 状态 更 新 。 或 者 说 ， 此 时 用 户 还 看 不 
到 “动画 ”效果 。 要 真正 将 动画 反映 到 屏幕 上 ， 就 必须 借助 于 
SurfaceF linger 了 。 在 “通知 ”SurfaceFlinger 之 前 ，WMS 还 要 对 
Surface 做 一 些 准备 工作 ， 即 prepareSurfaceLocked。 


这 个 函数 的 任务 有 两 个 。 


o 准备 好 Sutface 的 更 新 数据 





Surface 是 客户 端 (Java) 与 SurfaceFlinger 间 的 中 介 ， 或 者 说 
是 “业务 的 载体 ”。 当 我 们 需要 对 Surface 进 行 批量 修改 时 ， 通 常 是 
调用 Surface. openTransaction 表 示 业 务 开 始 ， 随 后 调用 Surface 提 供 的 
接口 进行 设置 ， 最 后 才 是 通过 Surface. closeTransaction 来 关闭 业务 ， 
并 将 更 新 信息 统一 传递 给 SurfaceFlinger。 


经 过 前 面 各 种 类 型 动画 的 “sit” its, WMS 中 的 各 状态 已 经 得 到 
了 更 新 。 这 时 我 们 就 可 以 基于 这 些 最 新 的 状态 来 准备 发 送 给 Surface 
的 “数据 包 ” 了 ， 这 是 由 computeShownFrameLocked 来 完成 的 。 


e 将 上 一 步 计 算出 的 “数据 包 ” 逐 一 设置 到 Surface 对 象 中 


动画 类 型 的 不 同 以 及 每 次 动画 步 进 产生 的 状态 有 差异 ， 导 致 需要 设 
置 到 Surface 的 内 容 也 可 能 有 变化 。 具 体 分 为 两 部 分 : 


e setSurfaceBoundaries 


处 理 Surface 尺 寸 大 小 、 位 置 相关 的 更 新 ， 包 括 


Surface. setPosition, Surface. setSize 和 setWindowCrop 等 。 
e setAlpha，setLayetr 和 setMatrix 等 属性 的 更 新 。 


Step5@WindowAnimator. animateLocked。 为 了 使 Surface 中 的 信息 
生效 ， 最 后 我 们 要 通过 closeTransaction 来 关闭 业务 ， 此 时 Surface 中 
的 所 有 更 新 就 会 传递 给 SurfaceFlinger， 后 者 会 在 下 一 次 的 界面 合成 中 
ee ee 于 是 用 户 就 可 以 看 到 最 终 的 动画 “ 步 
进 ” 效 果 了 。 


假如 mAnimating 为 true， 表 示 动 画 还 将 继续 进行 ， 因 而 我 们 接着 调 
用 scheduleAnimationLocked 来 安排 下 一 次 的 “触发 源 ”; 如 果 
mAnimating 为 false， 且 wasAnimating 为 true， 此 时 就 是 动画 结束 前 的 
最 后 一 次 step (因为 wasAnimating 记 录 的 是 上 一 次 的 mAnimating， 这 种 
情况 下 说 明 mAnimating 在 上 一 次 时 为 true， 本 次 则 变 为 false， 所 以 是 
最 后 一 次 ) ， 我 们 需要 通过 requestTraversalLocked 来 发 出 一 个 
DO_TRAVERSAL 消 息 ， 随 后 performLayoutAndPlaceSurfaces Locked} 
次 被 调用 。 


E 
让 你 的 界面 炫 彩 起 来 的 GU1 系 统一 一 View 体 系 


我 们 在 前 两 个 章节 已 经 深入 分 析 了 Android 中 GU1 系 统 的 底层 支撑 框 
架 ， 即 SurfaceFlinger 和 WMS 两 个 系统 服务 的 内 部 原理 。 但 是 从 终端 用 
户 的 角度 来 讲 ， 这 两 者 都 不 是 他 们 最 关心 的 。 因 为 真正 与 用 户 产 生 直 接 
联系 的 ， 是 本 章节 要 阐述 的 View 体 系 一 一 几乎 所 有 APK 应 用 程序 的 U1 界 
面 都 是 由 它 来 描述 的 。 





11.1 应 用 程序 中 的 View 框 架 


应 用 程序 中 的 View 框 架 如 图 11-1 所 示 。 
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全 图 11-1 应 用 程序 中 的 View 框 架 


Act ivity 是 应 用 程序 各 组 件 中 使 用 率 最 高 的 ， 专 门 设 计 用 于 UI 珊 面 
的 显示 和 处 理 〈 当 然 ， 这 并 不 意味 着 在 其 他 组 件 中 就 一 定 无 法 显示 U1， 
只 不 过 需要 做 很 多 额外 的 工作 ) 。 对 于 应 用 开发 人 员 来 说 ， 他 们 可 以 利 
用 SDK 向 导 来 生成 一 个 带 Activity 的 应 用 程序 模板 ， 再 根据 具体 需 
求 “ 加 工 ”Android 提 供 的 “半成品 ” setContentView, 
onCreate、onStart 等 方法 ， 从 而 快速 定制 出 应 用 程序 ; 而 从 系统 实现 
E E E E 


在 对 这 部 分 源码 进行 讲解 前 ， 我 们 发 现 以 下 几 个 问题 是 很 多 开发 者 
共同 的 困惑 。 





e View 和 ViewRoot 


如 果 以 xm1 文 件 来 描述 U1 界面 的 layout， 可 以 发 现 里 面 的 所 有 元 素 
实际 上 都 形成 了 树 状 结构 的 关系 ， 比 如 : 


<LinearLayout xmlns:android="http://schemas.android.com/apk/res/a 
android:id="@+id/top"...> 

<LinearLayout android:id="@+id/digits container"...> 
<com.android.contacts.dialpad.DigitsEditText android:id="@+id/d 
<ImageButton android:id="@+id/deleteButton".../> 
</LinearLayout> 

<View android: id="@t+id/viewEle".../> 

</LinearLayout> 


这 个 xml 文 件 中 各 元 素 的 关系 如 图 11-2 所 示 。 





全 图 11-2 xml 文 件 中 各 元 素 的 关系 图 


从 色 称 来 理解 ，“ViewRoot” 似 乎 是 “View 树 的 根 ”。 这 很 容易 让 
人 产生 误解 ， 因 为 ViewRoot 并 不 属于 View 树 的 一 分 子 。 从 源码 实现 上 来 
看 ，ViewRoot 和 View 对 象 并 没有 任何 “血缘 ”关系 ， 它 既 非 View 的 子 
类 ， 也 非 View 的 父 类 。 更 确切 地 说 ，ViewRoot 可 以 被 理解 为 “View 树 的 
管理 者 ” 它 有 一 个 mView 成 员 变 量 ， 指 向 的 是 它 所 管理 的 View 树 的 
根 ， 即 图 中 id 为 “top” 的 元 素 。 


ViewRoot 的 核心 任务 就 是 与 Wi ndowManagerService 进 行 通 信 ， 我 们 
在 后 面 小 节 会 详细 介绍 。 


e Activity 和 Window 的 关系 


我 们 知道 ，Activity 是 支持 U1 显示 的 ， 那么 它 是 否 直接 管理 View 树 
或 者 ViewRoot 了 呢 ? 答案 是 否定 的 。Activity 并 没有 与 这 两 者 产生 直接 的 
联系 ， 这 中 间 还 有 一 个 被 称 为 “Window” 的 对 象 。 


具体 而 言 ，Activity 内 部 有 一 个 mWindow 成 员 变 量 。 如 下 所 示 : 


private Window mWindow; 


Window 的 字面 意思 是 “窗口 ”， 这 很 好 地 解释 了 它 存 在 的 意义 。 
Window 是 基 类 ， 根 据 不 同 的 产品 可 以 衍生 出 不 同 的 子 类 一 一 具体 则 是 由 





系统 在 Activity. attach 中 调用 Pol icyManager. make NewWindow 决 定 
的 ， 目 前 版 本 的 Android 系 统 默 认 生 成 的 都 是 PhoneWindow。 


e Window 与 WindowManagetImpl 的 关系 


以 “Window” 开 头 的 类 有 不 少 ， 如 Window、WindowManager、 
WindowManagerlmp1 等 ， 为 什么 需要 这 么 多 的 相似 类 呢 ? 


先 来 看 Window， 它 是 面向 Activity 的 ， 表 示 “U1 窜 面 的 外 框 ”; 
而 “ 框 里 面 ” 具 体 的 东西 包括 布局 和 内 容 等 ， 是 由 具体 的 Window 子 类 ， 
如 PhoneWindow 来 规划 的 。 但 无 论 最 终生 成 的 窗口 怎样 ，Activity 都 是 
不 需要 修改 的 。 


Window 的 另 一 层 含 义 是 要 与 WindowManagerService 进 行 通信 ， 但 它 
并 没有 直接 在 自身 实现 这 一 功能 。 原 因 就 是 : 一 个 应 用 程序 中 很 可 能 存 
在 多 个 Window。 如 果 它 们 都 单独 与 WMS 通信 ， 那 么 既 浪 费 资源 ， 又 会 造 
成 管理 的 混乱 。 换 句 话说 ， 它 们 需要 统一 的 管理 。 于 是 就 有 了 
WindowManager ， 它 作为 Window 的 成 员 变 量 mWindowManager 存 在 。 这 个 
WindowManager 是 一 个 接口 类 ， 其 真正 的 实现 是 WindowManagerlmp1， 后 
者 同时 也 是 整个 应 用 程序 中 所 有 Window 的 管理 者 。 因 而 WindowManager 
与 Wi ndowManagerlmp1 的 关系 有 点 类 似 于 “地 方 与 中 央 ” : 地 方 为 实施 
中 央 的 “政策 ”提供 了 一 个 “接口 ”， 然 后 汇总 到 中 央 进 行 管理 。 


e ViewRoot 和 WindowManagerImpl 的 关系 
在 早期 的 系统 版 本 中 ，WindowManager mp1 在 每 个 进程 中 只 有 一 个 
实例 。 调 用 它 必 须 使 用 如 下 语句 : 
WindowManagerImpl.getDefault(); 
在 WindowManager 1mp1 内 部 ， 存 在 3 个 全 局 变量 : 
private View[] mViews; 


private ViewRootImpl[] mRoots; 
private WindowManager.LayoutParams[] mParams; 


它们 分 别 用 于 表示 View 树 的 根 节 点 、ViewRoot 以 及 Window 的 属性 。 
由 此 也 可 以 看 出 ， 一 个 进程 中 不 仅 有 一 个 ViewRoot; 而 Activity 与 
ViewRoot 则 是 一 对 一 的 关系 。 


Android 4. 3 对 此 做 了 修改 ，WindowManager Imp1 不 再 直接 存储 上 述 
3 个 数组 变量 ， 而 是 由 一 个 称 为 “WindowManagerGlobal” 的 类 统一 管 
理 。 另 外 ， 新 版 本 还 对 各 个 类 的 关系 进行 了 梳理 ， 别 除了 一 些 历史 遗留 
下 来 的 无 关 类 。 当 然 ， 其 统一 管理 ViewRoot 与 View 树 的 本 质 是 没有 变 
的 ， 正 所 谓 “ 换 汤 不 换 药 ”。 


e ViewRoot 与 WindowManagerService 的 关系 
每 一 个 ViewRoot1imp1 内 部 ， 都 有 一 个 全 局 变量 : 
static IWindowSession sWindowSession; 


这 个 变量 用 于 ViewRoot 到 WMS 的 连接 ， 它 是 ViewRoot 利 用 WMS 的 
opneSess ion () 接口 来 创建 得 到 的 。 caret ViewRoot 也 会 通过 
IWindowSession. add () 方法 提供 一 个 IWindow 对 象 一 一 从 而 让 WMS 也 可 以 

通过 这 个 Bindcr 对 象 来 号 ViewRoot 进 行 双向 通 fs. 


我 们 可 以 用 图 11-3 来 描述 这 些 类 之 间 的 关系 。 
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全 图 11-3 Activity, WindowManagerGlobal#e WMS ¥ 4) KAA 


如 图 11-3 所 示 ， 每 个 Application 都 有 一 个 ActivityThread 主 线程 
以 及 mAct ivities 全 局 变量 ， 后 者 记录 了 运行 在 应 用 程序 中 的 所 有 
Activity 对 象 。 一 个 Activity 对 应 唯一 的 WindowManager 以 及 
ViewRoot Imp1。WindowManagerGlobal 作 为 全 局 管理 者 ， 其 内 部 的 
mRoots 和 和 mViews 记 录 了 各 Activity 的 ViewRoot1mp| 和 View 树 的 顶层 元 
素 。ViewRoot Imp1 的 另 一 个 重要 角色 就 是 负责 与 WMS 进行 通信 。 从 
ViewRoot Imp1 到 WMS 间 的 通信 利用 的 是 IWindowSession， 而 反方 向 则 是 
由 IWindow 来 完成 的 。 


11.2 ActivityPView Tree 的 创建 过 程 


Activity 与 其 他 组 件 最 大 的 不 同 ， 就 是 其 内 部 拥有 完整 的 表面 显示 
机 制 ， 这 涉及 了 ViewRoot1lmp1，Window 以 及 由 它们 管理 的 View Tree 
等 。 前 几 个 章节 讨论 应 用 程序 窗口 的 启动 流程 时 ， 我 们 曾 大 致 讲解 了 
View Tree 的 建立 要 点 一 一 现在 是 时 候 把 其 中 的 细节 逐一 剖析 清楚 了 ， 
如 图 11-4 所 示 。 
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全 图 11-4 View Tree 的 建立 流程 图 


参与 View Tree 创建 的 有 几 个 主体 ， 即 ActivityThread、 
Activity、PhoneWindow、ViewRoot1mp1 和 WM 〈 这 里 先 不 严格 区 分 是 本 
地 的 WindowManager 还 是 服务 端的 WindowManagerService) à 


主要 流程 如 下 : 


Step1， 作 为 应 用 程序 的 主线 程 ， a e 
心事 件 。 比 如 “AMS 通 知 应 用 进程 去 启动 一 个 Activity” 这 个 任务 
终 将 转化 为 ActivityThread 所 管理 的 LAUNCH_ ACTIVITY 消 息 ， 然 后 调用 
handleLaunchActivity， 这 是 整个 ViewTree 建 立 流 程 的 起 点 。 


Step2. 在 handleLaunchAct ivity 内 部 ， 又 可 以 细 分 为 两 个 子 过 程 : 


e performLaunchAct ivity; 


° handleResumeActivity (注意 ，Resume 的 处 理 时 机 有 多 种 情 
况 ， 我 们 以 此 为 例 ) 。 


具体 源 代 码 如 下 : 


/*frameworks/base/core/java/android/app/ActivityThread. java*/ 
private void handleLaunchActivity(ActivityClientRecord r, Intent 


Activity a = performLaunchActivity(r, customIntent);//jaah (M8 


if (a != null) { 
handleResumeActivity(r.token, false, r.isForward);//Resum 


小 节 开 头 的 序列 图 ， 分 别 对 这 两 个 函数 进行 解析 。 
1. performLaunchActivity 


private Activity performLaunchActivity(ActivityClientRecord r, In 


Activity activity = null; 
try { 
java.lang.ClassLoader cl = r.packageInfo.getClassLoad 


activity = mInstrumentation.newActivity(cl, component 
/* 加 载 这 个 Activity 对 象 */ 


} catch (Exception e) { 
} 


try { 
Application app = r.packageInfo.makeApplication(false 


if (activity != null) { 


activity.attach(appContext, this, getInstrumentat 
r.ident, app, r.intent, r.activityInfo, t 
r.embeddedID, r.lastNonConfigurationInsta 


mInstrumentation.callActivityOnCreate(activity, r 


} catch (SuperNotCalledException e) { 


return activity; 


} 


这 个 函数 的 主要 任务 是 生成 一 个 Activity 对 象 ， 并 调用 它 的 attach 
方法 ， 然 后 通过 Instrumentation. cal1Activity0nCreate 间 接 调用 
Activity. onCreate。 其 中 attach 将 为 Activity 内 部 众多 全 局 变量 赋值 
一 一 最 重要 的 就 是 mWindow。 源 代码 如 下 : 


mWindow = PolicyManager .makeNewWindow(this); 


这 里 得 到 的 就 是 一 个 PhoneWi ndow 对 象 ， 它 在 每 个 Activity 中 有 且 
仅 有 一 个 实例 。 我 们 知道 ，“Window” 在 Activity 中 可 以 被 看 成 “表面 
的 框架 抽象 ”， 所 以 有 了 Window 后 ， 下 一 步 肯 定 还 要 生成 具体 的 View 内 
容 ， 即 Activity 中 的 mDecor。Decor 的 原 义 是 “装饰 ”。 换 句 话说 ， 它 
除了 包含 Activity 中 实际 想 要 显示 的 内 容 外 ， 还 必须 具备 所 有 应 用 程序 
共同 的 “装饰 ”部 分 ， 如 Title，ActionBar 等 (最 终 是 否 要 显示 这 
些 “ 装 饰 ”， 则 取决 于 应 用 程序 自身 的 需求 〉。 


产生 DecorView 的 过 程 是 由 setContentView 发 起 的 ， 这 也 就 是 开发 
需要 在 onCreate 时 调用 这 个 函数 的 原因 。 而 onCreate 本 身 则 是 由 
mlnstrumentation. cal |ActivityOnCreate (activity, r. state) 间接 调 


用 的 ， 有 兴趣 的 读者 可 以 自行 分 析 。 


Activity 中 的 setContentView 只 是 一 个 中 介 ， 它 将 通过 对 应 的 
Window 对 象 来 完成 DecorView 的 构造 : 


/*frameworks/base/policy/src/com/android/internal/policy/impl/Pho 
public void setContentView(int layoutResID) { 
if (mContentParent == null) {// 如 果 是 第 一 次 调用 这 个 函数 的 情况 下 
installDecor ( ) ;// 需 要 首先 生成 npecor 对 象 
} else { 
mContentParent.removeAllViews();// 不 是 第 一 次 调用 此 函数 ，5 








mLayoutInflater.inflate(layoutResID, mContentParent);// 根 j 


ae 


变量 mContentParent 是 一 个 ViewGroup 对 象 ， 它 用 于 容 
纳 “ContentView”。 当 mcContentParent 为 空 时 ， 说 明 是 第 一 次 调用 
setContentView。 此 时 mDecor 也 必定 为 室 ， 因 而 调用 instal1Decor 创 建 
一 个 DecorView; 否则 先 清理 mCcontentParent 中 已 有 的 所 有 View 对 象 。 
最 后 通过 1ayoutRes1D 来 inflate 新 的 内 容 (mContentParent 就 是 这 个 由 
layoutRes1D 生 成 的 View 树 的 根 ) 。 从 中 我 们 也 可 以 看 出 ， 
setContentView 在 应 用 进程 中 是 允许 多 次 调用 的 ， 只 是 一 般 不 这 么 做 。 


疯 数 instal1Decor 有 两 个 任务 ， 即 生成 mDecor 和 mContentParent。 
我 们 先 来 看 看 mDecor 的 生成 过 程 : 


private void installDecor() { 
if (mDecor == null) { 
mDecor = generateDecor(); 


} 


疯 数 generateDecor 实 际 上 只 是 new 一 个 DecorView 对 象 ， 而 返回 值 
则 赋予 mpecor 。Decoryview 继 承 自 FrameLayout， 后 面 就 能 看 到 这 样 做 的 
原因 。 


变量 mContentParent 的 创建 过 程 与 nDecor 有 关联 ， 代 码 如 下 : 


if (mContentParent == null) { 
mContentParent = generateLayout(mDecor ) ; 





} 
}//installDecor 结 束 


可 以 看 到 ，mContentParent 是 通过 generateLayout 国 数 生 成 的 : 


protected ViewGroup generateLayout(DecorView decor) { 
TypedArray a = getwindowStyle( );// 获 取 窗 口 样式 
mIsFloating =a.getBoolean(com.android.internal.R.styleable 
ting, false); 





int layoutResource; 
int features = getLocalFeatures(); 
if ((features & ((1 << FEATURE_LEFT_ICON) | (1 << FEATURE_ 
..V/ 根 据 具体 的 样式 为 layoutResource 挑 选 匹 配 的 资源 
} else if ((features & ((1 << FEATURE_PROGRESS) | (1 << 
FEATURE_INDETERMINATE_PROGRESS))) != 0 
&& (features & (1 << FEATURE_ACTION_BAR)) == 











else if ((features & (1 << FEATURE_CUSTOM_TITLE)) != 0) 
else if ((features & (1 << FEATURE_NO_TITLE)) == 0) { 


else if ((features & (1 << FEATURE ACTION _MODE_OVERLAY) ) 


WY YY Zw 


else { 
} 


View in = mLayoutInflater.inflate(layoutResource, null);// 
decor .addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, 
ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDRO 


return contentParent,; 


} 
上 面 的 代码 段 分 为 3 个 步骤 。 


e 取出 Window 样 式 ， 如 windowIsFloating、windowNoTite， 
windowFullscreen 等 。 这 是 通过 分 析 styleable.Window 获 得 的 ， 如 下 : 


mWindowStyle = mContext.obtainStyledAttributes(com.android.intern 


e 根据 上 一 步 得 出 的 样式 来 挑选 符合 要 求 的 layout 资 源 ， 并 由 
layoutResource 来 表示 。 


比如 通过 以 下 语句 : 





(features & ((1 << FEATURE_LEFT_ICON) | (1 << FEATURE_RIGHT_ICON) 


可 以 得 知 应 用 程序 的 U1 表面 是 否 需要 左 、 右 两 个 icon 一 一 满足 这 一 
要 求 的 layout 也 有 两 种 ， 我 们 还 需要 根据 mlsFloat ing 进 一 步 决定 是 
com. android. internal.R. attr. dialogTitlelconsDecorLayout 或 者 
com. android. internal.R. layout. screen title_icons。 顺 便 提 一 下 ， 
系统 framework 提 供 的 这 些 默认 1ayout 文 件 统一 存放 在 
frameworks/base/core/res/res/layout#. 


其 他 几 个 else 分 支 的 处 理 过 程 都 类 似 ， 读 者 可 以 自行 阅读 。 要 特别 
注意 的 是 ， 不 论 哪 种 layout 都 必须 包含 id 值 为 “content” 的 View 对 
象 ， 否 则 将 发 生 异 常 。 


e 4% JE layoutResource4¥ Æ HY layout(xml) x 4} , 来 inflate 出 相应 的 View 对 
象 。 然 后 把 这 一 新 对 象 addView 到 mDecor (DecorView 是 一 个 
FrameLayout) 中 ; 最 后 ， 整 个 genetateLayout 函 数 的 返回 值 是 一 个 id 
4 ID_ANDROID_CONTENT= com.android.internal.R.id.content 的 对 
2, EN mContentParent. 





DecorView 的 布局 之 一 如 图 11-5 所 示 。 
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全 图 11-5 DecorView 的 布局 之 一 


由 此 可 知 ，setContentView 实 际 上 做 的 工作 就 是 把 应 用 程序 想 要 显 
示 的 视图 (ContentView) 加 上 系统 策略 中 的 其 他 元 素 〈 比 如 Title， 
Action) ， 合 成 出 用 户 所 看 到 的 最 终 应 用 程序 的 界面 〈 如 图 11-5 所 
示 ) 。 需 要 注意 的 是 ，setContentView 并 不 负责 将 这 一 视图 真正 地 显示 
出 来 。 有 一 个 实验 也 可 以 证 明 一 点 ， 读 者 可 以 尝试 在 Activity 中 不 调用 
setContentView， 看 下 最 终 应 用 程序 的 表面 是 否 还 能 照常 显示 出 来 一 一 
只 是 中 间 的 “content” 部 分 为 空 而 已 。 


顺便 说 一 下 ，Android 系 统 不 同 版 本 间 的 U1 办 面 样式 差异 不 小 。 
而 如 果 是 需要 兼容 多 个 版 本 的 应 用 程序 ， 在 Release 之 前 最 好 挑选 几 个 
有 代表 性 的 版 本 进行 测试 一 一 特别 是 需要 针对 Android 2.3、2. 2 和 3.0 
以 上 的 3 种 版 本 进行 验证 ， 因 为 它们 之 间 的 变更 最 大 。 


比如 应 用 程序 中 很 常用 的 Menu 〈 总 共有 3 类 ) ， 在 不 同 版 本 间 的 样 
式 区 别 如 下 。 


e Options Menu/ Action Bat 


这 是 最 常用 的 一 类 菜单 。 在 Android 2. 3 版 本 以 下 ， 通 过 按 Menu 键 
就 可 以 调 出 来 (显示 在 底部 ) ; 而 且 如 果菜 单 选 项 超过 6 个 ， 还 会 
现 “More” 的 字样 。 而 3. 0 以 后 的 版 本 ， 则 被 Action Bar 所 取代 。 两 者 
的 区 别 如 图 11-6 所 示 。 


e Context Menu/Contextual Action Mode 


从 名 称 可 以 推断 出 ， 它 是 和 “上 下 文 环 境 ” 有 关联 的 一 类 菜单 。 比 
如 我 们 可 以 通过 长 按 Listyiew 的 某 个 Item 来 调 出 它 的 Context Menu。 这 
类 菜单 在 3.0 以 上 版 本 系统 中 有 两 种 可 选 的 样式 ， 即 Context Menu 和 
Contextual Action Mode。 前 者 是 Floating Menu， 即 悬浮 于 当前 界面 
之 上 ， 而 后 者 则 是 通过 在 屏幕 上 方 显 示 一 条 操作 栏 来 提供 操作 再 面 〈 这 
种 设计 的 特点 是 “内 容 ” 不 会 被 挡住 ， 因 而 可 以 方便 用 户 选 择 多 个 元 
素 ， 如 文件 管理 器 中 的 批量 删除 ) 。 它 们 的 区 别 如 图 11-7 所 示 。 


O 


3.0 以 上 版 本 的 Action Bar， 除 了 最 右边 
的 默认 按钮 外 ， 用 户 还 可 以 自 定义 需要 


显示 的 Action。 比 如 图 中 的 Camera 图 标 
就 是 自 定义 的 
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Context Menu Contextual Action Mode 
全 图 11-7 Context Menu#eContextual Action Mode 的 区 别 


e Popup Menu 


弹出 式 菜单 和 其 他 样式 最 大 的 区 别 在 于 其 出 现 位 置 是 基于 激活 它 的 
View 而 定 的 ， 这 样 用户 融 很 清楚 这 一 菜单 是 针对 表面 中 的 哪个 View 而 设 
置 的 了 。 


2. handleResumeActtvity 


通过 performLaunchActivity，Activity 内 部 已 经 完成 了 Window 和 
DecorView 的 创建 过 程 。 可 以 说 整 棵 View Tree 实际 上 已 经 生成 了 ， 只 不 
过 还 不 为 外 办 所 知 。 换 句 话说 ， 无 论 是 WMS 还 是 SurfaceFlinger， 都 还 
不 知道 它 的 存在 。 所 以 接 下 来 还 需要 把 它 添加 到 本 地 的 
WindowManagerGlobal 〈 还 记得 吗 ? WindowManagerGlobal 中 有 3 个 数 
组 mViews，mRoots 和 和 mParams) ， 继 而 注册 到 WMS 里 。 


这 其 中 就 涉及 ViewRoot Imp1 的 相关 操作 : 


final void handleResumeActivity(...) {... 
ActivityClientRecord r = performResumeActivity(token, cle 
Activity. onResume 最 终 被 调用 */ 
if (r != null) { 
final Activity a = r.activity; 


if (r.window == null && !a.mFinished && willBeVisible 

r.window = r.activity.getWindow( );//Activityx if 
View decor = r.window.getDecorView( );//i SbF mDec 
decor.setVisibility(View. INVISIBLE) ;// 先 设置 为 不 可 页 
ViewManager wm = a.getwindowManager();//BIWindowMe 
WindowManager.LayoutParams 1 = r.window.getAttrib 
a.mDecor = decor; 
1.type = WindowManager .LayoutParams.TYPE_BASE_APP 
1.softInputMode |= forwardBit; 
if (a.mVisibleFromClient) { 

a.mWindowAdded = true; 

wm.addView(decor，1);// 首 先 添加 decor 到 本 地 的 全 局 i 


} 
} else if (!willBeVisible) { 


} 


我 们 将 上 述 函 数 中 涉及 的 相关 重点 部 分 高 亮 显 示 ， 以 方便 大 家 阅 
读 。 可 以 看 到 ， 变 量 wm 声 明 的 类 型 是 ViewManager 。 这 是 因为 
WindowManager 继 承 自 ViewManager， 而 getWindowManager 真 正 返回 的 是 
一 个 WindowManager Imp1 对 象 。 后 者 的 addview 又 间接 调用 了 
WindowManager Global 中 的 实现 : 


/*frameworks/base/core/java/android/view/WindowManagerGlobal. java 
public void addView(View view, ViewGroup.LayoutParams params, 


Display display, Window parentWindow) {... 
ViewRootImpl root; 
View panelParentView = null; 
synchronized (mLock) {... 
int index = findViewLocked(view，false);// 是 不 是 添加 过 上 | 


root = new ViewRootImpl(view.getContext(), display);/ 
ViewRoo 
view.setLayoutParams(wparams ) ; 
if (mViews == null) {// 第 一 次 添加 元 素 到 mViews 中 
index = 1; 
mViews new View[1]; 
mRoots new ViewRootImp1l[1]; 
mParams = new WindowManager.LayoutParams[1]; 
} else {// 不 是 第 一 次 操作 
.…/ /动态 分 配 数组 容量 ， 代 码 省 略 











index--; 
mViews[index] = view; 
mRoots[index] = root; 
mParams[index] = wparams; 
} 
try { 


root.setView(view, wparams, panelParentView);// 将 View; 
} catch (RuntimeException e) {... 
} 
} 


如 果 上 面 代码 段 中 的 index 小 于 0， 表 示 之 前 未 添加 过 此 View 对 象 ， 
因而 程序 可 以 继续 执行 ;否则 说 明 调用 者 多 次 添加 了 同一 个 View 对 象 ， 
因而 函数 直接 返回 。 


接 下 来 addyiew 需 要 添加 一 个 新 的 ViewRoot1mp 1 到 
WindowManagerGlobal 的 mRoots 数 组 中 。 由 于 事先 并 不 知道 一 个 应 用 程 
序 中 会 有 多 少 ViewRoot 存 在 ，WindowManagerGlobal 采 用 的 是 动态 存储 
方法 。 具 体 细节 在 前 面 章节 已 经 做 过 分 析 ， 这 里 不 再 整 述 。 


除了 mRoots，WindowManagerGlobal 中 还 有 另外 两 个 重要 数组 。 其 
中 mViews 记 录 的 是 DecorView，mParams 记 录 的 是 布局 属性 。 这 3 个 数组 
中 的 元 素 是 一 一 对 应 的 ， 即 同一 个 index 在 3 个 数组 中 得 到 的 元 素描 述 的 
是 同一 个 Activity 中 的 View 树 、ViewRoot 和 布局 属性 。 


wA, AUE root. setView 把 DecorView 同 步 记 录 到 


ViewRoot1Imp1 内 部 的 myiew 变 量 中 。 因 为 后 面 ViewRoot1mp1 将 会 频繁 访 
问 到 这 棵 View Tree 比如 当 收 到 某 个 按键 事件 或 者 触摸 事件 时 ， 需 
要 把 它 传 递 给 后 者 进行 处 理 。 


由 此 一 个 Activity 中 的 一 棵 View Tree 就 完整 地 建立 起 来 ， 并 纳入 
本 地 的 全 局 管理 中 。 不 过 需要 指出 的 是 ， 到 目前 为 止 我 们 的 分 析 仍 然 停 
留 在 本 地 应 用 进程 中 。 或 者 说 我 们 还 没 看 到 与 WMS 及 SurfaceF1inger 发 
生 实 质 性 交互 的 地 方 ， 如 向 WMS 申请 一 个 用 于 显示 的 窗口 〈 注 意 和 
PhoneWindow 的 概念 区 别 开 来 ) ; 也 还 没有 分 析 View Tree 中 的 各 个 对 象 
是 如 何 借用 这 个 Wi ndow 来 绘制 最 终 的 UI 内 容 的 。 


接 下 来 将 为 读者 一 一 揭 开 这 些 问题 的 答案 。 





11.3 在 WMS 中 注册 窗口 


上 一 节 我 们 虽然 看 到 了 整 棵 View Tree 的 建立 过 程 ， 但 整个 分 析 还 
没有 跳出 应 用 程序 进程 的 范畴 。 


首先 还 要 再 次 强调 一 下 “窗口 ”的 概念 ， 以 免 引 起 混淆 。 本 章 前 几 
个 小 节 提 到 的 PhoneWindow 继 承 自 Window 类 ， 它 表达 了 窗口 的 一 种 约束 
机 制 ; 而 WMS 中 的 Window 则 是 一 个 抽象 的 概念 ， 其 有 一 个 WindowState 用 
于 描述 状态 。 如 果 读 者 还 是 觉得 比较 困惑 的 话 ， 也 可 以 简单 地 理解 : 
PhoneWindow 是 应 用 进程 端 对 于 “窗口 ”的 描述 ，WindowState 则 是 WMS 
中 对 “窗口 ”的 描述 。 

当 ViewRoot1mp1 构 造 的 时 候 ， 它 需要 建立 与 WMS 通信 的 双向 通道 。 
前 面 已 经 讨论 过 了 ， 分 别 是 : 


e ViewRootImplWMS: IwindowSession ; 
e WMSViewRootlmpl: Iwindow. 


因为 WMS 是 在 Servi ceManager 中 注册 的 实名 Binder Server ( 详 见 
Binder 章 节 的 描述 ) ， 因 而 任何 程序 都 能 在 任何 时 候 通 过 向 Service 
Manager 发 起 查询 来 获取 WMS 的 服务 。 而 IWindowSession 和 IWindow 则 是 
两 个 匿名 的 Binder Server， 它 们 需要 借助 一 定 的 万 式 才 能 提供 服务 。 


其 流程 如 图 11-8 所 示 。 
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全 图 11 一 8 如 何在 WMS 中 注册 窗口 


Step1. ViewRoot1mp1| 在 构造 涵 数 中 ， 首 先 会 利用 WMS 提 供 的 
openSession 接 口 打 开 一 条 Session 通 道 ， 并 存储 到 内 部 的 


mWindowSessionas =H: 


public ViewRootImpl(Context context, Display display) 4... 
mWindowSession = WindowManagerGlobal.getwWindowSession();// 


mwindow = new W(this);//IWindow 
} 
水 数 getWindowSession 负 责 建 立 应 用 程序 与 WMS 间 的 Session 连 接 : 


public static IWindowSession getWindowSession() { 
synchronized (WindowManagerGlobal.class) { 
if (sWindowSession == null) { 


try { 
InputMethodManager imm = InputMethodManager.ge 
IWindowManager windowManager = getWindowManage 
sWindowSession = windowManager .openSession(imm 
imm. 


} catch (RemoteException e) { 
Log.e(TAG, "Failed to open window session", e) 


return sWindowSession; 


如 果 sWindowSess ion 不 为 空 ， 那 么 就 没 必 要 再 重复 打开 Session 连 
接 了 ; 否则 需要 先 通过 ServiceManager 来 获取 WMS 服务 ， 再 利用 它 提供 
的 openSession 接 口 来 建立 与 WMS 的 “通道 ”。 


有 必要 说 明 的 是 ， 上 述 代 码 段 中 的 windowManager 变 量 和 前 一 小 节 
handleResumeActivity 中 见 到 的 WindowManager 对 象 是 不 一 样 的 ， 我 们 
特别 把 它们 列 出 来 进行 比较 。 


在 handleResumeActivity 中 : 


ViewManager wm = a.getWindowManager(); 


这 人 句 代 码 中 的 wm 是 ViewManager， 即 WindowManager 类 的 基 类 ， 
则 由 WindowManager 1mp1 来 实现 。 


而 上 面 的 windowManager 变 量 则 是 : 


public static IWindowManager getWindowManagerService() { 
synchronized (WindowManagerGlobal.class) { 
if (sWindowManagerService == null) { 
sWindowManagerService = IWindowManager.Stub.asInt 
ServiceManager .getService("window" ) ); 


return sWindowManagerService; 


} 


我 们 可 以 这 么 理解 这 两 种 WindowManager : 其 中 一 种 完全 是 属于 本 
地 端的 ， 存 储 于 应 用 进程 内 部 用 于 窗口 管 理 的 相关 事务 ; 男 一 种 则 是 
WindowManagerService 在 本 地 进程 中 的 代理 。 前 省 最 终 由 
WindowManager Imp1 来 实现 ， 而 后 者 则 是 由 WindowManagerService 在 远 
程 端 实现 。 


Step2.， 在 前 一 小 节 我 们 看 到 ， 哨 数 addView 在 最 后 会 调用 
ViewRoot Imp!. setView 这 个 国 数 一 方面 会 把 DecorView， 也 就 是 
View 树 的 根 设置 到 VierRootImp1 中 ; 另 一 方面 会 向 WMS 申请 注册 一 个 窗 
口 ， 同 时 将 ViewRoot1mp1 中 的 W (1Window 的 子 类 )〉 对 象 作为 参数 传递 给 
WMS 。 





/*frameworks/base/core/java/android/view/ViewRootIimpl. java*/ 
public void setView(View view, WindowManager.LayoutParams att 
View panelParent View) { 
synchronized (this) { 
if (mView == null) { 
mView = view;//ViewRoot 内 部 记录 了 它 所 管理 的 View 树 的 根 




















requestLayout();// 执 行 Layout 


try £... 
res = mWindowSession.addToDisplay(mWindow, mS 
getHostVisibility(), mDisplay.getDisp 
mAttachInfo.mContentInsets, mInputCha 
} catch (RemoteException e) {... 


} finally 4... 
J 


} 


关于 requestLayout 所 引发 的 遍历 过 程 ， 可 以 参见 后 面 小 节 的 介 
绍 ， 这 里 先 不 做 详细 分 析 。 上 述 代码 段 中 最 关键 的 一 步 ， 就 是 通过 
IWindowSession 提 供 的 addToDisplay (这 个 函数 将 调用 WMS 的 
addWindow) ， 向 WMS 申请 注册 一 个 窗口 。 这 些 内 容 在 前 一 章节 讲解 WMS 
时 已 经 系统 讨论 过 ， 不 清楚 的 读者 可 以 返回 复习 下 。 


11.4 ViewRoot 的 基本 工作 方式 


在 讲解 View 树 中 具体 的 事务 处 理 前 ， 有 必要 先 给 大 家 分 析 下 
ViewRoot 的 基本 工作 方式 ， 这 有 助 于 大 家 在 接 下 来 众多 烦琐 问题 的 剖析 
中 把 握 事 件 的 核心 。 


我 们 知道 ， 每 棵 View Tree 只 对 应 一 个 ViewRoot， 它 将 和 
WindowManagerService 进 行 一 系列 的 通信 ， 包 括 窗口 注册 、 大 小 调整 等 
(可 以 参见 1WindowSession 提 供 的 接口 方法 ) 。 那 么 ，ViewRoot 在 什么 
情况 下 会 执行 这 些 操作 呢 ? 


主要 的 触发 源 有 两 种 : 
e View Tree 内 部 的 请 求 


比如 某 个 View 对 象 需 要 更 新 U1 时 ， 会 通过 invalidate 或 者 其 他 方 
式 发 起 请 求 。 随 后 这 些 请 求 会 沿 着 View 最 终 到 达 
ViewRoot 这 个 View Tree 的 管理 者 再 根据 一 系列 实际 情况 来 采取 相 
应 措施 〈 比 如 是 否 发 起 一 次 遍历 、 是 否 需 要 通知 WMS 等 ) 。 


。 外 部 的 状态 更 新 


除了 内 部 的 变化 外 ，ViewRoot 同 样 可 以 接收 来 自 外 部 的 各 种 请 求 。 
比如 WMS 会 回调 ViewRoot 通 知 磺 面 大 小 改变 、 触 摸 事 件 、 按 键 事件 等 。 


不 论 是 内 部 还 是 外 部 的 请 求 ， 通 常情 况 下 ViewRoot 并 不 会 直接 去 处 
理 它 们 ， 而 是 先 把 ; FA Da BOR SCE. ViewRoot 内 部 定义 了 
ViewRootHand1er 类 来 对 这 些 消息 进行 统一 处 理 。 有 意思 的 是 ， 这 个 
Handler 实 际 上 是 和 主线 程 的 MessageQueue 挂 钧 的 ， 这 也 就 验证 了 
ViewRoot 相 关 的 操作 确实 是 在 主线 程 中 进行 的 。 正 因为 此 ， 我 们 在 
ViewRootHandler 中 执行 具体 的 事件 处 理 时 要 特别 注意 不 要 有 耗 时 的 操 
作 ， 否 则 很 可 能 会 阻塞 主线 程 而 引发 ANR。 


ViewRoot 的 工作 流程 可 以 概括 如 图 1 1 -9 所 示 。 


图 中 各 种 内 外 部 请 求 和 状态 更 新 都 首先 入 队 到 程序 主线 程 的 
MessageQueue 中 ， 再 由 ViewRoot 具 体 处 理 。 这 样 做 避免 了 应 用 程序 因 长 





时 间 处 理 某 个 事件 而 导致 的 响应 速度 降低 ， 我 们 在 平时 的 项 目 研发 中 可 
A eo 
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全 图 11-9 ViewRoot 的 一 般 工 作 流 程 


11.5 View Tree 的 遍历 时 机 


Brig “Wal” (Traversal) ， 是 指 程序 按照 一 定 的 算法 路 径 依次 
对 一 个 集合 《如 View Tree) 中 的 所 有 元 素 进行 有 且 仅 有 一 次 访问 的 过 
程 。 相 信 学 过 数据 结构 的 读者 对 此 并 不 陌生 。 那 么 体现 到 Android 的 
View 体 系 中 ，“ 人 遍历 ”意味 着 什么 昵 ? 


先 来 思考 以 下 两 点 ， 
。 人 多 与 子 


我 们 知道 ，View Tree 中 的 各 元 素 是 有 “父子 ”关系 的 ， 即 最 顶层 
的 元 素 是 第 二 层 元 素 “ 如 果 存 在 的 话 ) 的 “父亲 ”， 依 此 类 推 。 


。 如 何 协 调 View Tree 中 所 有 元 素 的 显示 需求 


如 果 整 个 U1 界面 只 是 由 单一 的 View 对 象 来 描述 的 ， 那 么 很 简单 一 一 
它 既 可 以 占据 整个 屏幕 空间 ; 也 可 以 有 选择 地 在 屏幕 任何 一 片区 域 上 显 
示 。 不 过 这 种 理想 的 情况 是 不 存在 的 。 通 常 我 们 面 对 的 View 树 层级 都 较 
深 ， 涉 及 的 View 对 象 数量 众多 。 此 时 系统 就 要 综合 考虑 各 个 View 提 出 
的 “需求 ”了 。 上 比如 它们 都 希望 占据 整个 屏幕 ， 或 者 都 希望 从 (0, 0) 
坐标 点 开始 绘图 ， 怎 么 办 呢 ? Android 的 遍历 机 制 则 必须 以 尽 可 能 公平 
的 万 式 解决 这 些 问题 。 


View 体 系 中 的 “遍历 ”， 简 而 言 之 就 是 系统 综合 考量 各 元 素 “ 请 
求 ”的 过 程 。 当 “遍历 ”结束 后 ， 各 个 View 元 素 就 能 得 到 系统 的 最 终 分 
配 结果 。Android 系 统 要 求 所 有 元 素 都 服从 它 的 “安排 ”， 否 则 很 可 能 
会 产生 未 知 的 错误 。 从 上 面 的 分 析 可 以 知道 ，“ 分 配 结果 ”最 少 会 包含 
两 方面 内 容 ， 即 View 对 象 的 尺寸 大 小 和 位 置 一 一 再 加 上 View 自 身 的 U1 内 
gee NARI 0 a 
LTE o 


在 此 之 前 还 要 解决 一 个 问题 应 用 程序 在 什么 情况 下 会 遍历 View 
TreelE ? 


1. 应 用 程序 刚 启 动 时 


根据 前 面 几 个 小 节 的 分 析 ， 应 用 程序 启动 后 会 逐步 构造 出 自己 的 整 
棵 View Tree， 然 后 进行 一 次 全 面 的 遍历 : 


public void setView(View view, WindowManager.LayoutParams attrs, ` 

// Schedule the first layout -before- adding to the windo 

// manager, to make sure we do the relayout before receiv 

// any other events from the system.// 从 注释 中 也 可 以 看 出 这 是 和 
requestLayout(); 


在 setView 中 调用 的 requestLayout 就 是 执行 第 一 次 遍历 的 触发 源 。 
这 个 函数 将 通过 向 Choreographer 注 册 一 个 CALLBACK_TRAVERSAL 回 调 事 
件 来 间接 驱动 Layout 的 执行 。 最 终 的 “遍历 ”工作 由 
performTraversals 来 完成 ， 我 们 放 在 后 续 小 节 统 一 分 析 。 


2. 外 部 事件 


对 于 应 用 程序 来 说 ， 外 部 事件 才 是 驱动 ViewRoot 工 作 的 主要 触发 
源 。 比 如 由 用 户 产生 的 触摸 、 按 键 等 事件 ， 经 过 层 层 传递 最 终 分 配 到 应 
用 进程 中 。 这 些 事件 除了 可 以 改变 应 用 程序 的 内 部 状态 外 ， 还 可 能 影响 
到 U1 界面 的 显示 一 一 在 必要 的 情况 下 ，ViewRoot 就 会 通过 人 遍历 来 确定 事 
件 对 各 View 对 象 产生 的 具体 影响 。 


3. 内 部 事件 


除了 外 来 触发 源 ， 程 序 在 自身 运行 的 过 程 中 有 时 也 需要 主动 发 起 一 
些 触 发 事件 。 比 如 我 们 写 一 个 时 钟 应 用 ， 最 少 每 隔 一 秒 就 需要 刷新 一 次 
界面 ; 又 比如 当 一 个 View 的 Visibi1ity 从 GONE 到 VI1SIBLE， 都 涉及 界面 
的 调整 和 重 绘 。 所 以 程序 在 这 些 情况 下 要 主动 请 求 系统 进行 界面 刷新 ， 
并 可 能 引发 遍历 的 执行 。 


下 面 先 来 举 几 个 例子 ， 看 看 ViewRoot 在 什么 情况 下 会 发 起 “ 遍 
历 ” > 


1. View.requestLayout 


View 对 象 可 以 通过 调用 requestLayout () REJAH EA. XAA 
数 的 实现 很 简单 ， 如 下 所 示 : 


/*frameworks/base/core/java/android/view/View. java*/ 
public void requestLayout() {... 


mPrivateFlags |= PFLAG_FORCE_LAYOUT; 

mPrivateFlags |= PFLAG_INVALIDATED; 

if (mParent != null && !mParent.isLayoutRequested()) { 
mParent .requestLayout();// 把 请 求 往 上 一 层 传递 

} 


i; 


上 述 代 码 段 首先 置 位 View 内 部 变量 mPrivateFlags 中 的 相关 标志 。 
在 Android4. 3 系统 中 ，View 类 中 专门 用 于 记录 各 种 flag 标 志 的 变量 就 有 
3 个 ， 以 满足 不 断 增加 的 功能 需求 。PFLAG ”FORCE_LAYOUT 表 明 这 是 程序 
自发 的 layout 请 求 ， 它 将 在 随后 开展 的 遍历 流程 中 产生 作用 。 


接着 主动 发 起 遍历 的 View 对 象 需 要 把 这 一 请 求 提交 给 它 的 父亲 
(ViewParent) ， 即 mParent. requestLayout () 。 这 个 ViewParent 既 可 
能 是 ViewGroup， 也 可 能 是 ViewRoot 。 前 者 没有 重 写 requestLayout 这 个 
方法 ， 所 以 会 直接 采用 View 类 中 的 实现 ， 即 继续 向 上 一 级 父 类 传递 请 
K; 而 如 果 ViewParent 是 ViewRoot， 则 处 理 如 下 : 


public void requestLayout() { 
if (!mHandlingLayoutInLayoutRequest) { 
checkThread( ) ;// “4H G AE ZEAE ( BUZE RViewRoot Impl xt RAZ 
mLayoutRequested = true;// 当 前 已 经 发 起 Layout 申 请 
scheduleTraversals();// 安 排 一 次 Traversal 





第 一 行 是 检查 当前 是 否 为 主线 程 一 一 因为 Android 系 统 规定 只 有 主 
线程 才能 够 操作 U1 对 象 。 这 也 确保 了 接 下 来 的 操作 中 不 会 出 现 多 个 线程 
同时 访问 的 情况 ， 因 而 不 再 需要 特别 的 同步 机 制 。 第 二 行 代 码 的 
mLayoutRequested 用 于 表示 当前 是 否 已 经 有 用 户 发 起 了 Layout 请 求 ， 这 
A ene ae ae er ene ee 
统一 分 析 。 


2. View.setLayoutParams 


这 个 方法 用 于 设置 一 个 View 对 象 的 各 种 布局 属性 : 


public void setLayoutParams(ViewGroup.LayoutParams params) 4... 
requestLayout(); 
} 


也 就 是 说 ， 当 View 的 布局 发 生变 化 时 ， 它 会 主动 申请 一 次 遍历 。 如 
np av Cmte VIGNE) OUD: 就 会 回调 onSetLayoutParams 通 知 父 类 进行 相 
应 的 调整 ， 然 后 直接 调用 前 面 分 析 过 的 requestLayout 函 数 。 


3. View.invalidate 


“invalidate” 从 字面 意思 看 是 “使 无 效 ”， 即 将 当前 的 UI A mF 
ati ee 过 程 。 要 特别 注意 这 个 函数 只 能 从 UI 线程 调 
其 他 线程 则 需 过 postlnval idate 来 实现 同样 的 ? 效果 。 


在 View. java 中 ，invalidate 有 多 个 带 不 同 参数 的 国 数 实现 。 如 下 
Pam: 


public void invalidate(Rect dirty); 

public void invalidate(int 1, int t, int r, int b); 
public void invalidate(); 

void invalidate(boolean invalidateCache) ; 


BUPA TP eR SPIT RA 的 意思 相同 ， 它 们 的 参数 都 用 于 指定 需 
被 “invalidate” 的 无 效 区 域 。 只 不 过 其 中 一 个 用 Rect 表 示 ， 另 一 个 则 
用 left，top，right 和 bottom 表 示 。 第 三 个 痕 数 则 是 oo 数 的 便 
捷 实 现 ， 即 inval idate (true) 。 


可 见 这 几 个 函数 形式 各 异 ， 但 基本 思想 是 一 样 的 。 因 而 我 们 只 挑选 
一 个 函数 来 做 具体 分 析 : 


public void invalidate(Rect dirty) { 
if (skipInvalidate()) {//Invalidate# Aik? 
return; 





} 

if ((mPrivateFlags & (PFLAG_DRAWN | PFLAG HAS BOUNDS)) == 
(PFLAG_DRAWN | PFLAG_HAS_ BOUNDS) | | (mPrivateFlags&PFLAG_ 

PFLAG_DRAWING_CACHE_VALID || (mPrivateFlags & PFLAG_INVALIDATED) 

mPrivateFlags &= ~~PFLAG_DRAWING_CACHE_VALID; 
mPrivateFlags |= PFLAG_INVALIDATED; 
mPrivateFlags |= PFLAG_DIRTY; 
final ViewParent p = mParent; 
if (!HardwareRenderer.RENDER_DIRTY_REGIONS) {// 是 否 需 要 


if (p != null && ai != null && ai.mHardwareAccele 
p.invalidateChild(this, null); 
return; 


} 

if (p != null && ai != null) { 
final int scrollX = mScrollx; 
final int scrollY = mScrolly; 
final Rect r = ai.mTmpInvalRect; 
r.set(dirty.left - scrollxX, dirty.top - scrolly, d 
dirty.bottom - scrolly); 
mParent.invalidateChild(this, r); 


J 


首先 ，skiplnvalidate () 用 于 判断 是 否 要 忽略 这 个 inval idate 操 
1E; 因为 如 果 当 前 View 并 不 是 可 见 的 ， 而 且 也 不 在 执行 动画 ， 那 么 进行 
inval idate 是 没有 意义 。 


接 下 来 需要 满足 以 下 3 个 条 件 之 一 ， 才 可 以 进行 jnval idate。 
emPtivateFlags 中 有 PFLAG_DRAWN 和 PEFLAG_HAS_BOUNDS 标 志 


View 中 有 3 个 PrivateFlags， 即 mPrivateFlags，mpPrivateFlags2 和 
mPrivateFlags3。 其 中 每 个 变量 最 多 支持 32 个 标志 ， 这 些 属性 基本 概括 
整个 View 的 特点 。 由 于 数量 较 多 ， 我 们 只 列 出 和 分 析 相 关 的 几 个 标志 
JEX. 


PFLAG DRAWN: 当 View 表 达 出 重 绘 意愿 后 ， 设 这 个 bit 为 1， 以 保证 
inval idate 的 执行 。 


PFLAG HAS BOUNDS: 这 个 View 对 象 所 占据 的 区 域 边界 已 经 确认 。 





。 或 者 有 PFLAG_DRAWING_CACHE_VALID 标 志 。 这 个 标志 指明 此 
View 对 象 的 cache 是 否 也 需要 被 invalidate， 通 常会 在 一 个 full invalidate 
中 使 用 。 

。 或 者 有 PFLAG_INVALIDATED 标 志 ， 这 个 标志 用 于 指示 我 们 是 否 
需要 重建 View 的 display list。 


紧 接 着 函数 会 依次 设置 几 个 标志 位 ，PFLAG_INVALIDATED 表 示 我 们 
调用 了 invalidate 这 个 函数 ; PFLAG_DIRTY 表 示 有 相应 的 区 域 需要 绘 
制 | 。 这 些 标志 将 在 随后 的 ViewTree 人 遍历 过 才 程 中 发 挥 作 用 。 


RENDER_DIRTY_REGIONS 表 示 是 否 只 刷新 di rty 区 域 。 当 这 个 值 为 
fal se 时， 就 需要 刷新 整个 区 域 ; 否则 我 们 必须 特别 指明 需要 重新 绘制 
的 区 域 〈 即 di rty 区 ) . WRR ALEEA Kil, HAN RASA 
FAViewParent. invalidateChi1d 来 进一步 传递 invalidate 请 求 。 


虽然 ViewParent 既 有 可 能 是 ViewGroup， 也 有 可 能 是 ViewRoot， 但 
沿 着 View Tree 层 层 往 上 传递 后 ， 事 件 最 终 还 是 得 由 后 者 来 处 理 ， 如 图 
11-10 所 示 。 


ViewGroup ci 


invalidateChild > tnvalidateChildlnParent 


invalidateChild +» invalidateChildlnParent 


invalidate 





他 图 11-10 invalidate% 4.99 74 A A4 A 


ViewGroup 和 ViewRoot 中 都 拥有 同名 的 invalidate Child, (Bt) 
所 担负 的 责任 却 有 很 大 的 差异 。 前 者 是 “从 下 而 上 ”的 ， 可 以 理解 为 从 
当前 点 开始 ， 沿 着 ViewTree 回 漳 收 集 dirty 区 〈 即 需要 重 绘 的 区 域 ) 的 
过 程 ; 而 后 者 则 是 “从 上 而 下 ”的 ， 它 将 真正 发 起 ViewTree 的 所 历 ， 从 


而 实现 画面 的 重 绘 。 
4. dispatchAppVisibility 


当 应 用 程序 的 可 见 性 发 生变 化 时 〈 比 如 通过 startActivity 局 动 了 
一 个 新 Activity， 那 么 系统 会 通知 前 一 个 Activity 它 的 可 见 状 态 发 生 了 
变化 ) ， 会 调用 这 个 函数 。 


一 旦 ViewRoot Imp1 收 到 Visibility 改 变 的 消息 ， 也 会 组 织 一 次 
Traversal. 


通过 这 几 个 例子 ， 我 们 不 难 发 现 一 一 不 论 是 外 部 还 是 内 部 事件 ， 只 
要 ViewRoot 在 处 理 过 程 中 发 现 它 可 能 引发 由 表面 的 大 小 、 位 置 等 属性 的 
变化 ， 那 么 就 很 可 能 会 执行 “人 遍历” 操作。 遍历 的 主导 者 自然 还 是 
ViewRoot Imp1， 因 为 只 有 它 才 能 自 上 而 下 地 管理 整 棵 View Tree. 


遍历 流程 的 入 口 如 下 : 


/*frameworks/base/core/java/android/view/ViewRootIimpl.java* 
void scheduleTraversals() { 
if (!mTraversalScheduled) {// 当 前 是 否 已 经 在 做 遍历 了 
mTraversalScheduled = true; 





mChoreographer . postCallback ( 
Choreographer .CALLBACK_TRAVERSAL, mTraversalR 


} 


变量 mTraversalScheduled 用 于 指示 当前 是 否 已 经 在 
做 “Traversal”， 以 避免 多 次 进入 。 整 个 函数 的 重点 是 
mChoreographer. postCallback， 在 前 面 讲解 WMS 时 曾 多 次 看 到 过 这 个 类 
它 是 “Project Butter” 项 目的 产物 。 如 果 对 这 部 分 内 容 有 不 清楚 
的 地 方 ， 请 参见 SurfaceFlinger 和 WMS 这 两 个 章节 。 





一 旦 VSYNC 信 号 来 临 ，mTraversalRunnable 中 的 run 国 数 将 被 调用 ， 
以 保证 在 最 短 的 时 间 内 有 序 地 组 织 U1 界 面 的 更 新 。 也 数 run 的 实现 也 很 
简单 ， 它 直接 调用 了 doTraversal: 


void doTraversal() { 
if (mTraversalScheduled) { 











mTraversalScheduled = false;// 变 量 在 这 里 就 复位 了 





try { 
performTraversals( );// 执 行 遍历 
} finally { 
Trace.traceEnd(Trace.TRACE_TAG_VIEW); 
} 


} 

可 以 看 到 ， 这 个 函数 也 并 不 是 最 终 执行 遍历 的 地 方 ， 还 需要 进一步 
调用 performTraversals。 后 者 的 实现 比较 复杂 ， 内 容 也 很 多 ， 我 们 在 
后 一 小 节 将 做 专门 的 介绍 。 


图 11-11 描 述 了 View 体 系 中 执行 遍历 的 时 机 。 


11.6 View Tree 的 遍历 流程 


上 一 小 节 说 过 ，UI1 显 示 的 3 要 素 是 尺寸 大 小 、 位 置 和 内 容 ， 它 们 在 
遍历 过 程 中 分 别 对 应 以 下 3 个 函数 : 


e performMeasure (尺寸 大 小 ) 


用 于 计算 View 对 象 在 Ul 界面 上 的 绘图 区 域 大 小 。 


Choreographer 





APPLICATION 


全 图 11-11 遍历 的 执行 时 机 
e petfotmLayout (位 置 ) 
用 于 计算 View 对 象 在 U1 界面 上 的 绘图 位 置 。 
e performDraw (绘制 ) 
上 述 两 个 属性 确定 后 ，View 对 象 就 可 以 在 此 基础 上 绘制 U1 内 容 了 。 
遍历 的 主体 是 performTraversals。 这 个 函数 虽然 长 达 七 百 多 行 ， 


但 整体 逻辑 就 是 按照 上 述 3 个 步骤 进行 的 。 分 析 时 一 定 要 抓 住 这 个 线 
索 ， 才 不 容易 偏离 主体 ， 如 图 11-12 所 示 。 


perform Traversals 





全 图 11-12 performTraversals 的 实现 主体 


所 以 接 下 来 的 重点 就 转 换 为 : 在 什么 条 件 下 需要 执行 以 上 3 个 动 
? 


首先 来 介绍 几 个 全 局 变量 的 含义 ， 如 表 11-1 所 示 。 


5211-1 performTraversals 中 涉及 的 部 分 重要 变量 





mView 是 该 ViewRoot 管 理 下 View 
Tree 的 根 节 点 。 函 数 在 执行 过 程 中 需 
要 频繁 使 用 到 这 个 变量 ， 为 了 避免 意 
MView (或 者 host) 外 的 算 改 ，performTraversals 函 数 开 
头 使 用 了 一 个 本 地 变量 host 来 指 回 
它 ， 后 面 的 操作 全 部 由 这 个 变量 完成 


判断 是 否 第 一 次 执行 
performTraversals 


mIsInTraversal 当前 是 否 在 执行 Traversal 


在 某 些 情况 下 ， 我 们 需要 重 绘 所 有 界 
mFullRedrawNeeded 面 ， 这 个 变量 将 影响 后 续 的 
performDraw 





在 很 多 情况 下 ，mLayoutRequested 都 
会 被 置 为 tue， 如 View 对 象 主动 发 起 
一 个 requestLayout; 第 一 次 调用 
performTraversals; 当前 的 宽 高 
(mWidth/mHeight) 和 期 望 的 值 H 
mWinFrame 记 录 ) 不 符合 等 


mLayoutRequested 





ho Ys am 


mFitSystemW indowsInsets Loe 内 、 的 oo 状 


| Peer 用 于 | 








记录 一 系列 相关 信息 。 比 如 其 中 的 : 
mContentInsets， 表 示 View 中 除 screen 
decoration 外 的 空间 ; 
mWindowVisibility， 表 示 Window 的 
可 见 性 ; mSystemUiVisibility， 表 示 
通过 setSystemUiVisibility 所 设置 的 系 
统 ui 的 各 标志 位 等 


mAttachInfo 


通过 主动 请 求 WMS 计 算 后 得 到 的 
值 。 要 特别 注意 它们 和 
desiredWindowWidth/desired 


WindowHeight 的 区 别 ， 后 面 这 组 值 与 
mWinFrame 中 保存 的 值 是 一 致 的 ， 表 
示 WMS 期 望 的 应 用 程序 的 宽 / 高 


pwiniowsesion—_Viewtoo wos 8 








接 下 来 我 们 需要 寻找 一 条 线索 来 贯穿 这 个 长 函数 。 由 于 代码 量 较 
大 ， 涉 及 的 变量 也 很 多 ，“ 一 个 儿子 扎 进 代码 ”的 效果 并 不 好 一 一 因而 
建议 采取 “ 反 推 ”的 方式 。 我 们 真正 关心 的 是 : 在 什么 条 件 下 程序 会 分 
别 执行 志 历 的 上 述 3 个 步骤 ， 具 体 又 是 如 何 执行 的 ? 所 以 只 要 先 找到 调 
用 这 3 个 函数 的 地 方 ， 再 往 上 推导 与 之 相对 应 的 变量 及 处 理 过 程 ， 整 个 
流程 就 明朗 多 了 。 后 续 一 旦 梳理 了 也 数 的 逻辑 框 染 ， 再 来 尝试 正面 分 析 


源码 ， 相 信 会 有 另 一 番 收 获 。 


1. performMeasure 


这 个 函数 第 一 次 被 调用 的 地 方 在 ViewRoot Imp1. java 的 第 1668 行 
(另外 一 个 调用 地 方 也 是 类 似 的 ， 读 者 可 以 自行 分 析 ) 。 外 围 条 件 是 : 


private void performTraversals() 4.. 


if (mFirst || windowShouldResize || insetsChanged | | viewVi 


null) {// 层 级 1 


if (!mStopped) {// 层 级 2 


boolean focusChangedDueToTouchMode = ensureTouchMod 
(relayoutResult&windowManagerImpl.RELAYOUT_RES_IN_ 
if (focusChangedDueToTouchMode || mwidth != host.ge 
|| mHeight != host.getMeasuredHeight() || co 
int childWwidthMeasureSpec = getRootMeasureSpec(m 
int childHeightMeasureSpec = getRootMeasureSpec( 

// Ask host how big it wants to be 
performMeasure(childwidthMeasureSpec, childHeigh 


用 于 判断 是 否 执行 performMeasure 的 条 件 变量 都 高 显 出 来 了 。 其 中 
既 有 “与 ”的 情况 ， 也 有 “或 ”的 情况 ， 分 别 组 成 了 3 个 层级 ， 如 表 
11-2 所 示 。 


表 11-2 执行 performMeasure 的 条 件 





evel[Member | 


windowShouldResize 见 Case 1.1 


WMS 要 求 的 content insets 和 当 
insetsChanged 前 值 不 一 致 时 ， 为 true 


ViewRootImpl 记 录 的 Visibility 

和 ViewTree 根 节点 所 记录 的 值 

ie aa 产生 差异 时 ， 说 明 可 见 性 有 变 

view VisibilityChanged 化 ;或 者 需要 为 这 个 窗口 产生 
一 个 新 的 Surface， 那 么 这 个 


~ 


这 棵 View Tree 的 
WindowManager.LayoutParams 
params 属性 值 。 应 用 程序 可 以 通过 多 
种 方法 来 设置 ， 如 
Window.setAttributes 
层级 当 Activity 处 于 stop 状 态 时 ， 其 
> ”|mstopped 对 应 的 window 也 同样 会 被 
stopped 


是 五 U N 
poan a 从 引起 focus 的 












mWidth != getMeasuredWidth()z ViewXt 


层级 |host.getMeasuredWidth() 象 经 过 onMeasure 后 测量 出 来 
3 的 宽度 


getMeasuredHeight() 是 View 对 
象 经 过 onMeasure 后 测量 出 来 
的 高 度 


i 这 的 含 、 
contentInsetsChanged Oe 的 含义 相 


mHeight != 





host.getMeasuredHeight() 





Case 1.1 (windowShouldResize): 
boolean windowShouldResize = layoutRequested && windowSizeMayChan 
&& ((mWidth != host.getMeasuredwidth() || mHeight != host.getMeas 
|| (lp.width == ViewGroup.LayoutParams.WRAP_CONTENT 
frame.width() < desiredWindowwidth && frame. 
|| (lp.height == ViewGroup.LayoutParams.WRAP_CONTEN 
frame.height() < desiredwWindowHeight && frame.height() != mHeight 


如 果 mLayoutRequested 为 true， 并 且 当 前 不 处 于 stopped 状 态 ， 那 
么 layoutRequested 为 true。 变 量 windowS izeMayChange 正 如 其 名 所 示 ， 
表明 窗口 的 尺寸 大 小 有 可 能 发 生变 化 一 一 比如 当前 宽 高 与 期 望 值 不 相 
符 。 假 设 当 前 有 layout 需 求 ， 并 且 window size 确 实 需要 改变 ， 那 么 


windowShouldResize 就 是 true。 


一 旦 上 述 3 个 层级 的 条 件 者 满足， 程序 束 开始 执行 
performMeasure。 实 际 上 这 个 函数 什么 也 没 做 ， 只 是 简单 地 调用 了 View 
Tree 顶层 无 素 的 "ecur3 函 数 ， 





mView.measure(childwidthMeasureSpec, childHeightMeasureSpec) ; 


IX#EV i ewRoot Imp1 就 将 控制 权 转 交 给 View 树 的 根 元 素 ， 真 正 的 
Traversal 才 刚刚 开始 。 顺 便 说 一 下 ，View 类 中 提供 了 measure 和 
onMeasure 两 个 函数 实现 。 建 议 读者 在 扩展 一 个 新 的 View 组 件 时 ， 尽 量 
个 要 直接 重 载 measure 方 法 ， 而 是 通过 改写 后 者 来 达到 相同 的 目的 。 真 
正 的 测量 工作 也 是 在 onMeasure 中 进行 的 ， 如 下 : 


protected void onMeasure(int widthMeasureSpec, int heightMeas 
setMeasuredDimension(getDefaultSize(getSuggestedMinimumWid 
getDefaultSize(getSuggestedMinimumHeight(), heightMe 


人 参数 中 的 widthMeasureSpec 和 heightMeasureSpec 是 该 View 对 象 的 
上 一 级 父 对 象 要 求 的 宽 高 值 一 一 如 此 层 层 而 下 传递 到 View Tree 中 的 各 
个 元 素 。View Tree 的 树 根 元 素 〈 即 mDecor 〉 的 这 两 个 值 是 由 
ViewRootImp1 传 入 的 ， 后 者 通过 MeasureSpec. makeMeasureSpec 来 生成 
符合 当前 要 求 的 spec。 每 一 个 spec (int 类 型 值 ) 的 格式 如 下 : 


mode (最 高 二 位 ) +size 


通过 MeasureSpec. getMode 和 MeasureSpec. getSize 可 以 分 别 获 得 一 
个 spec 值 中 的 mode 和 size。 其 中 mode 有 3 种 。 


UNSPECIFIED=0: 父 对 象 没有 强制 要 求 子 对 象 必须 遵循 哪些 约束 。 


EXACTLY= 1: 父 对 象 要 求 子 对 象 必 须 严 格 按照 它 给 定 的 值 来 约束 自 
Eis 


AT_MOST= 2: 子 对 象 可 以 自行 选择 给 定 范 围 内 的 值 。 


mode 的 选取 则 和 LayoutParams 有 一 定 关 联 。 比 如 MATCH _PARENT 对 应 
的 是 EXACTLY;，WRAP_CONTENT 对 应 的 是 AT_MOST。 


虽然 View. java 提 供 了 默认 的 onMeasure 实 现 ， 但 是 扩展 的 视图 对 象 
通常 有 自己 需要 考虑 的 因素 ， 所 以 它们 会 选择 重 载 这 个 函数 来 切合 自己 
的 需求 。 比 如 mDecor 是 一 个 FrameLayout， 其 onMeasure 源 码 如 下 : 


/*frameworks/base/core/java/android/widget/FrameLayout.java*/ 
@Override // 这 是 一 个 重 载 函 数 
protected void onMeasure(int widthMeasureSpec, int heightMeas 
int count = getchildCount();// 子 对 象 个 数 
/*Step1. 判断 父 对 象 的 node 要 求 */ 
final boolean measureMatchParentChildren = 
MeasureSpec.getMode(widthMeasureSpec) != MeasureS 
MeasureSpec.getMode(heightMeasureSpec) != Measure 
mMatchParentChildren.clear(); 
int maxHeight = 0; // 所 有 子 对 象 中 测量 到 的 最 大 高 度 
int maxWidth = 0; // 所 有 子 对 象 中 测量 到 的 最 大 宽度 
int childState = 0 





. 
了 


for (int i = 0; i < count; i++) {// 循 环 处 理 所 有 子 对 象 
final View child = getChildAt (i);// 获 取 一 个 子 对 象 
if (mMeasureAllChildren || child.getVisibility() != G 
measureChildwWithMargins(child, widthMeasureSpec, 0 








0);//Step2. 
final LayoutParams lp = (LayoutParams) child.getL 
/*Step3. 取得 最 大 值 */ 
maxWidth = Math.max(maxwidth, child.getMeasuredwid 
lp.leftMargin + lp.rightMargin); 
maxHeight = Math.max(maxHeight, child.getMeasuredHe 
lp.topMargin + lp.bottomMargi 
childState = combineMeasuredStates(childState, chi 


} 


/*Step4. 综合 考虑 其 他 因素 */ 

// 检查 padding 

maxWidth += getPaddingLeftWithForeground() + getPaddingRi 
maxHeight += getPaddingTopWithForeground() + getPaddingBo 








// 检查 建议 的 最 小 宽 高 值 
maxHeight = Math.max(maxHeight, getSuggestedMinimumHeight 
maxWidth = Math.max(maxWidth, getSuggestedMinimumwidtnh( ) ) 


// 检查 foreground 背 景 宽 高 值 

final Drawable drawable = getForeground(); 

if (drawable != null) { 
maxHeight = Math.max(maxHeight, drawable.getMinimumHe 
maxWidth = Math.max(maxwidth, drawable.getMinimumwWidt 





} 
/* 记 录 结 果 */ 
setMeasuredDimension(resolveSizeAndState(maxwidth, widthM 
childState), resolveSizeAndState(maxHeight, h 
childState << MEASURED_HEIGHT_STATE_SHIFT 


} 


先 给 大 家 介绍 下 padding 和 margin 的 基础 知识 一 一 对 于 View 类 而 
言 ， 它 只 有 padding， 没 有 margin。 这 是 因为 padding 指 的 是 “内 容 ” 区 
域 与 外 围 边 框 的 距离 ， 分 为 left、right、top、bottom 四 个 方向 。 而 
margin 则 是 “内 容 ” 内 部 的 进一步 细 化 一 一 即 “ 内 容 ” 中 各 元 素 之 间 的 
间距 。 可 想 而 知 ， 一 个 View〈 非 ViewGroup) 实例 的 “内 容 ” 本 身 就 是 
不 可 分 割 的 ， 不 存在 内 部 对 象 间距 的 说 法 。 而 ViewGroup 由 多 个 子 对 象 
组 成 ， 它 们 之 间 有 时 需要 margin 属 性 来 将 彼此 区 分 开 来 。 更 多 详细 描述 
可 以 参见 后 续 小 节 对 于 View 和 ViewGroup 的 属性 分 析 。 


Step1@onMeasure. jfitMeasureSpec. getMode 可 以 取得 父 对 象 对 当 
前 视图 的 要 求 ， 只 要 宽 或 者 高 有 一 个 不 是 EXACTLY， 那 么 FrameLayout 在 


后 续 都 需要 执行 match parent 的 操作 。 


Step2@onMeasure。 变 量 count 代 表 该 FrameLayout 中 包含 的 子 对 象 
数量 ， 它 们 都 记录 在 成 员 变 量 ViewGroup. mchi ldren 中 。 基 于 View 
Tree 的 特性 ， 我 们 需要 逐个 处 理 这 些 子 对 象 。 这 里 使 用 的 是 
measureChildWithMargins， 意 即 需要 考虑 padding 和 和 margins。 这 个 辑 
数 将 根据 padding 和 和 margin 来 生成 新 的 spec， 然 后 调用 chi 1d.， measure 
消 数 。 于 是 遍历 流程 就 到 了 子 对 象 中 。 后 者 如 归 也 是 ViewGroup， 通常 
还 会 重 载 onMeasure， 进 一 步 把 测量 指令 往 下 “递归 ”， 直 到 叶 节 点 。 
当然 ， 并 不 是 所 有 子 对 象 都 需要 被 测量 。 假如 View 本 身 的 可 见 性 是 
GONE， 而 且 变 量 mMeasure Al1Children 为 false (可 以 在 
android:measureAl1Children 中 配置 ) ， 那 么 程序 会 跳 过 这 个 对 象 。 


Step3@onMeasure。 通 过 测量 ， 我 们 可 以 得 到 chi1d 的 计算 结果， 即 
child. getMeasuredWidth () 和 chi1d. getMeasuredHeight () 。 这 两 个 国 
数 分 别 对 应 的 是 View.，mMeasuredWidth 和 和 View. mMeasured Height 成 员 
变量 ， 它 们 通常 是 在 onMeasure 结 束 时 通过 setMeasuredDimension 来 设 
置 的 。 对 于 我 们 自己 扩展 的 View 组 件 ， 一 定 要 注意 这 一 点 。 


FrameLayout 需 要 知道 各 子 对 象 中 的 最 大 宽 高 值 ， 计 算 公式 如 下 : 


maxWidth = Math.max(maxwidth,child.getMeasuredwidth() + lp.leftMa 
maxHeight = Math.max(maxHeight, child.getMeasuredHeight() + lp.to 


maxWidth/maxHeight 记 录 的 是 当前 测量 出 的 最 大 值 。 如 果 后 续 子 对 
象 的 测量 结果 超过 前 一 次 的 最 大 值 ， 那 么 就 做 一 下 替换 。 


Step4@onMeasure。 上 述 步 又 得 高 和 最 宽 值 ， 但 
并 不 是 最 终结 果 。 还 有 3 个 因素 可 能 产生 影响 : 


e padding 


ViewGroup 本 身 的 padding 也 是 需要 考虑 的 。 


=> 
[=s 


e。 最 小 宽 高 值 


getSuggestedMinimumHeight 用 于 计算 适应 当前 View 的 最 小 高 度 
值 ， 核 心 语句 如 下 : 


return (mBackground == null) ? mMinHeight : max(mMinHeight, mBack 


AAS jg] 


mBackground 是 背景 图 片 ; mMinHeight 则 是 通过 android: 
minHeight 设 置 的 值 ， 表 示 开 发 者 希望 这 个 View 对 象 获取 到 的 最 小 高 度 
值 。 


getSuggestedMinimumWidth 的 实现 也 类 似 。 
e fotegtound 的 宽 高 值 
对 应 的 是 mForeground 所 指示 的 背景 ， 不 一 定 存 在 。 


Step5@onMeasure。 如 前 所 述 ，onMeasure 的 计算 结果 需要 被 记录 下 
来 ， 以 便 后 续 操 作 时 查询 使 用 。 值 得 一 提 的 是 ，mMeasuredWidth 和 
mMeasuredHeight 保 存 的 不 仅仅 是 size， 还 有 state。 所 以 还 要 先 调用 
resolveSizeAndState 来 对 这 两 个 值 进行 格式 整合 ， 最 后 才 能 通过 
setMeasuredDimension 来 记录 。 具 体格 式 读者 可 以 通过 阅读 源码 获悉 ， 
这 里 不 子 详 述 。 


2. performLayout 


经 过 上 面 的 performMeasure，View Tree 中 各 元 素 的 大 小 已 经 基本 
确定 下 来 ， 并 保存 在 自己 的 内 部 成 员 变 量 中 。 接 下 来 ，ViewRoot Imp1 会 
进入 另 一 个 “遍历 ”过 程 ， 即 位 置 测量 。 Layout 这 个 词 在 设计 令 minh Ay RE 
义 类 似 于 “构图 ”、 “布局 ”， 因 而 它 既 需要 “大 小 ”， 也 需要 “位 
置 ” 信 息 。 函数 performMeasure 和 人 叶 到 的 便 是 对 象 的 尺寸 大 小 ， 
poerfornlLvout 更 确切 地 说 是 在 此 基础 上 进一步 完善 “位 置 ” ia 然 
后 组 合成 真正 的 “layout”。Android 官 方 文档 有 这 样 的 描述 


“Layout is a two pass process: a measure pass and a 
layout pass. The measuring pass is implemented in measure (int, 
int) and is a top-down traversal of the view tree… The second 
pass happens in layout(int, int, int, int) and is also top- 
down. During this pass each parent is responsible for 
positioning all of its children using the sizes computed in 
the measure pass. ” 


也 就 是 说 ，Layout=measure passtlayout 


pass=measure () +l ayout () onMeasuretonLayout 


这 多 少 有 点 文字 游戏 的 味道 ， 我 们 在 实际 工作 中 发 现 很 多 开发 者 并 
没有 搞 清楚 ， 从 而 引发 了 理解 上 的 混乱 。 


国 数 performLayout 在 performTraversals 中 的 调用 位 置 只 有 一 处 ， 
1730 行 。 我 们 仍然 沿用 前 面 的 方法 ， 看 看 与 之 相关 的 执行 条 
牛 : 


private void performTraversals() 4.. 
final boolean didLayout = layoutRequested && !mStopped; 


if (didLayout) { 
performLayout(); 


变量 didLayout 取 决 于 两 个 因素 ， 即 1ayoutRequested 和 mStopped 
一 一 其 中 后 者 已 经 分 析 过 ， 此 处 不 再 歼 述 。 而 1ayoutRequested 主 要 由 
下 面 的 语句 赋值 : 


boolean layoutRequested = mLayoutRequested && !mStopped 


成 员 变量 mLayoutRedquested 为 true 的 情况 比较 多 ， 我 们 在 前 面 专门 
介绍 过 ， 读 者 可 以 回头 看 看 。 


简 而 言 之 ， 一 旦 ViewRoot1Imp1 发 现 需要 执行 layout， 那 么 它 会 调用 
performLayout 进 行 位 置 测 量 。 有 具体 实现 与 performMeasure 基 本 一 致 ， 
只 是 间接 调用 了 View Tree 的 顶层 根 元 素 (mView) 的 layout: 


private void performLayout() 4.. 
final View host = mView; 


try { 
host.layout(0, 0, host.getMeasuredwidth(), host.getMe 
Yon 
} 


我 们 仍然 以 FrameLayout 为 例 来 看 看 View 对 象 是 如 何 计 算 1ayout 
的 : 


/*frameworks/base/core/java/android/view/View. java*/ 
public void layout(int 1, int t, int r, int b) 4.. 


boolean changed = isLayoutModeOptical(mParent) ? 
setOpticalFrame(l, t, r, b) : setFrame(l, t, r, b); 
if (changed||(mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PF 
onLayout(changed, 1, t, r, b);//dt4tlayout 


} 
mPrivateFlags &= ~PFLAG FORCE_LAYOUT; 
} 


上 面 这 个 函数 的 1|、t、r、b 分 别 代表 此 View 对 象 与 父 对 象 的 左 、 
上 、 右 、 下 边框 的 距离 。 和 measure 的 很 大 差异 ， 是 1ayout 直 接 将 这 些 
值 记 录 (setFrame) 到 成 员 变 量 中 ， 即 mLeft，mTop，mRight 和 
mBottom。 接 下 来 ， 如 果 changed 为 true， 则 意味 着 本 次 设置 的 边 距 与 上 

次 相 比 发 生 了 变化 ; 或 者 flags 中 强制 要 求 layout， 那 么 就 会 调用 
GL ou 既然 该 View 对 象 本 身 的 layout 已 经 确定 下 来 ， 可 以 猜想 到 这 
个 函数 应 该 是 对 其 子 对 象 进行 布局 调整 的 过 程 。 也 正 因 如 此 ，View 类 中 
BYonLayout ck SLE AS ee eee 如 
FrameLayout 需 要 重 载 并 具体 实现 它们 所 需 的 功能 


/*frameworks/base/core/java/android/widget/FrameLayout.java*/ 
@override// 这 是 个 重 载 函数 
protected void onLayout(boolean changed, int left, int top, i 
final int count = getchildCount();// 子 对 象 的 个 数 


final int parentLeft = getPaddingLeftwithForeground();//x 
final int parentRight = right - left - getPaddingRightWit 
final int parentTop = getPaddingTopWithForeground(); 

final int parentBottom = bottom - top - getPaddingBottomw 














for (int i = 0; i < count; i++) {// 循 环 处理 所 有 子 对 象 
final View child = getChildAt(i);// 当 前 子 对 象 
if (child.getVisibility() != GONE) {// 如 果 为 G60ONE 的 话 ， 示 
final LayoutParams lp = (LayoutParams) child.getL 
设置 的 lJayout 属 性 
final int width = child.getMeasuredwidth();//chil 
final int height = child.getMeasuredHeight();//ch 








—= 





int childLeft;// 最 终 计 算出 的 child 的 左边 距 
int childTop;// 最 终 计算 出 的 child 上 边 距 


int gravity = lp,gravity;// 这 个 属性 值 是 后 面 计算 的 依据 








final int layoutDirection 
final int absoluteGravity 
Direction); 


getResolvedLayoutDire 
Gravity.getAbsoluteGr 


final int verticalGravity = gravity & Gravity.VER 


switch (absoluteGravity & Gravity.HORIZONTAL_GRAV 

case Gravity.LEFT: 
childLeft = parentLeft + lp.leftMargin; 
break; 

case Gravity.CENTER_HORIZONTAL: :// 后 面 以 此 为 例 做 ; 
childLeft = parentLeft + (parentRight - p 
lp.leftMargin - 1lp.rightMargin; 
break; 

case Gravity.RIGHT: 
childLeft = parentRight - width - lp.righ 
break; 

default://default 情 况 下 的 处 理 ， 应 用 开发 人 员 要 特别 贸 
childLeft = parentLeft + 1lp.leftMargin; 





} 
…// 省 略 childTop 的 计算 过 程 ， 和 childLeft 是 类 似 的 
child.layout(childLeft, childTop, childLeft + wid 


} 


进入 代码 分 析 前 ， 先 来 思考 下 FrameLayout 的 onLayout 需 要 解决 的 
问题 。 ee lap hs 
GridLayout 的 一 个 显著 区 别 是 ， 它 的 各 子 对 象 并 不 存在 “竞争 空间 ”的 
问题 。 换 句 话说， FrameLayout 中 的 元 素 是 “Ee” MAA, EMA 
置 主要 取决 于 自身 与 父 对 象 间 的 调整 。 明 白 这 个 道理 后 ， 我 们 再 来 看 看 
上 面 的 onLayout 源 码 实现 。 


和 onMeasure 类 似 ， 它 首先 计算 所 包含 子 对 象 的 个 数 ， 然 后 通过 for 
循环 逐个 处 理 。 每 次 循环 的 最 后 一 行 都 调用 了 chi 1d. layout, aa 
Hd} SHRP toh i | layout 我 们 的 关注 重点 就 转化 为 : 这 
个 参数 是 如 何 得 到 的 呢 ? 


首先 要 知道 ， 一 个 长 方 体 的 layout 只 需要 left，top 和 width， 
height 就 可 以 确定 下 来 在 measure 中 已 经 有 了 确切 的 结 
果 ， 所 以 最 终 的 问题 就 转化 为 对 1eft 和 top 的 计算 。 


进行 过 应 用 开发 的 读者 应 该 知道 ， 我 们 可 以 在 View 对 象 中 设置 
Gravity 属 性 来 控制 其 在 父 对 象 中 的 位 置 ， 如 表 11-3 所 示 。 


表 11-3 Gravity 常用 属性 释义 


六 | 








| Gravity Attributes | Description | 


不 改变 矿 寸 大 小 的 情况 下 ， 放 置 在 父 
对 象 的 头 部 


不 改变 尺寸 大 小 的 情况 下 ， 放 置 在 父 
对 象 的 尾部 


不 改变 尺寸 大 小 的 情况 下 ， 放 置 在 父 
对 象 的 左 部 


不 改变 尺寸 大 小 的 情况 下 ， 放 置 在 父 
对 象 的 右 部 


不 改变 尺寸 大 小 的 情况 下 ， 放 置 在 父 


CENTER_VERTICAL 对 象 的 垂直 方向 中 部 


不 改变 尺寸 大 小 的 情况 下 ， 放 置 在 父 


CENTER_HORIZONTAL 对 象 的 水 平方 向 中 部 


不 改变 尺寸 大 小 的 情况 下 ， 放 置 在 父 
对 象 的 正中 部 位 





下 面 以 mLeft 在 Gravity. CENTER_HORIZONTAL 情 况 下 的 处 理 过 程 为 例 
来 做 详细 讲解 。 为 了 让 读者 看 得 更 清楚 些 ， 同 时 假设 lp. leftMargin 和 
lp. rightMargin 为 0: 


childLeft = parentLeft + (parentRight - parentLeft - width) / 2 + 
=parentLeft + (parentRight - parentLeft - width) / 2; 


各 变量 含义 如 图 11-13 所 示 。 


根据 上 图 ，parentRight-parentLeft 得 到 的 是 方 框 2， 即 
FrameLayout 内 容 区 域 的 宽度 。 因 为 子 对 象 是 要 放置 在 这 里 的 ， 
其 “center” 的 中 心 也 是 以 图 中 的 中 轴线 为 标准 。 所 以 (parentRight- 
parentLeft - width) / 2 得 到 的 是 方 框 3 左边 线 与 方 框 2 对 应 边线 的 距 
离 ， 最 终 chi 1dLeft 还 要 在 此 基础 上 加 parentLeft。 


计算 出 chi 1dLeft， 程 序 下 一 步 将 按照 类 似 的 方法 得 出 chi 1dTop。 
我 们 说 过 ， 对 于 一 个 长 方形 来 说 ，left+toptwidththeight 已 经 足够 确 
认 它 的 layout 了 。 因 而 调用 
child.layout(childLeft, childTop, childLeft + width, childTop + h 


来 设置 子 对 象 的 layout 区 域 。 
如 此 循环 往复 ， 直 到 View Tree 中 所 有 元 素 都 处 理 完成 。 


width 


Ate | 
HEN 3 的 中 轴线 
EE” | 
| y 
parentLeft | i 
| 
ig | 
hilde | 


parentRight 





HEL: FrameLayout 对 象 的 外 围 边 柜 
HED: FeameLayout 中 的 内 容 区 边框 
JjHE3; FrameLayout FARES AU HE 
全 图 11-13 childLeft 计 算 过 程 中 涉及 的 变量 释义 图 
3. performDraw 


一 个 对 象 的 1ayout 确 定 后 ， 它 才能 在 此 基础 上 执行 “Draw”。 团 数 
performDraw 是 遍历 流程 中 最 后 被 调用 的 ， 将 在 “画板 ”上 产生 UI1 数 
据 ， 然 后 在 适当 的 时 机 由 SurfaceF1inger 进 行 整合 ， 最 终 显示 到 屏幕 


上 。 绘 制 U1 的 实现 核心 如 下 : 
e Surface 


可 以 把 Surface 比 作 “ 男 板 ”。“ 巧 妇 难 为 无 米 之 炊 ”， 假 如 没 
合法 的 Surface， U1 数据 就 无 法 正常 存储 与 显示 ， 


。 图 形 绘制 的 方式 
有 两 种 ， 即 硬件 和 软件 。 
。 View Tree 各 元 素 的 协调 关系 
我 们 将 按照 怎样 的 顺序 来 绘制 UI 呢 ? 


performDraw 在 进行 必要 的 判断 (performDraw 的 判断 条 件 比较 简 
单 ， 读 者 可 以 自行 分 析 ) 后 ， 将 接着 调用 draw; 后 者 则 根据 
hardware/software render 的 配置 ， 选 择 调 用 attachlnfo. mHardware 
Renderer. draw 或 者 drawSoftware 来 执行 具体 的 绘制 操作 。 


Wi) TAME BRERA BRAN, Ahm: 


/*frameworks/base/core/java/android/view/ViewRootIimpl. java*/ 
private boolean drawSoftware(Surface surface, AttachInfo atta 
boolean scalingRequired, Rect dirty) {.//dirty 表 示 需 要 1i 
Canvas canvas;// 后 续 小 节 有 详细 介绍 


try {... 
canvas = mSurface.lockCanvas(dirty);// 先 取得 一 个 Canvasx 








} catch (Surface.OutOfResourcesException e) { 


} catch (IllegalArgumentException e) { 


} 


try {... 
try { 
canvas.translate(0, -yoff);//AAm eR 
if (mTranslator != null) { 
mTranslator.translateCanvas(canvas); 
} 


mView.draw(canvas) ;// 由 顶层 元 素 开 始 遍 历 绘制 
} finally 4.. 


} 
} finally { 


try { 
surface .unlockCanvasAndPost (canvas) ;// 绘 制 完 毕 ， 释 订 
} catch (IllegalArgumentException e) 4.. 


return true;//true 表 示 成 功 
} 


这 个 函数 的 实现 步骤 如 下 。 


(1) lockCanvas。Canvas 的 底层 实现 仍然 是 Surface， 它 是 面向 应 
用 层 开发 的 “画板 工具 ”， 我 们 在 后 面 小 节 有 专门 介绍 。 在 使 用 Canvas 
前 ， 必 须 显 式 地 锁定 它 ， 然 后 才 可 以 正常 使 用 。 假 如 lock 过 程 中 出 现任 
何 异 常 ， 那 么 drawSoftware 都 将 失败 ， 并 返回 fal se。 


(2) 坐标 变换 。 包 括 由 入 参 传 入 的 yoff 组 成 的 坐标 平移 ， 以 及 
mTranslator 指 示 的 变换 〈 如 果 存 在 的 话 ) o 


(3) View. draw。 这 是 真正 绘制 U1 的 地 方 ， 后 续 我 们 会 重点 分 析 。 


(4) unlockCanvasAndPost。 到 目前 为 止 我 们 改变 的 还 只 是 本 地 数 
据 ， 只 有 把 draw 完 成 后 的 Canvas 信 息 透 过 Surface 提 交 给 
SurfaceFlinger， 并 由 后 者 统一 合成 泻 染 到 Framebuffer 中 ， 才 能 最 终 
把 界面 显示 到 屏幕 上 。 


这 样 就 分 析 完 成 了 performTraversals 中 的 三 大 支柱 ， 即 
performMeasure、performLayout 及 performDraw。 它 们 按照 顺序 执行 
View Tree 中 各 元 素 的 大 小 人 遍历、 位置 遍历 以 及 绘图 遍历 ， 从 而 把 每 个 
View 对 象 所 代表 的 U1 信息 正确 地 绘制 到 了 终端 屏幕 上 一 一 它们 的 实现 流 
程 “大 同 小 异 ”， 即 通过 递归 的 方式 ， 由 上 而 下 遍历 和 处 理 View Tree 
中 的 对 象 〈《 只 是 具体 的 处 理 手段 和 目的 不 同 ) 。 


对 于 performDraw 的 内 部 实现 ， 因 为 还 涉及 Canvas， 
View/ViewGroup 属 性 、 坐 标 变换 等 一 系列 技术 细节 ， 所 以 特别 把 它们 独 
立 出 来 ， 在 接 下 来 的 小 节 中 逐一 击破 。 


11.7 View 和 ViewGroup 属 性 


相信 不 少 应 用 开发 者 都 有 类 似 的 经 历 : 在 用 XML 文 件 进行 UI 布局 
时， 无 论 怎 么 调整 都 达 不 到 预期 的 客 面 效果 ; 看 着 一 堆 padding 属 性 
值 ， 辨 别 不 出 它们 的 差异 ， 无 从 下 手 ; 原本 运行 很 好 的 一 个 UI 程序， 只 
是 改动 了 布局 文件 中 一 个 很 小 的 地 方 ， 整 个 表面 就 出 现 了 严重 变形 。 出 
现 这 些 情 况 主 要 有 两 方面 的 原因 : 其 一 是 我 们 对 View 的 属性 还 不 够 熟 
悉 ， 无 法 掌握 它们 所 表达 的 确切 意思 ， 只 能 通过 反复 调整 试验 来 达到 有 目 
标 。 其 二 就 是 对 View 的 内 部 实现 不 够 了 解 。“ 工 欲 善 其 事 ， 必 先 利 其 
器 ”， 只 有 对 View 的 “外 在 ”和 “内 在 ”都 有 了 更 全 面 的 认识 ， 青 来 做 
应 用 开发 才能 得 心 应 手 。 


为 此 ， 我 们 将 专门 在 本 小 节 讲 解 View 和 ViewGroup 中 的 一 些 关键 属 
性 ， 和 希望 能 让 读者 对 它们 有 个 感性 而 深入 的 认识 。 

值得 一 提 的 是 ，View 的 两 个 重要 特性 就 是 它 既 负责 U1 显 示 ， 也 可 以 
进行 各 种 事件 的 处 理 一 一 这 同时 也 是 它 和 Drawable 的 一 个 本 质 区 别 。 
11.7.1 View 的 基本 属性 


相信 有 不 少 读者 在 阅读 源码 时 ， 都 会 被 View 类 中 数量 众多 的 成 员 变 
量 所 困扰 一 一 特别 是 对 于 那些 名 称 相近 的 变量 更 是 如 此 。 另 外 ，View 对 
象 中 部 分 成 员 变 量 的 值 是 可 以 通过 在 1ayout (xml) 文 件 中 指定 View 属 性 
来 改变 的 。 所 以 属性 名 与 变量 之 间 的 对 应 关系 也 是 一 个 重点 ， 我 们 在 本 
小 节 一 并 详细 列 出 ， 以 方便 读者 阅读 学 习 。 


View 中 与 U1 显示 相关 的 属性 如 表 11-4 所 示 。 





表 11-4 View 中 的 U1 属性 











UI 属性 ”相关 方法 与 布局 属性 


Identifier 





属 llandroid:id 
性 


a findViewWithTag(Object tag) 





Tag 


android: tag 






la getTop(),getRight(), 
关 |lgetBottom() 

Fi \\setLeft(int left), setTop (int top), setRight(int right), 
法 |setBottom(int bottom) 


Size 
布 landroid:minWidth 
局 llandroid:minHeight 
J&\android:layout_width 
性 landroid:layout_height 













< ro ro 
中 fat] 
= an an 
ga a. a 
þ— 0 
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setPadding(...),setPaddingRelative(...), 


_getPaddingLeft(), getPaddingTop() 


getPaddingStart(), getPaddingEnd()= 


android: padding 
android:paddingLeft 
android:paddingRight 
android:paddingTop 
android:paddingBottom 
android:paddingStart 
android:paddingEnd 


Gravity 


android: gravity 
局 可 以 设置 的 值 包括 : top, bottom, left, right, 
属 center_vertical, center_horizontal，center 等 ， 可 以 参考 官 
| 档 说 明 : 


http://developer.android.com/reference/android/R.attr.html#g 


set Visibility(int), getVisibility() 









因 android:visibility 


android:scrollbars 
android:scrollX 
属 android:scrollY 
性 android:scrollbarSize 
android:scrollbarStyle<§ 









android:fadeScrollbars 
android: fadingEdgeLength 
android:alpha 


| Pa 


setRotationX (float) 
setRotation Y (float) 


setTranslationX (float) 
Transform setTranslation Y (float) 


android:rotation 
android:rotationX 
android:rotationY 
android:scaleX 
android:scaleY 

性 android:transformPivotX 
android:transformPivotY 
android:translationX 
android:translation 





下 面 从 源码 角度 详细 分 析 表 中 的 一 些 重 要 属性 。 
1. Position 


View. java 中 与 此 相关 的 内 部 变量 是 


protected int mLeft; 
protected int mRight; 
protected int mTop; 
protected int mBottom; 


这 些 变量 表示 的 是 该 View 在 4 个 方向 上 的 位 置 与 其 父 View 的 差 值 
(以 像素 为 单位 ) 。 比 如 mLeft 指 的 是 它 的 左边 缘 与 父 View 左 边缘 的 距 
离 ， 如 图 11-14 所 示 。 


实际 上 ， 这 4 个 值 不 仅 固 定 了 View 的 位 置 ， 同 时 也 决定 了 View 的 大 
小 。 比 如 getWidth 的 内 部 实现 如 下 : 


public final int getwidth() { 
return mRight - mLeft; 
} 


在 整 棵 View Tree 的 遍历 过 程 中 ， 系 统 会 综合 考虑 所 有 View 对 象 的 
需求 ， 然 后 为 这 些 成 员 变 量 赋值 ， 所 以 并 不 建议 外 部 程序 直接 通过 接口 
来 设置 它们 ; 而 且 即 便 我 们 通过 外 部 手段 改变 了 这 些 变量 ， 它 们 在 下 一 
次 layout 时 很 可 能 还 会 被 系统 还 原 回来 。 


2. Size 


View. java 中 与 此 相关 的 内 部 变量 包括 : 


private int mMinWidth; 
private int mMinHeight; 
int mMeasuredWidth; 
int mMeasuredHeight; 


前 两 个 变量 表示 这 个 View 对 象 所 希望 的 最 小 宽 、 高 值 ， 可 以 通过 
android:minWidth 和 android:minHeight 来 配置 。 我 们 在 前 面 讲解 View 
Tree 遍历 的 小 节 看 到 过 ， 系 统 将 尽量 保证 使 用 者 的 这 个 需求 。 


后 两 者 是 measure (int, int) 后 的 计算 结果 ， 并 不 代表 View 的 真正 宽 


高 。 
3. Padding 


Padding 是 View 内 部 四 周 的 填空 空间 ， 或 者 更 确切 地 说 ， 是 它 
的 “内 容 区 域 ” 与 外 边框 的 距离 ， 如 图 11-15 所 示 。 


A View 


mBottom 





全 图 11-14 View 在 4 个 方向 上 的 位 置 与 其 父 View 的 差 值 


i mPadding Top 


mPaddingLett mPaddingRight 


Content 


mPaddingBottom 





全 图 11-15 “内 容 区 域 ”与 外 边框 的 距离 
View. java 中 与 此 相关 的 内 部 变量 包括 : 


protected int mPaddingLeft; 
protected int mPaddingRight; 
protected int mPaddingTop; 
protected int mPaddingBottom; 
protected int mUserPaddingLeft; 
protected int mUserPaddingRight ; 4% 


Padding 值 需要 考虑 以 下 几 个 因素 。 
e 用 户 设置 的 padding 


应 用 开发 者 可 以 通过 android:padding、android:paddingLeft、 
android:paddingRight, android: paddingTop, 
android:paddingBottom 等 属性 值 来 指定 填充 边 距 的 大 小 。 当 View 对 象 
构造 时 ， 系 统 会 优先 考虑 这 一 设置 。 


。 其 他 


如 果 用 户 没 有 显 式 指定 padding 值 ， 系 统 将 使 用 默认 的 padding 值 
(或 者 从 background drawable 中 获取 的 padding) o 


4. Gravity 


我 们 已 经 比较 了 gravity 和 1ayout_gravity 的 区 别 ， 前 者 表达 了 
View 内 部 Content 的 重心 位 置 ， 而 后 者 则 是 View 在 ViewGroup 中 的 重心 位 
置 。 


实际 上 gravity 并 不 是 View 基 类 的 属性 。 换 句 话 说，View 类 中 没有 
处 理 这 个 属性 。 这 也 是 合情合理 的 ， 因 为 View 本 身 并 没有 实现 onDraw 方 
法 ， 所 以 继承 View 的 各 子 类 必须 根据 自己 的 需求 来 “ 画 ” 出 想 要 的 “内 
容 ” 以 及 “内 容 ” 的 位 置 。 比 如 在 TextView 组 件 中 : 


TextView(...) { 
case com.android.internal.R.styleable.TextView_gravity: 
setGravity(a.getInt(attr, -1)); // 记 录用 户 在 xml 中 所 1 
break; 


这 段 代 码 中 的 setGravity 会 把 这 一 属性 值 存储 到 TextView 类 的 成 员 


变量 mGravity 中 : 


private int mGravity = Gravity.TOP | Gravity.START; 


这 里 有 必要 了 解 下 Gravity 这 个 类 ， 它 是 专门 用 于 表 
示 “gravity” 属 性 相关 值 的 一 个 类 ， 例 如 : 


int TOP = (AXIS_ PULL_ BEFORE |AXIS_SPECIFIED)<<AXIS_Y_SHIFT; 
int LEFT = (AXIS_PULL_BEFORE|AXIS_SPECIFIED)<<AXIS_X_SHIFT; 


其 中 AXIS X_SHIFT 和 AX1S_Y_SHIFT 分 别 是 0 和 4， 即 前 4 位 用 于 表示 x 
轴 的 重心 位 置 ， 后 面 几 位 则 是 y 轴 重心 位 置 。4 个 bit 位 分 别 表 示 如 表 11- 
5 所 示 。 


表 11-5 4 个 bit 位 的 含义 


Bit | bit3 | bit2 | bit1 | bit0 | 


BEIR | 被 “ 拉 ” 到 被 “ 拉 ” 到 
Description ， aa right/bottom  |left/topi# 


HEAT BY 边缘 的 位 置 | 缘 的 位 置 





比如 Gravity. TOP 指 的 是 y 轴 上 对 top 边 缘 的 操作 ， 即 : 


(AXIS_PULL_BEFORE |AXIS_SPECIFIED)<<AXIS_Y_SHIFT 


而 Gravity.LEFT 则 是 x 轴 上 对 1eft 边 缘 的 操作 ， 具 体 如 下 所 示 。 


(AXIS_PULL_BEFORE |AXIS_SPECIFIED)<<AXIS_X_SHIFT 


之 所 以 叫 pul1， 是 因为 边缘 线 是 被 “ 拉 ” 到 某 个 位 置 上 的 。 换 句 话 
ae 如 果 同 时 “ 拉 ” 两 个 方向 上 的 边缘 线 ， “ 则 0bject 的 大 小 也 会 变 
比如 : 


Gravity. FILL VERTICAL = TOP|BOTTOM; 
5. Visibility 


可 见 性 也 是 在 开发 中 常见 的 一 种 属性 。 它 有 3 种 值 可 选 ， 具 体 如 下 
所 示 。 


e VISIBLE: 当前 的 View 处 于 可 见 状态 ， 因 而 它 会 被 “ 画 ” 出 来 。 
e INVISIBLE: 当前 的 View 处 于 不 可 见 状态 。 
e GONE: 在 INVISIBLE 的 情况 下 ， 虽 然 View 的 内 容 是 不 可 见 的 ， 但 
是 它 所 占据 的 空间 位 置 却 是 不 变 的 。 而 GONE 则 相当 于 完全 移 除 
View 这 个 对 象 ， 系 统 不 再 为 它 保 留 空间 位 置 。 


6. Scrollbar 


滚动 条 本 身 只 是 表达 当前 显示 内 容 在 整体 内 容 中 位 置 的 一 个 组 件 ， 


ANTextV i ew#E ME NALS SCF RR 要 有 类 似 指 示 。 它 让 用 户 产 生 一 种 错 
觉 ， 好 像 我 们 的 View 尺 寸 足以 容纳 整 篇 文章 ， 只 不 过 屏幕 不 够 大 而 已 
(但 实际 上 View 的 尺寸 并 没有 想象 中 那么 大 ) 。 


Scrol1lbar 在 View 内 部 以 Scrol1abi1ityCache 类 型 的 mScrol1Cache 
变量 统一 管理 ， 如 表 11-6 所 示 。 


表 11-6 Scrol1abilityCache 类 型 的 mScrol1Cache 变 量 


Related Member 


ScrollabilityCache.OFF, ScrollabilityCache.ON 


ScrollabilityCache.scrollBarSize Scrollbar 大 小 


View.mVerticalScrollbarPosition 


ii View.viewFlag Values |= scrollbarStyle & Scrollbar 的 样 
SCROLLBARS STYLE _MASK 来 记录 A 


Ab Æ, 
ScrollabilityCache .scrollBar POOLDE TA 





要 特别 注意 Scrol1bar 与 mScrol1X/mScrol1Y 的 区 别 和 联系 。 简 单 来 
讲 ，Scrollbar 是 内 容 〈 比 如 文本 ) 的 滚动 条 ， 而 后 两 者 则 是 View 视 图 
的 滚动 位 置 。Scrol1lbar 是 用 于 提示 用 户 当 前 内 容 位 置 的 ， 它 对 View 本 
身 的 显示 内 容 并 不 产生 影响 ， 而 mScrol1X/mScrol1Y 则 真正 体现 了 View 
的 这 些 属性 。 或 者 可 以 这 样 理解 : Scrol1bar 是 给 用 户 看 的 ， 想 象 一 下 
在 没有 屏幕 的 情况 下 ， 它 将 一 无 是 处 ; 而 另外 两 者 是 基于 “内 存 ” 的 操 


作 。 


The week in music: 
Pink, Ozzy & more 

» Rivera crash details sought 

a Pelosi gets "30 Rock' cameo 

= Steve Jobs biopic due in April 
« Anthrax quitarist quits band 

= Oscars to feature Bond tribute 
« Beatles’ tour rider revealed 





poate 01/04/2013 11:41 ET 


JOW 13,435.21 +43.85 
IASDAQ 3,101.66 +1.09 
&P 1,466.47 +7.10 
RFAI FSTATF 


实例 如 图 11-6 和 图 11-7 所 示 。 


Re ene aoe 
. Pelosi on "30 Rock’ » Dempsey to buy coffee chain 

+ Taliban chief killed .US unemployment steady 

+ Photo of princess to auction » Kimmel slams Leno 


Scrollbar 


Miley Cyrus adopts a furry friend 


The young star brings home a pet Chihuahua & more 
celebrity news from the world of social media. 


© Dutch engineers plan glow-in-the-dark roads 










MSN VIDEO 


@ Demanding dog won't let owner stop petting him 

© High school hoops star leaps over opponent for dunk 
© Super Bowl of suds: Vegas hosts beer pong tourney 
© Videographer reverses footage of fireworks display 


WHAT DO YOU THINK? 





全 图 11-16 ” Scrollbar 实例 


Touch to select music. 





全 图 11-17 mScrollX % 4] 


图 例 显 示 了 Scrol1lbar 和 mScrol1X 的 区 别 。 图 11-16 中 ，Scrollbar 
表示 用 户 当 前 阅读 到 的 内 容 在 整 版 中 的 位 置 ， 图 11-17 则 是 我 们 常见 的 
桌面 Launcher， 它 由 一 个 ViewGroup 添 加 了 若干 个 子 View 组 成 ， 每 个 桌 
面 页 都 是 一 个 View 对 象 。 当 拖 动 屏幕 时 ， 改 变 的 就 是 mScrol1X 的 值 一 一 
也 就 是 屏幕 上 显示 的 这 一 部 分 宕 面 ， 距 离 整个 ViewGroup 左 边 宕 的 位 
移 。 当 然 ， 因 为 ViewGroup 同 时 也 是 个 View， 如 果 把 Launcher 加 上 一 个 
ale een 这 时 的 “内 容 ” 就 指 的 是 其 中 容纳 的 若干 
View 了。 


11.7.2 ViewGroup 的 属性 


ViewGroup 继 承 自 View， 因 而 它 具 有 View 的 所 有 属性 。 另 外 ， 
ViewGroup 还 有 其 自己 的 特性 ， 我 们 统一 列 在 表 11-7 中 。 


表 11-7 ViewGroup 的 U1 属 性 


a ee ee 











关 必 etMargins (int left, int top, 
Fj \\int right, int bottom) 


.上 法 
Margin - - 
布 landroid:layout_marginL eft 
局 landroid:layout_marginTop 
属 llandroid:layout_marginRight 
性 llandroid:layout_marginBottom 





地 
法 
Layout 
”而 
局 llandroid:layout_height 
属 landroid:layout_width 
i 


ViewGroup.MarginLayoutParams 
是 从 ViewGroup 中 独立 出 来 专 
门 处 理 margin 的 类 


ViewGroup.LayoutParams 是 从 
ViewGroup 中 独立 出 来 专门 处 
理 Layout 的 ， 与 之 对 应 的 是 
layout_heigh 和 1layout_width 两 个 
布局 属性 这 两 者 的 使 用 非 
党 广泛， 几乎 所 有 应 用 程序 都 
需要 配置 它们 。 

在 前 一 小 节 描 述 View 属 性 的 表 
格 中 我 们 讲解 过 ， 它 们 在 View 
对 象 中 配置 ， 却 在 ViewGroup 
中 处 理 。 有 3 种 取 值 : 
FILL_PARENT: 废弃 值 ， 不 建 
议 使 用 

MATCH_PARENT: 和 父 对 象 
一 样 大 

WRAP_CONTENT: 只 需要 能 
刚好 履 盖 内 容 (包括 padding) 
所 占 的 空间 大 小 即 可 














11.7.3 View、ViewGroup 和 ViewParent 


这 三 者 既 有 联系 又 有 区 别 ， 如 图 11-18 所 示 。 


<<interface>> 
ViewParent 


*requestLayout () 

request TransparentRegion () 
+HnvalidateChuld () 

request tSystemWindows () 
+createContextMenu (} 





p — — = 





ViewGroup 


ViewRootlmp 





A 411-18 View. ViewGroup#eViewParent 


View 确 切 地 说 是 一 个 抽象 的 视图 对 象 《虽然 这 个 类 不 是 抽象 的 ) ， 
它 定 义 了 一 个 视图 所 需 具 有 的 属性 和 基本 操作 万 法 。ViewGroup 本 质 上 
也 是 一 个 View， 我 们 可 以 理解 为 YiewGroup 中 的 Content 是 由 若干 个 View 
组 成 的 。ViewParent 顾 名 思 义 是 一 个 View 的 “父亲 ”。 这 个 父亲 既 可 能 
是 ViewGroup， 也 可 能 是 ViewRoot。 也 就 是 说 ， 对 于 View Tree 
的 “ 根 ” (通常 它 是 一 个 ViewGroup) ， 它 的 “父亲 ”是 ViewRoot; 而 
其 他 元 素 的 “父亲 ” 则 是 ViewGroup。 


11.7.4 Callback 接口 


public class View implements Drawable.Callback, KeyEvent.Callback 
AccessibilityEventSource { sit 


由 以 上 代码 可 知 View 类 实现 了 以 下 几 个 接口 ， 如 图 11-19 所 示 。 


Accessibility 


EventSource 





View 


A 11-19 View 类 实现 的 回调 接口 


e View 类 中 将 会 使 用 Drawable; 
e Views Ik It KeyEvent; 
e View + (# JF] T AccessibilityEvent. 


AccessibilityEvent 是 系统 发 送 的 ， 反 映 UI 变 化 的 事件 。 比 如 按钮 
点 击 、 某 个 View 获 得 了 焦点 等 。 


先 来 看 看 什么 是 Drawable， 这 不 仅 是 Android 显 示 系 统 中 的 一 个 重 
要 概念 ， 也 是 应 用 开发 人 员 在 实现 UI 交互 表面 时 经 常会 接触 到 的 。 


按照 Android 的 解释 ，Drawable 就 是 “Something that can be 
drawn” 的 抽象 。 也 就 是 说 ， 它 表达 了 我 们 希望 在 屏幕 上 绘制 的 图 像 。 
举 个 例子 ， 一 个 Bitmap 文 件 就 可 以 说 是 Drawable， 因 为 它 承 载 了 图 片 的 
数据 。 这 些 数据 不 依赖 于 设备 平台 ， 只 是 图 片 自身 内 容 的 反映 (想象 一 
下 一 张 小 狗 的 Bitmap 图 片 ， 它 不 管 在 Android 设 备 上 ， 还 是 在 Windows 操 
作 系 统 上 ， 显 示 出 来 都 是 一 样 的 ， 不 会 变 成 其 他 动物 ) 。 


读者 可 能 会 觉得 奇怪 ， 我 们 的 View 类 不 也 有 数据 储存 这 个 功能 吗 ， 
它 与 Drawable 有 什么 区 别 呢 ? 


区 别 就 在 于 View 不 仅仅 包含 了 图 片 数据 ， 还 需要 处 理 各 种 事件 《〈 比 
如 触摸 事件 、 按 键 事件 等 ) 。 我 们 可 以 用 图 11-20 来 概括 它们 之 间 的 关 


7INO 


CallBack 





CallBack 


A 511-20 View 与 Drawable 的 关系 图 


Drawable 人 通常 会 以 如 下 形式 出 现 。 


e Bitmap 


这 是 形式 最 简单 的 Drawable， 除 了 图 像 本 身 ， 基 本 上 不 带 任 何 附 加 
信息 ， 如 一 张 PNG 或 者 JPEG 图 。 


e Nine Patch 


Android 系 统 自 定义 的 一 种 格式 ， 是 PNG 的 扩展 。 它 的 初衷 是 使 图 片 
ERAS TP RH, 因而 文件 本 身 会 附加 关于 拉 伸 操作 的 具体 信 


e Shape 


它 不 仅 包 含 了 原始 的 图 卢 数 据 ， 而 且 提供 了 简单 的 绘图 命令 来 保证 
我 们 在 某 些 图 像 尺寸 变 化 的 场合 能 产生 比较 好 的 效果 。 


e Layers 


复合 Drawable 中 的 一 种 。Layer 表 示 “ 层 ”， 复 数 形式 表示 会 有 多 
个 “ 层 ”， 这 些 层 不 断 地 又 加 在 彼此 之 上 。 


e States 


复合 Drawable 中 的 一 种 。State 代 表 “ 状 态 ”， 因 此 States 表 示 多 
种 状态 以 及 每 种 状态 所 对 应 的 图 像 。 这 在 应 用 开发 中 使 用 比较 频繁 ， 如 
一 个 按钮 有 over，pressed 和 normal 等 多 种 状态 ， 显然 我 们 在 山 卉 面 的 
ee \ 同 一 一 通常 情况 下 ， 当 按钮 被 按 下 时 ， 
高 显 或 加 深 颜色 显示 。Android 的 View 机 制 提 供 了 非常 便利 的 方式 来 满 
足 开发 者 的 多 状态 显示 需求 我 们 只 要 在 一 个 相关 的 xm1 中 定义 按钮 的 
E a 剩 下 的 难题 系统 会 自 
动 解决 。 





e Levels 


复合 Drawab le 中 的 一 种 ， 和 上 面 的 States 有 点 类 似 。 区 别 在 于 它 是 
以 Leve1 值 来 决定 需要 采用 哪 种 图 片 的 ， 而 不 是 State。 比 如 信号 格 数 分 
为 0~5 六 个 Level， 那 么 在 具体 情况 下 就 可 以 显示 对 应 的 图 片 。 


e Scale 


合 compound 中 的 一 种 。 从 名 字 可 以 看 出 ， 它 运用 于 需要 调整 尺寸 
大 小 的 场合 ， 即 根据 level 值 来 决定 图 形 的 尺寸 。 


Drawable 除 了 必 不 可 少 的 图 形 数 据 外 ， 还 封 洲 了 不 少 操作 函数 。 其 
主要 分 为 创建 、 销 毁 、 简 单 的 图 形 处理 、 绘 制 等 类 别 ， 有 兴趣 的 读者 可 
以 参考 官方 文档 。 


既然 Drawable 只 是 图 像 数 据 的 抽象 ， 那 么 当 图 形 有 变化 或 者 需要 重 
绘 时 ， 就 必然 要 通知 View。 完 成 这 一 操作 的 就 是 Drawable 的 Cal1back 接 
O: 


public static interface Callback { 
/* 当 drawable 需 要 人 被 重 绘 时 调用 */ 
public void invalidateDrawable(Drawable who); 
/* 用 于 drawable 规 划 动 画 的 下 一 帧 */ 
public void scheduleDrawable(Drawable who, Runnable wh 
/* 用 于 取消 scheduleDrawable 的 操作 */ 
public void unscheduleDrawable(Drawable who, Runnable 





} 


下 面 是 View 类 对 invalidateDrawab le 方法 的 实现 ， 其 他 两 个 函数 不 
影响 我 们 下 一 步 的 分 析 ， 因 此 暂时 略 过 : 


public void invalidateDrawable(Drawable drawable) { 
if (verifyDrawable(drawable)) { 
final Rect dirty = drawable.getBounds();/* 获 取 drawable 
/* 获 取 View 的 ScrollX 与 ScrollY*/ 

final int scrollX = mScrollx; 

final int scrollY = mScrolly; 
invalidate(dirty.left + scrollxX, dirty.top + scrolly, 
dirty.bottom + scrollY);/* 调 用 View 内 部 的 jnval 
一 个 长 方形 的 4 条 边 ， 分 别 为 left、t: 


} 

可 见 真 正 起 绘制 作用 的 是 View 中 的 invalidate 函 数 〈 做 过 MFC 开 发 
a 它 是 我 们 刷新 屏幕 上 的 图 形 时 所 需要 调 
用 的 ) 。 


这 个 inval idate 国 数 在 View 类 中 有 4 个 原型 ， 如 下 : 


public void invalidate(Rect dirty); 

public void invalidate(int 1, int t, int r, int b); 
public void invalidate(); 

void invalidate(boolean invalidateCache) ; 


关于 invalidate 的 源码 实现 ， 在 “View Tree 的 遍历 时 机 ”小 节 已 
ip, KERB. 


至 此 ， 我 们 已 经 将 View 类 所 实现 的 接口 介绍 完了 。 但 还 有 一 些 问 题 
并 没有 得 到 解决 ， 如 View 是 如 何 与 Drawable 联 系 起 来 的 ， 又 是 如 何 最 终 
将 图 形 显 示 到 屏幕 上 的 。 要 理 清 这 些 问题 ， 接 下 来 还 需要 花 点 时 间 来 学 
习 几 个 重要 的 概念 。 


11.8 “作画 “工具 集 


Canvas 的 字面 意思 是 “画布 ”， 按 照 Android 系 统 的 解释 ，“The 
Canvas class holds the draw calls”。 也 就 是 说 ， 它 其 实 是 将 “图 
像 ” 数 据 写 入 Bimap 中 的 一 个 工具 集 ， 取 名 Canvas 并 不 是 非常 贴切 ， 容 
易 引 起 误解 。 


大 家 可 以 想象 下 ， 如 果 需 要 在 屏幕 上 “作画 ”， 需 要 哪些 支持 我 
们 可 以 与 画家 的 创作 做 类 比 ) 呢 ? 





Canvas 


e Bitmap 


这 是 存储 数据 的 地 方 ， 类 比 于 画家 所 用 的 纸张 。 在 不 同 的 系统 实现 
中 可 能 还 会 有 进一步 的 封装 ， 如 我 们 之 前 谈 到 的 Drawable 以 及 它 的 众多 
子 类 。 


e Canvas 
作画 的 工具 集 ， 即 辅助 画家 完成 作品 的 一 个 “工具 箱 ”。 
e Drawing Primitive 


Primitive 一 般 用 来 形容 那些 不 可 再 分 割 的 元 素 。 比 如 一 个 操作 是 
由 A、B 两 部 分 组 成 ， 而 且 这 两 部 分 是 不 可 分 割 的 ， 那 么 它们 就 组 成 了 一 
个 Primitive 操 作 。 在 这 里 ，Drawing Primitive 就 是 指 Rect，Path,， 
Text 等 这 些 基础 元 素 。 


e Paint 


如 同 画家 在 绘制 不 同 风格 的 作品 时 ， 会 用 到 各 种 画笔 、 着 色 手 法 、 
样式 ， 我 们 在 电脑 上 “ 作 图 ”也 是 可 以 选择 各 式 各 样 的 Paint 的 。 读 者 
对 Paint 和 Canvas 的 功能 可 能 还 是 有 点 模糊 。 打 个 比方 ，Canvas 就 像 一 
台 打印 机 ， 它 按照 Primitive 的 描述 来 打出 线条 、 长 方形 等 ;而 Paint 则 
是 墨盒 一 一 这 也 就 意味 着 ， 装 上 了 不 同 颜色 墨盒 的 同一 台 打 印 机 ， 可 以 
打印 出 色彩 各 异 的 线条 、 长 方形 ， 如 图 11-21 所 示 。 





我 们 知道 ， 打 印 机 的 工作 流程 大 致 是 : 

(1) 找到 一 台 能 正常 工作 的 打印 机 〈Canvas) ; 
准备 好 需要 的 墨盒 〈(Paint) ; 

将 墨盒 装 入 打印 机 

准备 好 需要 的 纸张 (Bitmap) ; 

将 纸张 放 入 打印 机 的 纸 模 ; 


(6) 通过 某 种 传输 途径 “〈 网 络 连 接 、U 盘 连接 ) 向 打印 机 
(Canvas) 发 送 打印 命令 ， 如 男 一 条 线 、 一 个 长 方形 或 者 文字 等 ; 


(7) 打印 机 《〈Canvas) 将 结果 输出 到 纸张 (Bitmap) E; 


5 (8) 完成 打印 后 ， 用 户 到 打印 机 的 纸张 出 口 处 获取 已 经 打印 好 的 
纸张 ; 
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QW 
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Wa 
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wy ONY 


(5 


(9) 用 户 检 查 纸张 上 的 绘图 结果 是 否 符合 预期 要 求 。 

这 样 读者 对 Canvas 应 该 有 一 些 初步 的 认识 了 。 还 有 一 点 需要 特别 指 
出 的 是 ，Canvas 这 台 “ 打 印 机 ”本 身 其 实 是 带 有 “纸张 ”的 一 一 它 内 部 
封装 了 存储 U1 数据 的 内 存 空间 。 

接 下 来 我 们 将 分 几 个 小 节 来 逐步 剖析 Canvas。 
11. 8. 1 “绘制 UI” 一 一 Skia 

实际 上 在 应 用 程序 中 “绘制 U1” 的 方法 有 很 多 种 ， 并 不 拘泥 于 
OpenGL ES。 比 如 我 们 在 SurfaceFlinger 章 节 曾 提 到 过 的 Skia， 也 是 一 
个 可 行 的 方式 。 

如 图 11-22 所 示 。 

Skia 是 到 目前 为 止 Android 仍 然 在 采用 的 ， 适 用 于 Java 层 View Tree 


中 绘制 UI 表面 的 一 个 20 图 形 引 警 库 。 本 地 层 的 Canvas 和 Bitmap 实 现 ， 也 
都 基于 Skia。 因 而 ， 我 们 有 必要 先 对 它 做 一 个 了 解 。 


Skia 最 初 由 Skia 1nc 公 司 开 发 ， 并 在 2005 年 被 Google 收 购 。 从 这 个 
时 间 点 来 看 ， 我 们 有 理由 相信 Google 当 时 收购 Skia 的 重要 目的 之 一 ， 就 
是 给 Android 系 统 做 准备 。 目 前 ，Skia 已 经 被 应 用 到 了 除 Android 外 的 很 
多 知名 项 目 中 ， 如 Mozilla Firefox, Google Chrome, Chrome 0S 等 。 
其 源码 项 目的 管理 主页 地 址 是 : 


http://code. google. com/p/skia/。 






Memory Buffer 


SurfaceF linger 


全 图 11-22 Skia 


Skia 在 Android 工 程 中 的 源码 目录 是 : external\skia. 


再 来 思考 一 人 下， 市 面 上 的 开源 图 形 库 ， 特 别 是 20 引 警 的 可 选择 性 还 
是 比较 多 的 ， 为 什么 Google 要 大 费 周 折 地 另起炉灶 呢 ? 换 句 话说 ，Skia 
的 优势 何在 ? 


Skia 公 司 的 创始 人 是 图 形 领 域 的 顶级 专家 ，George Michael 
( “Mike” ) Reed 博 士 。 他 曾 在 牛津 大 学 任教 近 二 十 年 〈1986 一 2005 
年 ) ， 不 过 从 目前 0xford 的 Fellow List 介 绍 (http://www. seh. ox. 
ac. ük/fel lows-and-staff/emer itus—fel oa 来 看 ， 很 可 能 已 经 退休 
了 。 从 2005 年 开始 ， 他 成 为 澳门 UNUA11ST 的 Director 〈 应 该 也 已 退 
fE). 


Skia 一 开始 就 受到 了 外 界 的 关注 。 其 第 一 个 产品 SGL 因 在 低 配 置 的 
手持 设备 上 表现 出 的 高 效 性 而 被 人 称道 。 综 合 源 码 和 一 些 文档 说 明 ， 我 
们 总 结 出 Skia 的 优秀 特性 如 下 : 


器 平台 

高 度 优 化 BY Je Se 28 5 

可 选 的 硬件 加 速 ( 比 如 基于 OpenGL) ; 

动画 实现 (源码 目录 external\skia\stc\animator) ; 

图 片 解码 (JPG\PNG\GIF\BMP 等 ， 源 码 目录 
external\skia\ stc\images) 

o 文本 绘制 能 力 (源码 目录 external\skia\stc\text) ; 

© 支持 多 种 特效 (源码 目录 external\skia\src\effects) o 





了 解 了 Skia 的 基础 知识 后 ， 我 们 再 回 到 Canvas 的 分 析 中 ， 并 以 此 为 
契机 进一步 挖掘 关于 Skia 的 更 多 知识 。 





Surface. |ockCanvas 


11.8.2 数据 中 介 


大 家 要 知道 ， 与 View 组 件 直接 打交道 的 是 Canvas， 而 不 是 
Drawable。 比 如 View 类 中 的 绘图 函数 : 


draw(Canvas canvas); 
其 参数 中 传 入 的 就 是 一 个 可 用 的 Canvas。 


不 过 根据 前 一 章节 的 学 习 ， 我 们 又 了 解 到 应 用 进程 端 与 
SurfaceFlinger 间 的 数据 中 介 并 不 是 Canvas， 而 是 Surface。 这 就 不 可 
避免 地 存在 一 个 问题 ， 即 Canvas 和 Surface 之 间 是 如 何 协作 的 。 


ViewRoot1mp| 中 取得 一 个 Canvas 的 方法 如 下 : 


canvas = mSurface.lockCanvas(dirty); 


lockCanvas 是 一 个 jni 国 数 ， 对 应 的 实现 核心 如 下 : 


/*frameworks/base/core/jni/android_view_Surface.cpp*/ 
static void nativeLockCanvas(JNIEnv* env, jclass clazz, 
jint nativeObject, jobject canvasObj, jobject dirtyRectOb 
sp<Surface>surface(reinterpret_cast<Surface *>(nativeObject ) ) 


//it dirty region, 代码 略 .. 

ANativeWindow_Buffer outBuffer;// 用 于 存储 UI 数据 的 Buffer 

Rect dirtyBounds(dirtyRegion.getBounds()); 

status_t err = surface->lock(&outBuffer, &dirtyBounds) ) ;// 获 取 - 


SkBitmap bitmap; 
ssize_t bpr = outBuffer.stride * bytesPerPixel(outBuffer.form 
bitmap.setConfig(convertPixelFormat(outBuffer.format), outBuf 


if (outBuffer.width > 0 && outBuffer.height > 0) { 
bitmap.setPixels(outBuffer .bits);// 为 Bitmap 分 配 可 用 的 数据 空间 
} else { 
bitmap.setPixels(NULL); 


} 
SkCanvas* nativeCanvas = SkNEW_ARGS(SkCanvas, (bitmap) ) ;// 通 过 
swapCanvasPtr(env, canvasObj, nativeCanvas) ;V/* 将 本 地 Canvas 保 存 到 Jav 


对 象 的 成 员 


我 们 最 关心 的 问题 是 ，Canvas 中 自 带 的 “纸张 ”从 何 而 来 ? 可 以 肯 
定 的 是 ， 它 与 Surface 有 关系 ， 所 以 我 们 沿 着 这 条 线索 来 分 析 源 码 。 注 
意 区 别 源码 中 有 两 个 Surface， 分 别 面 向 Java 层 〈 对 应 函数 参数 clazz ) 
和 C++ 本 地 层 (对 应 参数 native0bject) 。 涵 数 首 先 通 过 强制 类 型 转换 
来 把 native0b ject 变 成 本 地 的 Surface 对 象 。 


本 地 Surface 对 象 随后 通过 lock (&info, &dirtyRegion) 来 获取 一 
个 可 用 的 Buffer 。 这 个 ANativeWindow Buffer 大 有 文章 ， 其 内 的 bits 就 
是 我 们 要 找 的 “纸张 ”: 


typedef struct ANativeWindow_Buffer { 
int32_t width;// 宽 度 ， 以 像素 为 单位 





int32_t height;// 高 度 ， 以 像素 为 单位 
int32_t stride;// 内 存 中 buffer 的 每 一 行 所 占 的 像素 值 ， 可 能 大 于 等 于 widtr 
int32_t format;// 缓 冲 区 格式 ， 即 WINDOW_FORMAT _* 
void* bits;// 存 储 数 据 的 地 方 
uint32_t reserved[6];// 保 留 
} ANativeWindow_Buffer; 


所 以 问题 进一步 转化 为 : bits 如 何在 接 下 来 的 步骤 中 “封存 ”到 


Canvas 中 ? 


Java 层 的 Canvas 与 Surface 在 本 地 都 有 与 之 相对 应 的 类 ， 分 别 是 
SkCanvas 和 Surface， 后 两 者 由 C++ 编写 。 本 地 的 Canvas 在 上 面 范 数 中 的 
变量 名 为 nativeCanvas， 由 如 下 语句 构造 完成 : 


SkNEW_ARGS(SkCanvas, (bitmap)); 


这 个 宏 定 义 展开 来 就 是 new SkCanvas (bitmap) ， 即 生成 了 一 个 
SkCanvas 对 象 ， 且 以 bitmap 作 为 构造 函数 的 入 参 。 


因为 Canvas/SkCanvas 只 是 “打印 机 ”， 其 内 部 的 “ 纸 盒 ” 需 要 装 
载 “打印 纸 ” 才 能 正常 工作 ， 这 就 是 SkBitmap 从 名 称 上 可 以 看 出 ， 
它 和 SkCanvas 都 属于 Skia 工 程 。 


程序 使 用 了 bitmap 变 量 来 表示 一 个 SkBitmap， 不 过 一 开始 它 只 是 一 
个 “ 空 过”， 真 正 存储 图 形 数 据 的 内 存 块 还 需要 通过 setPixels 来 配 
置 。 所 以 前 面 ANativeWindow Buffer 内 部 的 
ANativeWindow_Buffer.bits 所 指向 的 内 存 地 址 被 作为 参数 传 入 
SkBitmap 中 。 这 样 SkBitmap 才 是 一 个 有 效 的 类 。 


经 过 这 些 操作 后 ，SkCanvas 就 成 功 地 装载 了 『 “打印 纸 ”。 当 然 ， 最 
终 lockCanvas 哨 数 返 回 的 还 是 Java 层 的 Canvas 对 象 ， 这 是 由 J 改 1 机 制 所 
决定 的 。 

Surface，Canvas 等 元 素 的 关系 如 图 11-23 所 示 。 


明白 了 整体 流程 后 ， 我 们 再 来 详细 分 析 Surface. lock 获 得 的 内 存 块 
(bits) 的 由 来 。 


根据 前 面 章节 的 分 析 可 知 ，Surface (C++) 是 0penGL ES 的 本 地 窗口 
之 一 。 不 过 ， 这 并 不 代表 它 必 须要 借助 于 0penGL ES 来 完成 U1 绘制 。 事 





实 上 ，Surface 具 有 两 面 性 甚至 多 面 性 。 或 者 用 更 通俗 的 话 讲 ， 它 的 职 
责 只 是 管理 SurfaceF1inger 分 配 的 用 于 存储 U1 数据 的 “内 存 块 ”而 已 。 
至 于 上 层 有 多 少 种 不 同 用 户 以 及 由 此 所 产生 的 各 种 对 Surface 的 使 用 方 
法 ， 它 是 不 需要 理会 的 。 如 图 11-24 所 示 。 


lockCanvas 


SkCanvas 





AW 11-23 lockCanvas 各 元 素 关系 





SurtaceF linger 


全 图 11-24 Sutface 的 多 面 性 


因此 Surface 只 是 一 个 中 介 而 已 ， 它 将 通过 与 SurfaceFlinger 的 一 


系列 协作 来 满足 上 层 的 需求 。 比 如 1ock 的 实现 如 下 : 


/*frameworks/native/libs/gui/Surface.cpp*/ 
status_t Surface::lock( ANativeWindow_Buffer* outBuffer, ARect* i 


{ 


if (mLockedBuffer != 0) {//Step1. 判断 当前 是 否 已 经 有 buffer 被 lockt 
ALOGE("Surface::lock failed, already locked"); 
return INVALID_OPERATION; 





} 


if (!mConnectedToCpu) {//Step2. 当前 是 否 已 经 建立 必要 的 连接 
int err = Surface: :connect(NATIVE WINDOW_ API_CPU);/*Step3 


/*Step4. 设置 内 存 块 的 用 法 */ 
setUsage(GRALLOC_USAGE_SW_READ_OFTEN | GRALLOC_USAGE_SW_W 




















Í 


ANativeWindowBuffer* out; 
int fenceFd = -1; 
status_t err = dequeueBuffer(&out);/*Step5. 从 buffer 队 列 中 dequt 
if (err == NO_ERROR) { 
sp<GraphicBuffer> backBuffer(GraphicBuffer: :getSelf (out) ) 


/*Step6. backBuffer5SfrontBuffer*/ 
const sp<GraphicBuffer>& frontBuffer(mPostedBuf fer ) ;//E— 
const bool canCopyBack = (frontBuffer != 0 &&backBuffer -> 
backBuffer->height == frontBuffer->height && 
backBuffer->format == frontBuffer->format );// 
if (canCopyBack) { 
/* 计 算 可 以 从 上 一 次 的 buffer 中 copy 多 少数 据 */ 
const Region copyback(mDirtyRegion.subtract(newDi 
if (!copyback.isEmpty()) 
copyBlt(backBuffer, frontBuffer, copyback); 














} else { 
/* 如 果 无 法 利用 上 一 次 的 计算 结果 ， 那 么 要 告知 上 层 用 户 ， 它 们 要 : 
// 代 码 省 略 

} 


void* vaddr; 
/*Step7. 锁定 buffer*/ 
status_t res = backBuffer->lock(GRALLOC_ USAGE_ SW_ READ 
GRALLOC_USAGE_SW_WRITE_OFTEN, newDirtyReg 
if (res != 0) { 
err = INVALID_OPERATION; 
} else {/*Step8. 收尾 工作 ， 以 及 函数 出 参 赋值 */ 
mLockedBuffer = backBuffer; 





} 
} 


return err; 


Step16@Surface: :1ock。 当 前 被 1ocked 的 buffer 最 多 只 能 有 一 个 ， 
以 mLockedBuffer 来 表示 ， 这 是 一 个 GraphicBuffer 类 型 的 强 指针 变量 。 
当 每 次 lock 成 功 后 ， 它 就 会 被 赋值 为 当前 被 1ocked 的 buffer; 而 当 U1 绘 
图 结束 并 调用 unlockAndPost 时 ， 这 个 mLockedBuffer 会 被 清空 ， 且 另 一 
个 变量 mPostedBuffer 用 于 记录 最 近 一 次 的 post 操 作 。 


因而 在 lock 涵 数 的 最 开始 ， 我 们 要 判断 mLockedBuffer 是 否 为 空 : 


假如 不 是 ， 就 要 避免 再 次 锁定 一 个 buffer 。 这 种 情况 将 直接 返回 
INVAL1D_OPERATI10N 类 型 的 错误 。 

Step2@Surface: :1ock。 接 下 来 ， 程 序 还 需要 判断 mConnectedToCpu 
是 否 为 true。 这 个 变量 名 称 有 点 怪 ， 实 际 上 它 想 表 达 的 意思 是 一 在 此 
之 前 是 否 已 经 成 功 地 执行 了 1GraphicBufferProducer. connect。 而 名 
称 最 后 的 “cpu” 是 指 connect 的 类 型 ， 包 括 表 11-8 所 列 的 几 种 。 


表 11-8 connect 的 类 型 


当 buffer 被 OpenGL ES 填充 

完成 后 ， 将 由 EGL 通 过 

eglSwapBuffers 来 入 队 
(queue ) 


NATIVE_WINDOW_API_EGL 


当 buffer 被 CPU (也 就 是 软 
NATIVE. WINDOW_API CPU 件 计算 ) 填充 完成 后 ， 入 
队 处 理 





当 buffer 被 video decoder 填 
NATIVE_WINDOW_API MEDIA | 充 完成 后 ， 由 Stagefright 来 
执行 入 队 


由 camera HAL 来 调用 入 队 


NATIVE_WINDOW_API CAMERA|= 
操作 





在 当前 这 个 场景 中 ， 显 然 连接 类 型 选择 的 是 
NATIVE_WINDOW_API_CPU. 


Step3@Surface: :1ock。 假 如 mConnectedToCpu 为 false， 则 主动 调 


用 connect 函 数 来 完成 连接 ， 从 函数 入 参 值 也 可 以 验证 前 面 对 类 型 的 判 


Step4@Surface: :1ock。 紧 接着 我 们 设置 内 存 块 的 用 法 ， 如 buffer 
是 否 经 常 被 软件 读 写 。 这 个 值 并 不 会 马上 传递 给 SurfaceFlinger， 而 是 
先 存储 到 内 部 的 成 员 变 量 mReqUsage 中 ， 在 后 续 的 dequeueBuffer 中 才 作 
为 参数 告知 SurfaceF1inger。 


Step5@Surface: :1ock。 一 切 准 备 就 绪 ， 现 在 可 以 向 
SurfaceFlinger 申 请 一 个 可 用 的 buffer 了 。 这 一 部 分 的 源码 实现 在 前 几 
个 章节 已 经 详细 分 析 过 ， 这 里 就 不 再 玫 述 。 


Step6@Surface: :1ock。 这 段 代 码 有 两 个 重要 变量 ， 即 backBuffer 
和 frontBuffer。 需 要 特别 注意 的 是 ， 它 们 并 不 是 前 面 章 节 中 提 及 的 双 
缓冲 区 概念 ， 而 是 分 别 代 表 当 前 正在 处 理 的 buffer 和 上 一 次 处 理 的 
buffer. 


两 次 图 像 更 新 闻 通 常 并 不 需要 重新 绘制 整个 屏幕 区 域 ， 因 而 我 们 完 
全 可 以 借助 于 之 前 buffer 的 计算 结果 来 填充 本 次 的 buffer 内 容 ， 以 加 快 
处 理 速度 。 判 断 两 个 buffer 间 能 否 复制 的 标准 之 一 是 canCopyBack， 判 
断 条 件 包 括 : frontBuffer!=0， 并 且 两 者 的 宽 、 高 和 格式 必须 完全 一 
致 。 在 这 个 变量 为 true 的 情况 下 ， 程 序 会 计算 出 需要 复制 的 那 一 部 分 区 
并 由 copyback 来 表示 ， 最 后 通过 copyB1t 吧 数 来 完成 复制 过 
2 。 

假如 前 后 两 次 buffer 不 能 复制 ， 那 么 我 们 要 告知 使 用 者 必须 刷新 整 
个 屏幕 区 域 。 为 了 帮 大 家 加 深 印 象 ， 我 们 以 对 话 形式 来 描述 这 一 过 程 ， 
如 图 11-25 所 示 。 
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全 图 11-25 围绕 绘图 板 展开 的 对 话 


Step7@Surface: :1ock。 锁 定 这 个 buffer， 以 防止 别人 使 用 。 可 以 
参见 前 面 SurfaceF1inger 章 节 关 于 BufferSlot 生 命 周 期 的 讨论 。 


Step8@Surface: :1ock。 当 前 被 锁定 的 buffer， 即 mLockedBuffer 可 
以 通过 backBuffer 来 赋值 ， 另 外 ，1ock 也 数 的 计算 结果 需要 告知 调用 
者 ， 包 括 申 请 到 的 buffer 的 属性 〈 宽 、 高 等 )， 存 储 U1 数 据 的 内 存 块 首 
地 址 bits 等 ， 这 些 都 通过 outBuffer 函 数 出 参 传 递 给 上 层 用 户 。 


11.8.3 解锁 并 提交 结果 一 一 unlockCanvasAndPost 


一 旦 UI 绘图 完成 ， 程 序 需 要 将 这 幅 “ 画 ”人 解锁， 并 提交 给 系统 进行 
这 里 的 系统 具体 指 的 是 SurfaceF1inger 这 个 服务 。 


Surface 提 供 了 与 前 一 小 节 lock 〈 可 能 命名 为 “lockCanvas” 会 更 
贴切 ) 相配 套 的 unlockCanvas AndPost， 以 便 ViewRoot Impl Æ 
performDraw 遍 历 后 ， 可 以 利用 这 个 接口 来 告知 Surface 一 个 完整 的 绘图 
操作 已 经 完成 。 这 个 函数 的 Java 层 实现 很 简单 ， 读 者 可 以 自行 分 析 。 我 
们 直接 看 它 在 JNI 中 的 实现 : 
/*frameworks/base/core/jni/android_view_Surface.cpp*/ 


static void nativeUnlockCanvasAndPost(JNIEnv* env, jclass clazz, 
sp<Surface> surface(reinterpret_cast<Surface *>(nativeObject) 





N= 
泻 染 


status_t err = surface->unlockAndPost(); 


JN1 层 的 nativeUnlockCanvasAndPost 又 调用 了 Surface (C++) 提供 的 
unlockAndPost: 


/*frameworks/native/libs/gui/Surface.cpp*/ 
status_t Surface: :unlockAndPost( ) 
{ 
if (mLockedBuffer == 0) {// 当 前 是 否 有 可 用 的 Buffer 
ALOGE("Surface::unlockAndPost failed, no locked buffer"); 
return INVALID_OPERATION; 
} 
status_t err = mLockedBuffer->unlock();//Buffer 解 除 锁 定 
err = queueBuffer(mLockedBuffer.get());//Buffer 入 队 


mPostedBuffer 
mLockedBuf fer 
return err; 


mLockedBuf fer ; 
0; 


第 一 步 判 断 mLockedBuffer 是 否 为 空 ， 这 个 变量 代表 当前 被 锁定 的 
buffer， 在 前 面 分析 的 Surface: :lockegA ASV Ac. FAA 
mLockedBuffer==0， 程 序 即刻 出 错 返回 。 


接着 ，mLockedBuffer 通 过 unlock 来 解锁 ， 这 个 函数 是 与 上 一 小 节 
Step7 中 的 backBuffer->lock 相 对 应 的 。 执 行 完 unlock 后 ， 现 在 可 以 把 
buffer 入 队 了 ， 即 queueBuffer 。SurfaceFlinger 便 可 以 在 后 续 的 合成 
中 对 这 一 buffer 进 行 处 理 ， 并 最 终 将 其 显示 到 屏幕 上 。 最 后 ， 
mPostedBuffer 记 录 下 已 经 提交 成 功 的 buffer， 这 将 作为 下 一 次 1ock 时 
的 参考 ; 而 mLockedBuffer 会 被 清 零 ， 以 等 待 新 的 lock 请 求 。 


11.9 draw 和 onDraw 
学 习 完 Canvas 的 实现 机 制 后 ， 现 在 可 以 把 重心 再 放 到 Java 应 用 层 。 


我 们 知道 ，ViewRootlmp1 的 遍历 分 为 3 步 ， 即 performMeasure、 
performLayout 和 performDraw。 前 两 步 我 们 都 已 经 完整 分 析 过 ， 还 剩 下 
最 后 也 是 最 关键 的 一 个 环节 ， 即 应 用 程序 配合 执行 performDraw 的 过 


程 。 

那么 ，View 对 象 绘制 图 形 的 一 般 流程 是 怎样 的 呢 ? 

一 旦 ViewRoot1mp1 成 功 lock 到 Canvas， 它 就 可 以 通过 ViewTree 的 根 
元 素 逐 步 把 这 个 “ 男 板 工具 ” 往 下 传输 。 因 而 第 一 个 被 处 理 的 元 素 是 最 


外 围 的 Décor View〔 针 对 PhoneWindow 的 情况 ) ， 如 下 所 示 (假设 是 在 
软件 泻 染 的 情况 下 ) : 


private boolean drawSoftware(..) {... 
mView.draw(canvas); 


} 

变量 myiew 是 ViewRoot1mp1 内 部 用 于 记录 ViewTree 根 元 素 的 成 员 变 
量 ， 它 的 draw 函 数 就 是 整 棵 ViewTree 绘 图 轴 历 的 起 点 。 另 外 ， 虽 然 
Decor View 是 ViewGroup， 但 并 不 重 载 draw 方 法 ， 所 以 上 述 代 码 段 中 还 
是 调用 了 View. draw。 


在 分 析 源 码 前 先 来 思考 一 下 : 如 果 你 是 View 的 设计 者 ， 将 如 何 编排 
这 个 draw 上 函数 呢 ? 至 少 有 两 个 大 方向 要 特别 注意 : 


e draw 5 onDrawh) DB 
因为 后 续 的 View 子 类 硕 望 只 重 载 onDraw， 而 不 是 整个 draw 函 数 。 这 
就 给 我 们 提出 了 强制 性 要 求 ， 即 View 的 draw 函 数 设 计 要 具有 共性 因 
为 我 们 没有 办 法 预先 知晓 所 有 扩展 子 类 的 行为 。 
e dtaw 中 的 绘图 顺序 
View 中 包含 的 U1 内 容 很 多 ， 绘 图 是 否 有 特定 的 顺序 ?如 图 11-26 所 
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全 图 11-26 onDraw & žk 
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全 图 11-27 View 所 表达 的 UI 界面 


也 就 是 说 ，View 类 中 有 如 下 UI 元素。 


e background 
View 视 图 通常 需要 设置 一 个 背景 ， 如 一 张 图 片 。 
e content 


内 容 区 域 是 这 个 View 真 正 想 表达 的 画面 ， 所 以 是 重 中 之 重 。 根 据 以 
前 的 分 析 ， 这 个 区 域 与 外 边框 通常 情况 下 会 有 一 定 的 距离 ， 即 
padding。 


e decorations 


主要 是 指 scrollbar 。 滚 动 条 分 为 垂直 和 水 平 两 种 ， 位 置 也 是 可 以 


调整 的 。 
e fading 


有 
特效 。 


之 着 这 些 基础 知识 ， 我 们 来 看 看 View 类 中 draw 肖 数 的 源码 实现 : 


public void draw(Canvas canvas) {... 
final int privateFlags = mPrivateFlags; 
final boolean dirtyOpaque = (privateFlags & PFLAG_DIRTY_M 
PFLAG_DIRTY_ OPAQUE&& (mAttachInfo == null || !mAttachI 
mPrivateFlags = (privateFlags & ~PFLAG_DIRTY_MASK) | PFL/ 
// Step 1. 2ER: 
int saveCount; 
if (!dirtyOpaque) { 
.…// 具 体 代码 稍 后 分 析 


} 

/* 接 下 来 分 为 两 种 情况 : 要 么 完整 执行 Step2-6; 要 么 跳 过 其 中 的 Step2 和 St 

的 详细 说 明 ， 请 结合 起 来 阅读 )*/ 

final int viewFlags = mViewFlags; 

boolean horizontalEdges = (viewFlags & FADING_EDGE_HORIZO 

boolean verticalEdges = (viewFlags & FADING_EDGE_VERTICAL 

if (!verticalEdges && !horizontalEdges) {// 情 况 1， 没 有 fadii 
if (!dirtyOpaque) onDraw(canvas);// Step 3， 绘 制 内 容 
dispatchDraw(canvas);// Step 4, 绘制 子 对 象 
onDrawScrollBars(canvas);// Step 6， 绘 制 decoration 
































return;// 直 接 返 回 
} 


/* 情 况 2， 如 果 程 序 走 到 这 里 ， 说 明 我 们 要 完整 执行 Step2-Step6(uncommc 
..// 有 具体 代码 略 








在 阅读 上 面 源码 的 过 程 中 ， 首 先 要 抓 住 一 个 重点 ， 即 它 的 绘制 顺序 
是 怎样 的 。 我 们 已 经 对 每 一 个 步骤 都 做 了 注释 ， 总 的 来 说 是 : 


(1) 绘制 背景 。 
显然 背景 在 最 撒 层 ， 会 被 其 他 元 素 所 黎 兰 ， 因 而 需要 最 先 被 绘制 。 


(2) 保存 canvas 的 layers， 以 备 后 续 fading 所 需 。 


(3) 绘制 内 容 区 域 。 
(4) 绘制 子 对 象 〈 如 果 有 的 话 ) 。 
(5) 绘制 fading 〈 如 果 有 的 话 ) ，restore 第 (2) 步 保存 的 


layers. 
(6) 绘制 decorations (主要 是 scrollbars) o 


上 述 6 个 步骤 并 不 是 每 次 draw 过 程 都 会 被 全 部 执行 。 比 如 step 2 和 
step5 对 于 很 多 应 用 程序 来 讲 都 是 可 选 的 ， 并 不 需要 考虑 。 由 此 ， 整 个 
draw 函 数 分 为 两 种 Cases。 


Case1 (Common Case): 假如 horizontalEdges 和 verticalEdges 都 为 
空 ， 那 么 可 以 跳 过 第 2 步 和 第 5 步 一 一 这 将 大 大 简化 整个 函数 流程 。 其 他 
Steps 所 对 应 的 实现 分 别 是 : 





Step3: onDraw。 
Step4: dispatchDraw. 


Step6: onDrawScrol |Bars. 


其 中 对 于 onDraw 会 在 后 续 内 容 中 做 详细 分 析 。 而 剩余 Steps 比 较 简 
单 ， 大 家 可 以 自行 阅读 理解 。 


另外 ， 第 一 个 步骤 即 背 景 的 绘制 是 在 两 种 情况 下 都 要 考虑 的 。 代 码 
实现 如 下 : 


final Drawable background = mBackground; 
if (background != null) {V// 背 景 资 源 存在 
final int scrollX = mScrollx; 
final int scrollY = mScrolly; 


if ((scrollxX | scrollY) == 0) { 
background.draw(canvas); 

} else { 
canvas.translate(scrollxX, scrollyY); 
background.draw(canvas); 
canvas.translate(-scrollxX, -scrollyY); 


} 


背景 图 记录 在 mBackground 成 员 变 量 中 ， 所 以 如 果 这 个 值 为 空 ， 我 
们 就 没有 必要 往 下 执行 了 。 另 一 个 需要 考虑 的 是 mScrol1X/mScrol1Y， 
假如 这 两 个 值 都 为 0%， 说 明 当 前 View 还 没有 或 者 不 用 Scrol1， 这 样 
background 就 可 以 直接 绘制 ; 否则 它 还 应 该 进行 必要 的 坐标 变换 〈 注 
意 : background. draw 结 束 后 坐标 变换 需要 还 原 回 来 ) 。 


在 分 析 onDraw 具 体 的 实现 代码 前 ， 我 们 先 通 过 两 个 小 例子 来 帮助 读 
者 准备 一 些 基础 知识 。 


例 1: 


假设 有 一 个 LinearLayout (ViewGroup) ， 包 含 了 3 个 View 对 象 ， 并 
且 它 们 都 平均 分 配 空间 位 置 (View 树 里 每 个 节点 的 位 置 和 空间 大 小 的 计 
算 ， 在 Android 中 有 一 个 完整 的 逻辑 流程 。 这 其 中 涉及 很 多 细节 与 用 户 
配置 ， 如 margin，weight 等 。 不 清楚 的 读者 可 以 参见 前 面 
View/ViewGroup 属 性 的 讲解 。 我 们 这 里 假设 3 个 View 视 图 所 占 的 空间 大 
小 是 平均 分 配 的 ) 。 那 么 ， 整 体 效果 看 起 来 是 这 样 的 〈View 的 大 小 和 位 
置 确定 好 后 了 ) ， 如 图 11-28 所 示 。 


LinearLayout 
0, 9 


View! View? View: 





A 11-28 确认 好 位 置 和 大 小 后 的 状态 


也 就 是 说 ， 最 终 每 个 View 的 大 小 都 是 150*80。 我 们 知道 ， 如 果 View 
对 象 所 占 的 面积 足够 支撑 它 的 内 容 区 域 ， 那 么 就 不 需要 滚动 条 了 ， 这 样 
问题 会 简单 点 ; 否则 如 果 内 容 过 多 ， 一 次 性 无 法 显示 完整 ， 那 情况 又 不 
一 样 了 。 以 View3 为 TextView 为 例 ， 用 户 在 阅读 一 个 字数 较 多 的 文本 时 
通常 需要 不 断 滚 屏 来 浏览 全 文 ， 如 图 11-29 所 示 。 
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全 图 11-29 TextView 起 始 状 态 


”如 图 11-29 所 示 ， 是 TextView 的 起 始 状 态 ， 即 还 没有 操作 滚动 条 时 
的 效果 。 因 为 整个 文本 超出 了 View3 的 可 视 范 围 ， 用 户 在 阅读 过 程 中 肯 
定 需要 不 断 调整 滚动 条 来 获取 他 所 需要 的 信息 ， 如 图 11-30 所 示 。 





可 以 看 到 ， 当 滚动 条 起 作用 后 ， 文 本 的 起 点 位 置 不 再 与 Yiew3 的 起 
始 原点 重合 。 这 时 View 中 的 内 部 变量 mscro11X 和 mScrol1Y 也 会 被 赋予 相 
应 的 值 。 通 过 这 个 小 例子 ， 我 们 明白 了 以 下 几 点 。 


。 每 个 View 的 大 小 都 会 受到 其 他 View 的 制约 


假设 View 的 大 小 是 wrap_content 的 ， 那 么 父 类 会 根据 其 所 有 子 类 的 
实际 情况 ， 为 这 个 View 分 配 相应 的 大 小 。View 也 可 以 强制 指定 所 需 的 空 
间 大 小 ， 不 过 能 否 最 终 满足 ， 还 依赖 于 其 他 View 的 配置 。 总 之 ， 分 配 过 
程 遵循 “ 尽 可 能 满足 所 有 View 的 需求 ， 但 又 公平 、 人 合理” 的 原则 进行 。 
具体 细节 可 以 参见 前 面 小 节 对 遍历 流程 的 分 析 。 
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全 图 11-30 TextView 的 滚动 条 效果 


。 View 的 “潜在 ”显示 内 容 有 可 能 超过 其 可 视 区 域 


View 的 大 小 是 有 限制 的 ， 而 “显示 内 容 ” 理 论 上 是 无 限 的。 比如 字 


数 众多 的 一 个 Text 文 本 ， 即 便 我 们 给 它 整 个 屏幕 空间 ， 也 未 必 能 一 次 性 
全 部 显示 出 来 。 所 以 ，View 内 市 有 滚动 条 操作 是 合理 而 且 必 需 的 。 在 理 
解 滚动 、View 以 及 内 容 之 间 的 关系 时 ， 我 们 可 以 这 样 想 : 


View 的 可 视 区 域 是 不 变 的 。 也 就 是 说 ， 上 面 View3 的 可 视 区 间 
是 父 类 分 配 的 ,为 (Left:300, Top:0, Right:450, 
Bottom:80) 。 这 个 区 域 是 客观 存在 的 ， 并 不 会 随 着 View3 本 身 
的 “意志 而 转移 ” (比如 View3 拉 动 了 滚动 条 ， 并 不 会 改变 它 的 显 
示 区 域 。 当 然 ， 如 果 是 View3 主 动向 父 类 发 起 了 1ayout 变 更 请 求 ， 
而 且 父 类 也 同意 了 ， 那 么 这 个 区 域 是 会 变化 的 。 不 过 这 也 会 影响 到 
其 他 View 的 位 置 和 大 小 ， 所 以 一 定 会 引起 ViewRoot Imp1 对 ViewTree 
进行 重新 遍历 ) 。 


当 滚 动 条 操作 时 ， 显 示 内 容 会 发 生变 化 。 这 就 像 用 眼睛 看 世 开 
一 样 ， 世 再 是 无 穷 大 的 ， 但 我 们 可 以 看 到 的 视野 是 有 限 的 ， 因 为 眼 
球 的 “可 视 区 域 ” 惑 那么 大 。 虽 然 无 法 改变 这 个 可 视 苑 围 的 大 小 ， 
= a a 

To 


明白 了 以 上 几 点 后 ， 我 们 再 来 小 结 下 View 要 怎么 做 才 可 能 满足 上 面 


的 需求 。 


当 一 个 View 对 象 经 过 ViewRootImpl 的 统一 遍历 后 ， 它 会 有 固定 的 大 
小 及 位 置 。 


。 View 应 该 有 一 个 初始 界面 。 这 就 好 比 我 们 每 天 早上 睁 开 双 眼看 到 的 





第 一 个 画面 一 样 。 而 且 在 一 段 时 间 内 ， 第 一 个 画面 并 不 会 改变 。 就 
好 像 你 只 是 睁 开 了 双眼 ， 但 还 是 赖 在 床上 一 动不动 ， 那 么 你 看 到 的 
东西 多 半 是 不 变 的 。 当 然 ， 如 果 你 看 到 的 是 家 里 的 小 狗 ， 那 么 即便 
你 自己 不 动 ， 也 不 能 保证 它 摇 动 尾 巴 而 带 来 的 画面 更 新 〈 这 个 其 实 
类 似 于 View 中 动画 的 实现 原理 ) 。 大 家 可 以 再 体会 一 下 其 中 的 关 

系 





。 什么 情况 下 画面 会 动 ? 可 能 是 View 收 到 了 外 部 事件 触发 了 它 “ 动 的 


欲望 ”比如 用 户 拉 动 了 滚动 条 ， 或 者 收 到 了 外 部 硬件 事件 。 那 么 
在 响应 事件 的 同时 ， 很 可 能 就 会 更 新 画面 ) ; 当然 也 可 能 是 前 面 所 
说 的 “动画 ”机 制 从 内 部 产生 的 触发 事件 。 








。 S n eens, o ee 会 的 


AN 














最 终 cle alae 导 整个 过 程 。 
例 2: 


前 一 个 例子 我 们 通过 一 个 TextView 了 解 了 滚动 条 操作 的 处 理 过 程 。 
为 了 保持 连贯 性 ， 还 是 接着 上 面 的 图 例 进行 分 析 ， 如 图 11-31 所 示 。 


View) (LinearLayout) 


View! View? | View 
= 


LinearLayout 





全 图 11-31 View3 也 是 ViewGroup 的 情况 


假设 View3 不 再 是 TextView， 而 是 和 它 的 父 类 一 样 的 
LinearLayout (继承 自 ViewGroup) 。 它 包含 了 3 个 子 View (View4~ 
View6) 。 也 就 是 说 ， 这 棵 View 树 暂时 是 这 样 的 ， 如 图 11-32 所 示 。 


图 11-32 中 的 ViewTree 相 比例 子 1 又 复杂 了 点 ， 不 过 与 大 多 数 应 用 程 
序 中 真正 的 ViewTree 相 比 还 有 一 定 差异 。 换 句 话 说，ViewTree 拥 有 的 树 
叶 节 点 理论 上 是 没有 上 限 的 。 当 draw 阴 数 由 树 根 节点 〈 即 图 中 的 
ViewO) 逐步 往 下 递归 调用 时 ， 问 题 就 来 了 : 是 不 是 所 有 的 树叶 节点 都 


2 ile A Be ? 


ViewRootInp| 





全 图 11-32 例 2 中 的 View 树 


答案 是 “不 一 定 ”。 对 于 那些 珊 面 没有 任何 变化 的 View 对 象 ， 我 们 
没有 必要 浪费 资源 去 进行 重 绘 。 为 了 达到 这 一 目标 ， 就 要 求 View 的 父 对 


KR, WView2WFViewt~View3, MBView3ZFView4~Views, ALL 
格 把 控 住 整个 draw 流 程 。 我 们 在 进行 应 用 程序 开发 时 ， 尤 其 是 扩展 了 一 
个 View/ViewGroup 类 时 ， 也 需要 特别 注意 这 一 点 。 


接 下 来 我 们 以 lImageView 为 例 ， 来 分 析 onDraw 的 源 代 码 实现 : 


/*frameworks/base/core/java/android/widget/ImageView. java*/ 
protected void onDraw(Canvas canvas) { 
super .onDraw(canvas); 
if (mDrawable == null) {// 如 果 Drawable 为 空 ， 直 接 返 回 
return; // couldn't resolve the URI 


} 
if (mDrawablewidth == © || mDrawableHeight == 0) {//HDrav 
return; // nothing to draw (empty bounds) 


} 
if (mDrawMatrix == null && mPaddingTop == 0 && mPaddingLe 
mDrawable.draw(canvas); 
} else { 
int saveCount = canvas.getSaveCount()j; 
canvas ,Save();// 保 存 这 一 场景 ， 稍 后 还 要 恢复 
if (mCropToPadding) { 
final int scrollX = mScrollXx; 
final int scrollY = mScrolly; 
canvas.clipRect(scrollX + mPaddingLeft, scrollY + 
scrollX + mRight - mLeft - mPaddingRight, 
scrollY + mBottom - mTop - mPaddingBottom 











} 
canvas.translate(mPaddingLeft,，mPaddingTop);// 坐 标 变换 
if (mDrawMatrix != null) { 


canvas .concat(mDrawMatrix); 


mDrawable.draw(canvas); 
canvas.restoreToCount(saveCount );//}k# Canvas 


} 


首先 进行 合法 性 判断 ， 即 ImageView 必 须 持 有 一 个 尺寸 大 小 正常 的 
mDrawable， 和 否则 直接 返回 。 随 后 的 情况 分 为 两 种 : 


1. 不 需要 坐标 变换 的 情况 


也 就 是 说 同时 满足 mDrawMatrix == null && mPaddingTop == 0 && 
mPaddingLeft == 0。 


那么 这 是 最 简单 直接 的 一 种 场景 ， 我 们 只 要 调用 
mDrawable. draw (canvas) ， 由 Drawable 来 将 其 图 像 写 入 Canvas 中 即 可 。 


2. 需要 坐标 变换 的 情况 


只 要 mDrawMatrix、mPaddingTop 或 者 mPaddingLeft 有 任何 一 个 不 为 
空 ， 那 么 我 们 就 进入 第 二 种 情况 。 和 在 其 他 地 方 的 处 理 类 似 ， 此 时 要 先 
保存 Canvas 的 状态 ， 以 备 后 续 恢 复 。 


变量 mCropToPadding 可 以 由 android:cropToPadding 属 性 来 配置 ， 
代表 image 是 否 要 裁剪 以 适应 padding。 如 果 是 ， 进 行 相应 的 cl1ipRect 操 
作 。 


接着 ，Canvas 要 通过 坐标 变换 来 跳 过 padding 部 分 的 绘制 ， 即 
canvas. translate (mPaddingLeft, mPaddingTop) ;如 果 mDrawMatr ix 不 
为 空 ， 我 们 还 要 concat 这 一 部 分 已 经 存在 的 matrix。 最 后 ， 才 能 调用 
mDrawable. draw(canvas) 将 Drawable 中 的 内 容 绘 制 到 Canvas 上 。 经 过 上 
面 的 努力 ， 此 时 图 像 内 容 就 可 以 按照 要 求 “ 画 ”到 指定 的 位 置 上 了 。 


11.10 ” View 中 的 消息 传递 
在 项 目 开 发 过 程 中 ，View 中 的 消息 传递 流程 也 是 一 个 重点 和 难点 


onlnterceptTouchEvent, onTouchEvent, onClick, onLongClick 


等 一 系列 接口 方法 很 容易 让 人 混 清 。 


读者 可 以 先 试想 一 下 ， 对 于 一 棵 View 树 来 说 ， 它 的 消息 传递 应 该 是 
自 上 而 下 ， 即 从 根 节 点 开始 逐 层 往 子 类 递归 传递 的 。 在 消息 流转 过 程 
中 ， 一 旦 有 人 处 理 了 这 个 消息 ， 那 么 传递 即 可 宣告 中 止 《除非 有 特殊 需 
K) 。 从 这 一 点 来 看 ，View 树 的 上 层 拥有 消息 处 理 的 优先 权 。 


从 理论 的 角度 来 讲 ， 因 为 我 们 预先 并 不 知道 树 的 节点 是 View 还 是 
ViewGroup， 因 而 递归 过 程 中 所 调用 的 接口 必定 是 由 View 提 供 的 ， 然 后 
由 ViewGroup 来 重 载 。 


当前 Android 系 统 所 能 处 理 的 外 部 事件 基本 涵盖 了 市 面 上 常见 的 输 
入 设备 ， 如 触摸 屏 、 按 键 、 鼠 标 等 。 我 们 将 在 后 续 章 节 对 系统 的 输入 设 
备 管理 机 制 进行 详细 的 分 析 ， 而 本 小 节 的 重点 是 View 和 ViewGroup 内 部 
是 如 何 处 理 Input Events 的 。 为 了 使 讲解 更 具 针 对 性 ， 接 下 来 的 内 容 以 
TouchEvent 为 主 ， 并 分 别 从 View 和 ViewGroup 两 个 方面 来 剖析 问题 。 





11. 10. 1 View 中 TouchEvent 的 投递 流程 


”我们 先 概括 下 View 类 对 整个 输入 事件 的 处 理 流程 ， 如 图 11-33 所 
/小 。 
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全 图 11-33 View 类 的 事件 处 理 流 程 图 


ViewRootImpl ÆJelly Bean 几 个 版 本 中 改动 较 大 。 最 新 的 Android 
系统 中 ， 事 件 的 处 理 者 不 再 由 InputEventReceiver 独 自 承 担 ， 而 是 通过 
多 种 形式 的 InputStage 来 分 别处 理 ， 如 SyntheticlnputStage、 
ViewPost|lmelnputStage, NativePost!melnputStage, 
Earl1yPostlmelnputStage 等 。 这 些 1nputStage 都 重 载 了 一 个 接口 ， 即 
onProcess。 以 ViewPostlmelnputStage 为 例 : 


protected int onProcess(QueuedInputEvent q) { 
if (q.mEvent instanceof KeyEvent) { 
return processKeyEvent(q) ;// 按 键 事件 
} else { 
final int source = q.mEvent.getSource(); 
if ((source & InputDevice.SOURCE_CLASS POINTER) != 
return processPointerEvent(q); 


in 








4 


} else if ((source & InputDevice.SOURCE_CLASS_ TRACK 


return processTrackballEvent(q); 
} else { 





return processGenericMotionEvent(q);//Motion 事 件 


} 
} 
由 此 可 见 ， 当 系统 判断 出 当前 是 SOURCE_CLASS_POINTER 类 型 的 事件 
后 ， 将 调用 process PointerEvent 做 进一步 处 理 。 这 个 函数 会 把 这 一 处 
理 权 移交 给 View Tree 的 根 元 素 ， 即 myiew 的 dispatchPointerEvent 接 
口 ， 然 后 由 后 者 再 细 化 判断 。 
e 是 否 Touch Event 
是 的 话 就 调用 di spatchTouchEvent. 
e TIl] gè Æ Generic Motion Event 


此 时 调用 di spatchGener icMot ionEvent. 


从 名 称 就 可 以 看 出 来 ， 这 些 函 数 负责 “分 发 ”事件 ， 它 们 将 决定 
Event 的 后 续 流 问 : 


/*frameworks/base/core/java/android/view/View. java*/ 
public boolean dispatchTouchEvent(MotionEvent event) {... 
if (onFilterTouchEventForSecurity(event)) { 
ListenerInfo li = mListenerInfo; 
if (li != null && 1i.mOnTouchListener != null && (mVi 
== ENABLED&& 1i.mOnTouchListener.onTouch(th 
return true; 


if (onTouchEvent(event)) { 
return true; 
} 


} 


return false; 


} 


可 以 看 到 ，View 类 中 分 发 TouchEvent 还 是 比较 简单 的 ， 主 要 考虑 了 
以 下 两 个 因素 。 


e onTouch 


View 对 象 可 以 通过 set0nTouchLi stener 来 设置 一 个 Event 的 监听 
者 ， 这 样 当 事 件 来 临时 ，View 会 主动 调用 这 个 1istener 来 告知 对 方 。 从 
优先 级 来 看 ， 这 种 方式 较 下 面 的 onTouchEvent 先 行 处 理 。 





e onTouchEvent 


假如 用 户 没有 指定 TouchListener， 或 者 flags 中 指明 被 di sabled， 
又 或 者 onTouch 的 返回 值 为 false 〈 代 表 这 一 事件 没有 被 处 理 ) ， 那 么 系 


统 会 将 event 传 递 给 onTouchEvent。 


上 述 两 种 方式 都 是 我 们 在 应 用 开发 中 经 常 使 用 的 ， 它 们 各 有 特色 。 
其 中 onTouch 更 为 简捷 高 效 ， 而 后 者 则 更 适用 于 View 扩 展 类 的 情况 (ŒE 
载 onTouchEvent) 。 在 这 里 ，onTouchEvent 充 当 了 一 个 “内 政 处 理 
者 ”的 角色 。 源 码 如 下 (DERNE) : 


public boolean onTouchEvent(MotionEvent event) { 
final int viewFlags = mViewFlags; 
if ((viewFlags & ENABLED_MASK) == DISABLED) {// 当 前 View 被 d 
if (event.getAction() == MotionEvent.ACTION_UP && (mP 
setPressed(false); 


} 
return (((viewFlags & CLICKABLE) == CLICKABLE || 


(viewFlags & LONG_CLICKABLE) == LONG_CLICKABL 
} 


这 段 代 码 说 明 ， 即 便 在 View 被 disabled 的 情况 下 ， 它 同样 会 消耗 这 
个 事件 一 一 只 是 不 做 出 任何 回应 而 已 。 这 就 好 比 快递 一 样 ，“ 包 右 ” 已 
经 正确 传递 到 目的 地 ， 而 如 何 处 理 它 则 是 目标 自己 的 事情 了 一 一 它 甚 至 
可 以 选择 丢弃 “ 包 庄 ”， 但 前 提 是 必须 先 “签收 ”。 


如 果 View 没 有 被 di sabled， 那 么 接 下 来 程序 将 具体 处 理 这 一 Touch 
事件 。 我 们 知道 ， eee a a T 种 类 型 ， 即 
ACTION_UP, ACTION DOWN, ACTION _CANCELFHACTION MOVE. 


1. ACTION_DOWN 


按照 人 体 的 正常 操作 顺序 ， 触 摸 事 件 的 序列 流通 常 都 是 DOWNUP 或 者 
DOWNMOVE UP. 可 以 看 出 DOWN 是 后 续 事件 的 “起 点 ”， 所 以 它 通 常 在 程 
序 中 被 作为 一 种 特殊 的 标志 : 


case MotionEvent.ACTION DOWN: 
mHasPerformedLongPress = false;// 置 初 值 false 


setPressed(true) ;// 当 前 状态 变 为 Pressed 
checkForLongClick(0);// 检 查 是 否 常 按 
break; 


在 DOWN 事 件 的 处 理 中 ，setPressed 用 于 指示 View 对 象 是 否 要 进入 
Pressed 状 态 。 如 果 此 View 对 象 设计 了 不同 press 状 态 下 的 套 别 显示 Can 
Button 控 件 在 Pressed 与 Normal1 状 态 下 的 背景 图 片 通常 是 不 同 的 ) uk 
时 就 需要 刷新 U1， 具体 的 处 理 函 数 是 refreshDrawableState。 另外 当 收 
到 DOWN 事 件 后 ，View 就 开始 监测 它 会 不 会 演变 成 长 按 事件 。 可 以 通过 
ViewConf i guration. zetLongPressTimeout () REE 导 长 按 事件 的 产生 标 
准 ， 然 后 postDelayed 一 个 CheckForLongPress 的 Runnable。 在 Timeout 
后 〈 在 timeout 之 前 如 果 有 ACTION_UP 或 者 ACTION_MOVE 产 生 ， 会 通过 
removeLongPressCal lback 移 除 这 个 Runnable) 系统 就 需要 进行 长 按 事 
件 的 处 理 。 如 果 用 户 通过 set0nLongClickListener 设 置 了 响应 的 函数 ， 
那么 就 会 回调 这 些 子 数 。 


2. ACTION_MOVE 


当 手 势 按 下 后 (DOWN) 并 拖 动 ， 就 会 随后 产生 ACTION_MOVE 事 件 。 


这 个 事件 通常 不 止 一 个 ， 而 是 随 着 用 户 的 不 断 拖 动 持续 产生 ， 直 到 
ACTION_UP 或 者 ACTION_CANCEL: 


case MotionEvent.ACTION_MOVE: 
final int x = (int) event.getX();//MOVE 事 件 的 x 
final int y = (int) event.getY();//MOVE 事 件 的 y 
if (!pointInView(x, y, mTouchSlop)) {// 是 否 已 乡 
removeTapCallback(); 
if ((mPrivateFlags & PRESSED) != 0) { 
removeLongPressCallback(); 
setPressed( false) ;// 不 再 是 Pressed 状 态 





} 


break; 


上 面 这 段 代 码 中 ，pointlnView 用 于 判断 当前 的 手势 是 否 已 经 超出 
View 的 范围 。 如 果 回 答 是 肯定 ， 我 们 需要 移 除 包括 长 按 监测 在 内 的 一 系 
列 操作 ， 并 且 View 对 象 将 退出 Pressed 状 态 。 换 句 话说 ，ACTI10N_DOWN 事 
件 产生 的 高 显 状态 〈 如 果 有 的 话 ) 此 时 就 会 恢复 正常 。 


3. ACTION_UP 


ACTION_UP 是 手势 操作 的 结束 点 。 除 了 改变 View 的 一 系列 状态 外 ， 
它 的 另 一 个 重要 操作 就 是 判断 是 否 会 产生 Click， 即 开发 人 员 
set0nC1lick 所 要 响应 的 事件 。 当 然 ， 并 不 是 任何 ACTION_UP 都 对 应 一 个 
Click。 比 如 前 面 如 果 已 经 产生 了 长 按 事件 ; 或 者 当前 不 是 Pressed 状 态 
等 情况 下 都 会 阻碍 Cli ck 的 形成 : 


if (!mHasPerformedLongPress) { // 已 经 执行 过 长 按 ， 
removeLongPressCallback(); 
if (!focusTaken) { 
if (mPerformClick == null) { 
mPerformClick = new PerformClick() 





} 

if (!post(mPerformClick)) { 
performClick(); 

} 


Í 


需要 注意 的 是 ，performCli ck 并 不 会 马上 被 调用 执行 ， 而 是 先 通过 
post 排 队 的 方式 处 理 。 这 样 做 可 以 让 其 他 View 状 态 优先 得 到 更 新 处 理 ， 
以 保证 执行 Cli ck 操作 时 这 些 状 态 都 是 正确 的 。 


4. ACTION_CANCEL 


ACTION_CANCEL 比 较 特殊 ， 它 并 不 由 用 户主 动产 生 ， 而 是 系统 在 说 
慎 判 断后 得 出 的 结果 。 这 个 事件 说 明 当 前 的 手势 已 经 被 废弃 ， 后 续 不 会 
再 有 任何 与 该 手势 相关 联 的 事件 产生 。 开 发 人 员 可 以 把 它 看 成 手势 的 结 
束 标志 ， 类 似 于 ACTION_UP， 并 做 好 清理 工作 : 


case MotionEvent .ACTION_CANCEL: 
setPressed(false); 
removeTapCallback(); 

removeLongPressCallback(); 
break; 


总 的 来 说 ，View 类 的 onTouchEvent 处 理 远 辑 比较 简单 。 它 一 方面 对 

原始 Touch 事 件 进 行 了 直接 的 处 理 〈DOWN，MOVE，UP 等 ) ; aa 方面 对 

各 状态 组 合 而 产生 的 新 事件 〈 比 如 LongPress、 Click) 也 进行 相应 的 
派发 和 处 理 。 


11.10.2 ViewGoup 中 TouchEvent 的 投递 流程 


ViewGroup 与 View 在 eroi a 一 致 的 ， 如 图 11-34 所 
示 。 大 家 可 以 先 参考 前 一 小 节 的 详细 描述 


ViewGroup 因 为 涉及 对 子 对 象 的 处 理 ， 其 派发 流程 没有 View 那 么 简 
单 直 接 。 具 体 来 说 ， 它 重 载 了 di spatchTouchEvent， 对 View 提 供 的 派发 
机 制 进 行 了 重新 规划 : 


/*frameworks/base/core/java/android/view/ViewGroup. java*/ 
public boolean dispatchTouchEvent(MotionEvent ev) {... 
boolean handled = false;//event 是 否 被 处 理 
if (onFilterTouchEventForSecurity(ev)) { 
final int action = ev.getAction(); 
/*Step1， 判 断 是 否 DOWN 事 件 */ 
final int actionMasked = action & MotionEvent.ACTION_ 
if (actionMasked == MotionEvent.ACTION_DOWN) {//DOWN« 
cancelAndclearTouchTargets(ev);// 一 旦 收 到 DOWN， 先 清 | 
resetTouchState(); 

















t 


/*Step2. 检查 interception 的 情况 */ 
final boolean intercepted; 
if (actionMasked == MotionEvent.ACTION_DOWN|| mFirstT 





final boolean disallowIntercept = (mGroupFlags & F 
if (!disallowIntercept) { 
intercepted = <strong>onInterceptTouchEvent</ 
ev.setAction(action); // restore action in ca 
} else { 
intercepted = false;// 不 需要 拦截 





} 
} else { 

intercepted = true;// 继 续 拦 截 
} 


final boolean canceled = resetCancelNextUpFlag(this) 
|| actionMasked == MotionEvent .ACTION_CANCEL; 
final boolean split = (mGroupFlags & FLAG_SPLIT_MOTIO 
TouchTarget newTouchTarget = null; 
boolean alreadyDispatchedToNewTouchTarget = false; 
if (!canceled && !intercepted) {//Step3. 不 拦截 的 情况 
…// 代 码 稍 后 分 析 


} 
.…// 其 他 部 分 代码 和 上 面 是 类 似 的， 大 家 可 以 自行 分 析 
J 























return handled;// 返 回 处 理 结果 





} 
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全 图 11-34 ViewGroup 中 TouchEvent 的 处 理 


打 个 现实 中 的 比方 ， 我 们 从 深圳 寄 快 递 到 上 海 ， 中 途 很 可 能 经 过 若 
干 城市 。 那 么 当 茶 个 城市 收 到 这 个 快递 包 时 ， 它 首先 判断 要 不 要 把 包 诸 
拦截 下 来 ， 即 这 个 包 暑 是 不 是 要 由 自己 所 在 的 城市 进行 处 理 。 如 果 当 前 
城市 就 是 上 海 ， 那 么 包 诸 就 不 应 该 继续 往 下 传输 ， 继 而 进入 由 市 二 区 
CH) 一 街 一 门牌 号 等 的 “内 政 ” 环 节 中 (onTouchEvent) ; 而 如 果 当 
前 城市 是 除 上 海外 的 中 间 城 市 ， 则 在 收 到 快递 包 时 要 继续 往 下 一 个 城市 
运输 ， 否 则 就 会 出 现 传递 错误 的 情况 。 当 然 ， 不 排除 有 个 别人 私自 截留 





ae 不 管 这 种 行为 是 否 有 意 为 之 ， 都 很 可 能 导致 系统 bug 
y 现 。 


理解 了 拦截 的 概念 后 ， 再 来 分 析 上 面 的 源码 段 就 清晰 多 了 。 


Step1@dispatchTouchEvent。 前 面 说 过 ，DOWN 是 后 续 其 他 事件 流 
的 “领头 手 ”， 被 看 成 一 个 完整 事件 流程 的 起 点 。 所 以 一 旦 收 到 
ACTION_DOWN， 程 序 就 会 清理 以 前 的 状态 ， 即 
cancelAndClearTouchTargets 和 和 resetTouchState。 


Step2@dispatchTouchEvent。 变 量 intercepted 代 表 是 否 要 拦截 事 
件 。 判 断 标准 如 下 : 


e Case 1. actionMasked == MotionEvent.ACTION_DOWN | | 
mFirstTouchTarget != null 


如 果 是 DOWN 事 件 ， 或 者 mF irstTouchTarget 不 为 空 ， 那 么 又 分 为 两 
种 子 情况 。 


e Case 1.1 disallowIntercept 为 false 


也 就 是 说 ， 此 ViewGroup 人 允许 拦截 ， 此 时 就 可 以 进一步 调用 
intercepted = onInterceptTouch Event (ev) 来 由 后 者 判断 是 否 要 真正 
执行 拦截 了 。 这 样 做 的 目的 是 为 扩展 ViewGroup 类 提供 便利 一 一 它们 只 
需要 重 载 这 个 函数 就 能 改变 ViewGroup 的 Intercept 策 略 。 


e Case 1.2 disallowIntercept ¥ true 


说 明 ViewGroup 不 允许 拦截 ， 这 种 情况 下 当然 intercepted=false。 


。 Case 2. 如 果 这 不 是 DOWN 事 件 ， 而 且 在 之 前 的 判断 中 
mFirstTouchTargetW 2, Ab Aintercepted X true, #7 ViewGrouptt 7 
继续 拦截 事件 。 


在 这 一 系列 的 判断 中 ，ViewGroup 始 终 优先 考虑 拦截 的 可 能 性 。 通 
常情 况 下 ， 这 一 决定 权 会 落 在 onlnterceptTouchEvent 中 ， 因 而 在 编写 
这 个 函数 时 要 特别 小 心 。 


Step3@di spatchTouchEvent。 如 果 intercepted 为 false， 表 明 
ViewGroup 不 希望 拦截 这 一 消息 ， 因 而 它 的 子 对 象 将 有 机 会 来 处 理 它 。 
源 代码 如 下 : 


if (actionMasked == MotionEvent.ACTION_DOWN 
|| (split && actionMasked == MotionEvent.ACTI 
|| actionMasked == MotionEvent .ACTION_HOVER_M 


final int childrenCount = mChildrenCount;// 子 对 象 个 
if (newTouchTarget == null &&childrenCount != 0) 
final float x = ev.getX(actionIndex) ; 
final float y = ev.getY(actionIndex); 
final View[] children = mChildren; 


for (int i = childrenCount - 1; i >= 0; i--) 

// 循 环 碍 找 一 个 能 处 理 
final int childIndex = customOrder ? 

getChildDrawingOrder (child 

final View child = children[childIndex]; 

if (!canViewReceivePointerEvents(child) 
|| !isTransformedTouchPointInView( x 

continue;// 不 符合 要 求 ， 跳 过 

















} 
// 找 到 了 此 TouchEvent 的 归属 child 
newTouchTarget = getTouchTarget(child); 





if (dispatchTransformedTouchEvent(ev, fal 


break: // 确 实 完成 了 任务 ， 可 以 结束 循环 了 




















这 部 分 代码 段 的 核心 就 是 如 何 判 断 此 Touch 事 件 在 ViewGroup 众 多 子 
对 象 中 的 归属 。 换 句 话 说， 在 这 么 多 的 子 对 象 中 ，ViewGroup 采 取 什 么 
策略 才 是 公平 正确 的 。 一 个 “下 策 ” 就 是 把 事件 挨个 发 送 给 每 个 子 对 
象 ， 然 后 由 它们 自己 来 决定 是 否 要 接受 这 个 Touch Event。 这 有 点 像 广 
播 机 制 ， 缺 点 就 是 浪费 时 间 ， 而 且 加 重 了 View 本 身 的 任务 一 一 它 需 要 有 
能 力 预先 判断 这 一 事件 是 否 属于 自身 。 


执行 归属 判断 的 是 canViewRece ivePo interEvents 和 
isTransformedTouchPointlnView。 前 者 表示 这 个 chi1d 是 否 能 接收 
Pointer Events (包括 Touch Event) ; 后 者 则 是 计算 (x, y) 这 个 点 有 
没有 “ 落 在 ”此 chi1d 的 “管辖 ”范围 内 。 这 样 做 就 相对 公平 了 ， 冬 
承 “ 谁 的 辖区 谁 负责 ”的 观念 ， 而 且 对 于 不 符合 要 求 的 子 对 象 可 以 直接 
continue 跳 过 ， 从 而 节约 了 时 间 。 


如 果 找 到 了 事件 的 归属 者 ， 接 下 来 就 要 将 此 事件 投递 给 它 了 ， 实 现 
AA FzdispatchTransformed TouchEvent。 这 个 国 数 将 调用 chi 1d 的 
dispatchTouchEvent， 分 两 种 情况 : 如 果 这 个 子 对 象 是 View， 可 以 参考 
上 一 小 节 的 分 析 ; 否则 就 仍然 是 ViewGroup 中 的 dispatchTouchEvent。 
如 此 循环 往复 ， 直 到 事件 真正 被 处 理 。 


当然 ， 事 件 的 归属 者 并 不 一 定 就 是 最 终 事 件 的 处 理 者 。 打 个 比方 ， 
快递 包 上 的 地 址 写 错 了 。 于 是 虽然 正确 到 达 了 指定 的 地 点 ， 但 接收 方 不 
认 账 ， 而 返回 了 false。 此 时 包 右 还 需要 继续 流转 ， 以 寻求 真正 的 处 理 
者 。 


最 后 我 们 来 小 结 一 下 。ViewGroup 中 的 di spatchTouchEvent 比 View 
复杂 很 多 ， 因 为 它 不 仅 要 考虑 ViewGroup 本 身 的 处 理 ， 更 重要 的 是 要 保 
证 消息 能 在 整 棵 View Tree 中 得 到 正确 的 传递 。 从 这 个 角度 出 发 ， 我 们 
可 以 把 它 的 处 理 过 程 分 为 以 下 几 个 方面 来 理解 。 


。 消息 往 下 传递 的 时 机 


即 什么 情况 下 ViewGroup 可 以 直接 intercept 此 消息 ， 而 另外 一 些 情 
况 下 则 需要 把 消息 继续 传递 给 它 管 理 下 的 子 对 象 做 进一步 处 理 。 大 家 应 
该 已 经 想到 了 ， 起 决定 作用 的 就 是 onlnterceptTouch Event. Android 
系统 鼓励 大 家 在 继承 ViewGroup 时 只 重 载 on1nterceptTouchEvent， 而 不 
是 重 载 di spatchTouchEvent。 因 为 后 者 可 谓 所 有 ViewGroup 共 性 的 提 
取 ， 不 应 轻易 改变 ; 而 前 者 才 是 体现 每 个 ViewGroup 对 象 “基因 ”差异 


的 地 方 。 我 们 应 该 尽 可 能 地 复 用 已 经 成 熟 的 代码 ， 而 不 是 什么 事 都 “条 
历 杀 为 ”， 这 样 做 并 不 符合 软件 开发 的 理念 。 


当 on1lnterceptTouchEvent 返 回 false 时 ， 说 明 当 前 的 ViewGroup 并 
没有 截留 这 个 事件 ， 所 以 它 需 要 继续 往 下 传输 ， 直 到 有 人 接收 并 处 理 
它 ; 同时 ， 后 续 的 事件 还 会 源源 不 断 地 调用 on1lnterceptTouchEvent 进 
行 判断 。 


而 当 onlnterceptTouchEvent 返 回 true 时 ， 说 明 当 前 的 ViewGroup 需 
要 截留 这 个 事件 以 供 内 部 处 理 。 此 时 意味 着 这 个 事件 以 及 后 续 的 事件 直 
到 ACTION_UP 前 都 会 直接 投递 到 ViewGroup 的 onTouchEvent 中 ， 而 不 会 往 
下 传递 。 


处 理 人 逻辑 如 图 11-35 所 示 。 
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A 11-35 ViewGroup 中 触摸 消息 流 的 传递 简 图 
e ViewGroup Ë 身 对 消息 的 处 理 


ViewGroup 也 是 View 对 象 ， 所 以 它 同样 有 权 对 事件 进行 处 理 。 具 体 
的 实现 和 前 一 小 节 的 分 析 完 全 一 致 ， 读 者 可 以 结合 起 来 阅读 。 





11.11 _ View 动画 
Android 系 统 中 至 少 提供 了 如 下 几 种 类 型 的 动画 。 
e Property Animation 


这 是 从 Android 3. 0 起 才 导 入 的 一 种 新 的 动画 方式 ， 也 是 官方 推荐 
使 用 的 做 法 。 它 将 以 某 个 对 象 ， 甚 至 是 那些 并 不 在 屏幕 上 显示 的 对 象 的 
属性 为 动画 契机 。 因 而 突破 了 View 动 画 的 传统 限制 ， 极 大 地 扩展 了 原先 
动画 的 灵活 性 。 


e View Animation 


View Animation 也 是 我 们 在 开发 过 程 中 经 常 使 用 的 一 种 方法 。 虽 然 
它 只 提供 了 大 小 、 旋 转 、 透 明度 等 基础 属性 的 动画 效果 ， 但 已 经 足够 满 
足 一 般 的 开发 需求 。 建 议 读者 在 选择 具体 的 动画 方式 时 ， 要 根据 实际 的 
需求 来 选择 ， 而 不 是 越 “ 高 级 ” 越 好 。 


本 小 节 的 内 容 将 以 View Animation 为 分 析 重 点 。 
e Drawable Animation 


这 是 传统 的 动画 实现 方式 之 一 ， 即 通过 连续 放映 图 片 来 产生 动画 的 
效果 。 相 对 于 上 面 两 种 ， 它 的 优点 是 可 以 实现 任何 动画 而 且 效果 出 色 ; 
缺点 也 是 明显 的 ， 即 要 花费 一 定 的 人 力 物力 来 完成 动画 所 需 的 相关 图 
上 请， 而 且 应 用 程序 的 体积 也 会 因此 增 大 。 


e Window Animation 


这 是 系统 内 部 实现 的 一 种 动画 ， 目 的 在 于 加 强 窗口 切换 时 的 显示 效 
果 。 我 们 在 Window ManagerService 中 已 经 有 详细 介绍 。 

接 下 来 我 们 以 View Animation 为 例 来 分 析 View 动 画 的 实现 原理 。 实 
际 上 ， 不 管 是 什么 类 型 的 动画 ， 其 本 质 原 理 都 是 一 样 的 。 引 用 
Wikipedia 上 对 Animation 的 解释 ， 即 : 


Animation is the rapid display of a sequence of images to create 


也 就 是 说 ， 动 画 的 本 质 是 时 间 和 图 像 的 关系 。 比 如 一 个 滚动 的 小 

球 ， 在 0 秒 时 显示 的 是 位 移 为 Im 的 图 片 ; 而 到 了 1 秒 时 显示 的 是 位 移 为 2m 
HAA; 3 秒 时 显示 的 是 位 移 为 3m 的 图 片 等 。 在 这 一 过 程 中 ， 所 有 图 片 
都 是 静止 的 ， 它 们 通过 在 不 同 的 时 间 内 有 序 地 显示 出 来 从 而 造成 了 “ 动 
起 来 ”的 感觉 。 根 据 视觉 原理 ， 人 体 对 于 一 幅 图 的 “存储 上 时间” 是 0. 34 
秒 ， 因 而 只 要 以 特定 的 速率 来 切换 图 片 〈 根 据 人 们 的 反复 测试 经 验 ， 电 
影 一 般 选 取 24 帧 / 秒 ， 电 视 则 是 25 帧 / 秒 ) ， 人 眼 就 会 感觉 整个 画面 是 流 
畅 的 ， 没 有 卡 顿 现象 。 


从 上 面 的 分 析 可 以 得 出 实现 View Animation 的 重点 ， 如 下 所 述 。 
1. 从 开发 人 员 的 角度 来 讲 


对 于 开发 人 员 而 言 ， 他 们 所 关心 的 是 如 何 快速 地 将 所 需 的 动画 效果 
告知 系统 ， 然 后 通过 调用 尽量 少 的 函数 就 可 以 开始 执行 和 控制 动画 。 具 
体 来 说 ， 在 Android 系 统 中 实施 一 个 View 动 画 需要 以 下 几 个 步骤 。 


。 首先 需要 填写 xml 动 画 资源 文件 。 


和 其 他 类 别 的 资源 一 样 ， 我 们 也 可 以 通过 xml 来 描述 一 个 View 动 田 
资源 。 比 如 新 建 一 个 example_anim. xm1 到 res/anim/ 目 录 下 ， 然 后 根据 
以 下 格式 范例 来 生成 一 个 动画 效果 : 


<?xml version="1.0" encoding="utf-8"?> 
<set xmlns:android="http://schemas.android.com/apk/res/android" 
android: interpolator="@[ package: ]anim/interpolator_resource" 
android: shareInterpolator=["true" | "false"] > 
<alpha 
android: fromAlpha="float" 
android: toAlpha="float" /> 
<scale 
android: fromxScale="float" 
android: toxScale="float" 
android: fromyScale="float" 
android: toYScale="float" 
android: pivotxX="float" 
android: pivotY="float" /> 
<translate 
android: fromxDelta="fFloat" 
android: toxDelta="float" 
android: fromyDelta="float" 
android: toYDelta="float" /> 


<rotate 
android: fromDegrees="float" 
android: toDegrees="float" 
android: pivotxX="float" 
android: pivotY="float" /> 
<set> 


</set> 
</set> 


一 个 摘 述 动画 资源 的 xm| 文 件 必 须 以 alpha>，《scale>， 
<translate>, 《rotate> 或 者 《set> 为 根 节 点 ， 其 中 最 后 的 <set> 表 示 前 
面 四 种 类 别 的 组 合 ， 它 在 源码 中 的 实现 类 是 An imat ionSet。 这 5 个 元 素 
的 属性 和 释义 如 表 11-9 所 示 。 


表 11-9 ”动画 资源 各 属性 释义 


Animation 要 采用 的 
Interpolator， 下 面 我 们 会 讲 
= 


表示 动画 EA F 的 ca 0 
取 值 范围 0.0 GEH) ~ 
1.0 〈 不 透明 ) ，float 类 型 


表示 动画 结束 时 的 alpha 值 。 
取 值 范围 0.0 GEH) ~ 
1.0 〈 不 透明 ) ，float 类 型 


表示 动画 起 始 时 ，X 方 回 的 
android:fromXScale 缩放 倍数 ，float 类 型 ，1.0 为 
没有 变化 
表示 动画 结束 时 ，X 方 回 的 
android:toXScale 缩放 倍数 ，float 类 型 ，1.0 为 
没有 变化 
表示 动画 起 始 时 ，Y 方 回 的 
<scale> __ llandroid:fromY Scale 缩放 倍数 ，float 类 型 ，1.0 为 





没有 变化 


p o 





android:pivotX 缩放 中 心 点 的 X 坐 标 
android:pivotY 缩放 中 心 点 的 Y 坐 标 


android:toYScale i 
没 


移动 点 的 X 坐 标 起 始 值 ， 
六 是 绝对 数 











android:fromXDelta 

<translate> 
android:toX Delta 移动 点 的 X 坐 标 结束 值 
android:fromYDelta 移动 点 的 Y 坐 标 起 始 值 
android:toYDelta 移动 点 的 Y 坐 标 结 束 值 





i ARXA 
android:pivotX i 

边缘 ) 类 型 

i Ly YAR, JEA 
mvpiory En 


android:fromDegrees “| 旋转 度数 起 始 值 ，float 类 型 
android:toDegrees [EREE ATL, floa Hl 
1X A 
<rotate> 5 





除了 上 述 属性 外 ， 每 个 元 素 还 可 以 指定 android:duration， 也 就 是 
动画 执行 的 时 间 长 度 。 这 个 值 越 小 ， 则 动画 从 起 点 到 终点 所 用 的 时 间 就 


越 短 。 另 外 ，android: start0ffset 则 指明 动画 开始 前 的 延 时 时 间 





当 调 用 start 来 执行 动画 时 ， 有 时 候 我 们 希望 某 些 动画 效果 稍 慢 于 其 他 
一 些 动画 ， 这 时 就 可 以 采用 这 个 属性 。 默 认 情 况 下 ， 所 有 动画 一 开始 就 


执行 了 。 


可 见 ， 上 面 的 属性 多 数 只 是 描述 了 起 始 和 终点 时 动画 的 状态 ， 而 没 
有 给 出 中 间 过 程 的 变化 ， 完 成 这 一 任务 的 就 是 Interpolator 。 简 单 来 


讲 ， 它 给 出 了 动画 的 变化 速率 ， 种 类 非常 多 ， 如 匀速 运动 的 


Interpolator 和 抛物 线 运动 的 Interpolator 等 。 在 实现 上 ， 它 们 都 继承 


自 1nterpolator。 原 生 的 Android 系 统 本 身 已 经 提供 了 诸如 


AccelerateDeceleratelnterpolator, Acceleratelnterpolator, 
Anticipate lnterpolator，Linearlnterpolator 等 一 系列 常用 的 
Interpolator 。 开 发 者 可 以 通过 “@android:anim/ 
[Interpolator Name] ”来 引用 它们 。 比 如 : 


<set android:interpolator="@android:anim/ LinearInterpolator"> 


</set> 


另外 ， 我 们 还 可 以 通过 上 面 属 性 表格 中 的 android: interpolator% 
指定 一 个 自 定义 的 Interpolator 实 现 类 。 具 体例 子 可 以 参考 官方 文档 说 
明 。 


"o oe ee ml 描述 的 动画 资源 实际 上 给 出 了 以 
下 言 息 : 


有 几 个 动画 (rotate, scale, translate, alpha) 需要 执行 ; 
。 每 个 动画 的 起 始 和 最 终 效果 ; 

e 每 个 动画 的 起 始 时 间 和 延续 时 长 (duration) ; 

。 完成 每 个 动画 的 Interpolator。 


在 应 用 程序 中 使 用 一 个 xm1 动 画 资源 时 ， 通 常 可 以 这 么 做 : 


ImageView image = (ImageView) findViewById(R.id.image); 
Animation exampleAnim = AnimationUtils.loadAnimation(this, R.ani 
image.startAnimation(exampleAnim) ; 


余下 的 工作 就 由 系统 自动 完成 了 。 
2. 从 系统 实现 的 角度 来 讲 


当 应 用 程序 通过 1oadAn imat ion 加 载 一 个 xm1 动 画 资 源 文件 时 ， 返 回 
的 是 一 aa ears 不 过 大 部 分 情况 下 ， 它 其 实 是 
AnimationSet。 这 个 类 继承 自 Animation， 有 点 类 似 于 View 与 ViewGroup 
的 关系 。 每 一 个 An imat ion 都 属于 上 述 4 种 动画 (scale, rotates) 的 

其 中 一 种 ，AnimationSet 则 是 它们 的 集合 。 A mai one ti 有 一 
4smAnimat ionsBiArrayList 2 量 来 记录 它 包 含 的 所 有 动画 ， 如 图 11-36 
所 示 。 


| AntmationSet 


| 
loadAnimation 
| 
| 
| 


xml 





全 图 11-36 AnimationSet#eAnimation#y * A A 


i 下 面 为 了 简化 分 析 过 程 ， 我 们 还 是 以 Animation 来 表示 一 个 动画 主 


它们 的 继承 关系 如 图 11-37 所 示 。 


Animation 类 的 最 终 目 的 是 提供 getTransformation 接 口 实现 ， 这 个 
函数 将 返回 当前 时 间 点 的 Transformat ion 给 View 进 行 相应 处 理 。 熟 悉 图 
形变 换 的 开发 人 员 应 该 能 想到 ， 一 个 View 的 位 移 、 旋 转 、 缩 放 是 可 以 用 
matrix 来 表达 的 ， 那 么 为 什么 还 要 定义 一 个 Transformation 呢 ? 没 错 ， 
因为 还 有 Alpha 这 个 属性 是 matrix 所 不 能 表示 的 。 我 们 可 以 看 看 
Transformation 内 部 的 全 局 变量 : 


/*frameworks/base/core/java/android/view/animation/Transformation 
public class Transformation { 

protected Matrix mMatrix; 

protected float mAlpha; 


从 Animat ion 的 角度 来 看 ， 它 需要 计算 出 任何 时 间 点 的 
Transformation 值 。 如 果 只 是 匀速 运动 的 动画 ， 实 现 相 对 简单 。 而 如 果 
是 非 匀 速 运动 呢 ? 这 些 烦 琐 的 计算 实际 上 是 一 个 个 数学 模型 ， 我 们 统一 


用 Interpolator 来 实现 。 


+gefTransformation( 





TranslateAnimation BotateAnimation 
toetTranstormation() |  |+eetTranstormation() 





| 





fi ti 
getTransformation() | — |tgetTransformation() 


全 图 11-37 Animation 继承 关系 图 
下 面 举 两 个 动画 实例 来 进一步 理解 Interpolator。 
例 1: AlphaAnimation， 初 始 条 件 如 下 。 


e Alpha 起 始 值 : 0.0， 终 值 : 1.0. 
。 动画 时 长 : 28， 起 始 时 间 : 1s， 即 动画 起 止 时 间 是 1~3s。 


e 采用 LinearInterpolator。 


Interpolator 本 身 只 是 一 个 接口 类 ， 所 有 继承 它 的 子 类 都 要 实现 
getlnterpolation (float input) 。 其 中 input 是 唯一 的 入 参 ， 表 示 当 前 
时 间 点 在 整个 动画 时 长 中 对 应 的 位 置 〈 以 0. 0-1. 0 表示 ， 也 就 是 实现 了 
归 一 化 ) 。 在 这 个 例子 中 ， 如 果 当 前 时 间 是 2s， 那 么 input= (当前 时 间 - 
起 始 时 间 ) / (动画 时 长 ) = (2-1) /2=0.5。 由 于 是 匀速 运动 ， 速 度 在 任何 时 
间 点 都 是 恒定 不 变 的 ， 所 以 getlnterpolation 的 返回 值 即 input 本 身 : 


public class LinearInterpolator implements Interpolator { 


public float getInterpolation(float input) { 
return input; 
} 


得 到 这 个 返回 值 后 ，Animation 可 以 计算 出 Transformat ion: 


/*frameworks/base/core/java/android/view/animation/AlphaAnim 
protected void applyTransformation(float interpolatedTime, T 
final float alpha = mFromAlpha; 


t.setAlpha(alpha + ((mToAlpha - alpha) * interpolatedTi 
} 


可 见 在 Linear 1nterpolator 的 情况 下 ， 动 画 的 计算 过 程 比 较 简 单 明 
er 


例 2: 采用 Acceleratelnterpolator， 其 他 条 件 则 和 例 1 相 同 。 


现在 情况 有 了 变化 ， 即 速度 v 不 再 是 恒定 不 变 的 。 我 们 假设 加 速度 
不 变 ， 恒 定 为 v=t， 如 图 11-38 所 示 。 


例 2. 加 速度 v=t 





全 图 11-38 两 个 例子 中 的 速度 对 比 


因为 s=vt=t#t， 意 味 着 随 着 时 间 的 增加 ，s 值 的 增长 会 越 来 越 快 : 


/*frameworks/base/core/java/android/view/animation/AccelerateInte 
public float getInterpolation(float input) { 
if (mFactor == 1.0f) { 
return input * input; 
} else { 
return (float)Math.pow(input, mDoubleFactor); 


} 
从 上 面 两 个 例子 的 分 析 中 ， 我 们 可 以 得 出 两 个 结论 。 


e Intetpolatot 得 到 的 是 当前 时 间 点 ， 动 画 变换 值 在 整个 变换 中 的 位 
置 。 

e getIntetpolation 的 返回 值 范 围 是 0.0 一 1.0， 且 任何 Interpolatot 在 input 
为 1 时 ， 输 出 一 定 为 1.0。 


到 目前 为 止 ， 我 们 理解 的 动画 实现 可 以 抽象 成 图 11-39。 






全 图 11-39 动画 实现 简 图 


Animation 通 过 解析 xml 文 件 得 到 用 户 希望 产生 的 动画 效果 ， 并 进行 


初始 化 。 然 后 在 Interpolator 的 约束 下 不 断 地 与 View 进 行 交 互 
(Transformation) ， 从 而 产生 动画 过 程 。“ 不 断 地 ”表明 必须 要 有 一 
个 机 制 来 促使 这 一 流程 源源 不 断 地 运转 ， 直 到 动画 结束 。 一 般 情况 下 ， 
我 们 会 想到 启动 一 个 timer 来 达到 这 种 目的 。 基 于 这 点 考虑 ， 上 面 的 简 
图 还 应 该 包括 如 下 几 个 元 素 。 


o FY IB] ae 


时 间 器 从 动画 一 开始 就 要 启动 ， 直 到 动画 结束 ; 同时 ， 它 也 负责 对 
动画 刷新 频率 的 管理 。 换 句 话说 ， 每 隔 多 长 时 间 发 出 一 次 刷新 信号 对 于 
画面 的 连贯 性 有 不 小 的 影响 。 


。 效 果 计算 只 


当时 间 器 发 出 信号 后 ， 我 们 需要 知道 在 当前 的 时 间 点 ， 应 该 “ 描 
绘 ” 一 幅 怎 样 的 “画面 ”。 比 如 滚动 中 的 小 球 ， 以 1m/s 的 速度 移动 时 ， 
那么 2 秒 后 的 “画面 ”应 该 显示 它 已 经 移动 了 2 米 。 当 然 实 际 的 动画 计算 
肯定 比 这 个 例子 复杂 ， 如 还 要 综合 考虑 旋转 、 大 小 等 的 变化 。 


o 效果 计算 器 输出 的 内 容 如 何 体 现 到 UI 中 


前 面 的 时 间 器 、 效 果 计 算 器 ， 在 Android 系 统 中 都 是 由 Animat ion 类 
来 完成 的 。 那 么 当 Animat ion 计 算出 在 某 个 时 间 点 应 该 产生 什么 图 像 
时 ， 如 何 把 这 些 结果 告知 系统 呢 ? 这 就 涉及 An imat ion 与 View 的 接口 
了 ， 如 图 11-40 所 示 。 


Animation 


vet Transformation 


onAnimationStart | | onAnmationRepeat | 


| 
| 
| 
onAnimationEnd | 





全 图 11-40 View Animation ja] 49 # 7 


图 11-40 的 确 是 一 个 有 效 的 Animation 实 现 方案 。 不 过 在 Android 
中 ， 我 们 却 没有 从 Animation 类 中 发 现 Timer 的 踩 迹 ， 而 且 
AnimationListener 也 没有 提供 Transformation 的 回调 。 那么 ，View 是 
如 何 使 整个 动画 流程 “ 动 ”起 来 的 呢 ? 答案 就 是 View 会 主动 调用 
Animat ion 进 行 查 询 ， 上 换 句 话说 ， 何 时 去 获取 当 
前 的 “动画 状态 ”是 View 的 责任 与 权利 ， 和 Animat ion 并 没有 关系 。 如 
此 一 来 ， 问 题 就 转换 成 : View 在 什么 情况 下 会 去 “不 断 地 ”调用 


getTransformat ionHe ? 


前 面 代 码 中 调用 startAnimation 后 ， 其 内 部 最 后 会 调用 


invalidate: 
public void startAnimation(Animation animation) { 


invalidate(true); 


这 样 就 发 起 了 一 次 重 绘 请 求 ， 并 在 后 续 过 程 中 处 理 与 Animat ion 相 
关 的 操作 。 详 细 过 ‘Bape Rea EGA 2B, Ab AN RBS 


11.12 UiAutomator 


相信 大 家 对 UiAutomator 并 不 陌生 ， 这 个 Android 官 方 提供 的 自动 化 
测试 框架 具有 非常 强大 的 功能 ， 是 我 们 测试 应 用 程序 的 百 选 工具 之 一 。 
与 jnstrumentat ion 不 同 的 是 ，UiAutomator 并 不 与 被 测 程序 运行 于 同一 
进程 中 ， 因 而 它 可 以 实现 跨 进 程 的 测试 。 比 如 你 可 以 利用 UiAutomator 
获取 到 当前 设备 中 正在 显示 的 页 面 中 的 元 素 ， 然 后 对 它们 进行 各 种 操 
作 ; 也 可 以 要 求 设备 返回 桌面 ， 或 者 执行 Back 命 令 。 


UiAutomator 的 强大 功能 是 如 何 实现 的 呢 ? 


事实 上 ，UiAutomator 只 是 一 个 “ 壳 ”， 它 真正 倚赖 的 法 宝 是 如 下 3 
AE rE 
人 模块: 


e UiAutomation 


UiAutomat ion 并 非 Google 的 专利 ， 业 珊 其 他 公司 (Z2aApple) 亦 
有 与 之 同名 的 测试 框架 。 从 出 现时 间 上 来 推测 ，Android 中 的 
UiAutomat ion 很 可 能 是 Google“ 仿 照 ” 出 来 的 。 当 然 ， 站 在 巨人 的 肩膀 
上 本 身 并 非 坏 事 ， 更 何况 是 “造福 众人 ”的 开源 项 目 。 


e Accessibility Service 


乍 看 这 个 Service， 可 能 不 少 人 会 觉得 奇怪 ， 它 们 之 间 怎 么 会 有 关 
联 一 一 UiAutomator 和 Accessibility Service 似 乎 “ 八 杆子 都 打 不 
着 ”? 但 再 细 想 一 下 ， 就 不 难 发 现 它们 的 任务 是 有 共同 点 的 。 
Accessibility Service 旨 在 帮助 那些 有 有 某 些 方面 缺陷 的 人 士 可 以 像 正 
常人 一 样 使 用 Android 设 备 ， 璧 如 Accessibility Service 可 以 通过 语音 
告知 盲人 用 户 当 前 的 设备 珊 面 ， 以 便 后 者 在 知悉 了 这 些 信息 后 可 以 再 利 
用 语音 命令 来 发 出 表面 的 控制 命令 。 在 这 一 过 程 中 ，Accessibility 
Service 获 取 青 面 元 素 以 及 它 控制 弄 面 的 能 力 又 恰恰 是 UiAutomator 所 需 
要 的 。 因 而 二 者 可 以 说 是 “一 拍 即 合 ”。 


e ViewRoot 


Accessibility Service 绝 对 不 是 “ 神 ”， 它 的 权利 最 终 是 
ViewRoot 赋 予 的 。 这 也 是 为 什么 我 们 选择 将 UiAutomator 的 原理 在 本 章 


TET HAA RAZ — o 


如 果 大 家 对 于 UiAutomator 测 试用 例 的 书写 ， 以 及 它 的 基本 使 用 方 
法 有 不 清楚 的 地 方 ， 建 议 可 以 先 到 Android 官 网 查询 相关 资料 ， 限 于 篇 
幅 我 们 这 里 不 做 详细 介绍 。 接 下 来 我 们 的 重点 是 前述 UiAutomator 的 核 
心 实现 原理 。 


首先 ， 从 “adb shell uiautomator runtest… ”这 种 命令 格式 中 
不 难看 出 ，UiAutomator 会 是 /system/bin 下 的 一 个 可 执行 程序 。 而 且 这 
个 可 执行 程序 只 是 一 个 shel1 脚 本 文件 ， 源 码 路 径 
在 /frameworks/testing/ uiautomator/cmds/uiautomator 下 。 值 得 一 
提 的 是 ，Android 系 统 中 类 似 的 做 法 还 有 不 少 ， 比 如 pm、am 等 。 


程序 UiAutomator 支持 的 几 个 主要 命令 包括 runtest、dump 和 events 
等 。 其 中 runtest 用 于 执行 开发 者 提供 的 UiAutomator 测 试用 例 ，dump 则 
是 sdk 工 具 包 中 uiautomatorviewer 的 功能 承载 者 。 最 终 ，UiAutomator 
会 调用 如 下 的 语句 来 执行 真正 的 操作 : 


exec app_process ${base}/bin com.android.commands.uiautomator.Lau 


app_process 同 样 是 /system/bin 目 录 下 的 一 个 可 执行 文件 ， 它 同时 
也 是 Zygote 的 承载 体 ， 其 本 质 上 就 是 帮助 用 户 快速 束 建立 一 个 Android 虚 
拟 机 ， 以 便 Java 程 序 可 以 顺利 运行 。 


UiAutomator Launcher 会 根据 子 命令 的 不 同 ， ee 
类 进行 处 理 。 例 如 runtest 命 令 elie R java 中 被 解析 ， 有 具 
体 而 言 它 会 先 创建 一 个 UiAutomatorTestRunner， 然 后 开始 执行 测试 用 
例 : 


/*frameworks/testing/uiautomator/library/testrunner-src/com/andro 
protected void start() { 


UiAutomationShellWrapper automationWrapper = new UiAutoma 
automationWrapper.connect(); 


上 述 的 start 函 数 是 testrunner 执 行 测试 任务 的 核心 之 一 。 不 过 我 
们 据 弃 掉 了 其 他 琐碎 部 分 ， 只 把 焦点 放 在 了 如 何 与 UiAutomat ion 建 立 连 
接 上 。UiAutomationShel1Wrapper 即 是 testrunner 与 UiAutomation 之 则 


的 桥梁 ， 如 下 所 示 : 


/*frameworks/testing/uiautomator/library/testrunner-src/com/andro 
public void connect() 4.. 
mUiAutomation = new UiAutomation(mHandlerThread.getLooper 
new UiAutomationConnection()); 
mUiAutomation.connect(); 





可 以 看 到 UiAutomation 出 场 了 ， 同 样 也 是 调用 了 connect 函 数 
而 这 个 connect 又 最 终 调 用 了 UiAutomat i onConnect ion PAYA ey AX. 
如 下 所 示 : 


/*frameworks/base/core/java/android/app/UiAutomationConnection.ja 
public void connect(IAccessibilityServiceClient client) { 


registerUiTestAutomationServiceLocked(client) ; 
storeRotationStateLocked(); 


} 


简单 来 讲 ， 涵 数 registerUiTestAutomationServiceLocked 将 在 
UiAutomat ion 内 部 建立 一 个 IAccessibilityServiceClient 和 
AccessibilityService 之 间 的 连接 。 为 了 让 大 家 更 好 地 理解 
Accessibility 书 馆 Service 的 业务 流程 ， 我 们 接 下 来 选取 “获取 当前 珊 
面 的 U1 元 素 ” 这 一 场景 来 分 析 其 中 的 实现 原理 。 


我 们 知道 ，UiAutomator 提 供 了 如 表 11-10 所 示 的 AP1 类 来 帮助 开发 
者 完成 测试 用 例 的 编写 。 


表 11-10 AP 工 类 


Classes Description 





com.android.uiautomator.core.UiCollectionl| 用 户 界 面 元 素 的 集合 





提供 了 访问 设备 信息 
的 接口 ， 以 及 模拟 用 
户 操作 〈 辟 如 单 击 


com.android.uiautomator.core.UiDevice 
Home、Menu 键 等 ) 


| | 的 方法 | 
com.android.uiautomator.core.UiObject “代表 一 个 UI 元 素 


了 IN YS >. £ 
com.android.uiautomator.core.UiScrollable 中 . 的 





用 于 描述 需要 被 测试 


com.android.uiautomator.core.UiSelector S 
的 目标 





其 中 UiSelector 可 以 通过 文本 值 、class _ name 以 及 其 他 多 种 属性 来 
匹配 当前 界面 中 与 之 对 应 的 Ui0b ject。 以 U1 元 素 的 index 属 性 为 例 ， 我 
们 来 看 一 下 它 是 如 何 查 找到 正确 的 目标 对 象 的 : 


/*frameworks/testing/uiautomator/library/core-src/com/android/uia 
UiSelector.java*/ 
public UiSelector index(final int index) { 
return buildSelector(SELECTOR_INDEX, index); 
} 


可 见 上 述 函 数 直 接 调 用 了 bui ldSelector 。 其 中 SELECTOR_1NDEX 代 
表 的 是 U1 元 素 的 属性 ， 其 他 的 还 有 SELECTOR _CLASS、SELECTOR_1D 等 。 


/* frameworks/testing/uiautomator/library/core-src/com/android/ui 
UiSelector.java */ 
private UiSelector buildSelector(int selectorId, Object selectorv 
UiSelector selector = new UiSelector(this); 
if (selectorId == SELECTOR_CHILD || selectorId == SELECTO 
selector.getLastSubSelector().mSelectorAttributes.put 
else 
selector.mSelectorAttributes.put(selectorId, selector 
return selector; 


} 


到 目前 为 止 ， 对 于 UiSelector 的 操作 都 属于 UiAutomator “本 
地 ”， 换 句 话 说 它 并 未 与 Accessibility Service 发 生 任何 实质 关联 ， 
更 多 地 只 是 在 内 部 “做 了 个 记号 ， 以 备 后 用 ”。 这 样 一 来 ， 查 找 目标 对 


象 的 工作 自然 而 然 地 就 落 在 了 Ui0bject 上 。 以 对 一 个 目标 控件 执行 
Click 操 作为 例 ， 对 应 的 代码 如 下 : 


/* frameworks/testing/uiautomator/library/core-src/com/android/ui 
UiObject.java*/ 
public boolean click() throws UiObjectNotFoundException { 
Tracer.trace(); 
AccessibilityNodeInfo node = findAccessibilityNodeInfo(mC 


J 


可 以 看 到 Ui0bject 在 每 执行 一 个 操作 前 ， 都 会 利用 
findAccessibilityNodelnfo 来 查找 匹配 的 对 象 。 后 面 这 个 函数 最 终 又 
会 利用 
UiDevice. getlnstance (). getAutomatorBr idge (). getQueryControl ler 
findAccessibi | ityNodel nfo (getSelector ()) 来 完成 它 的 任务 。 
UiDevice 中 的 AutomatorBr i de Æ FAUi Automator TestRunner 4 StartAy i 
过 initialize 初 始 化 而 来 的 ， 对 应 的 是 一 个 She11UiAutomator 
Bridge。 我 们 省 略 其 中 的 细 校 末节 ， 直 接 分 析 QueryController 中 的 对 
应 实现 : 


/* frameworks/testing/uiautomator/library/core-src/com/android/ui 
Controller.java*/ 
protected AccessibilityNodeInfo findAccessibilityNodeInfo(UiSele 
boolean isCounting) { ... 
synchronized (mLock) { 
AccessibilityNodeInfo rootNode = getRootNode(); 


UiSelector uiSelector = new UiSelector (selector); 
return translateCompoundSelector(uiSelector, rootNode 


J 


上 述 这 个 函数 的 核心 重点 是 getRootNode， 它 用 于 获取 当前 活跃 窗 
口 的 最 顶层 元 素 ， 而 UiSelector 所 指定 的 具体 元 素 〈 如 我 们 这 个 场景 
通过 index 属 性 来 查找 的 目标 对 象 ) 则 需要 在 此 基础 上 运算 得 到 。 函数 
getRootNode 的 实现 如 下 : 


/* frameworks/testing/uiautomator/library/core-src/com/android/ui 
Controller.java*/ 
protected AccessibilityNodeInfo getRootNode() { 

final int maxRetry = 4; 

final long waitInterval = 250; 


AccessibilityNodeInfo rootNode = null; 
for(int x = 0; x < maxRetry; x++) { 
rootNode = mUiAutomatorBridge.getRootInActiveWindow( ) 
if (rootNode != null) { 
return rootNode; 
} 


i, 


return rootNode; 


可 以 看 到 ， 获 取 活 跃 窗口 的 顶层 元 素 并 不 是 能 一 次 性 成 功 的 ， 因 而 
我 们 设置 了 4 次 重 试 机 会 。 变 量 mUiAutomatorBr idge 是 对 于 
UiAutomat ion 的 桥接 ， 后 者 又 调用 了 AccessibilitylnteractionClient 
提供 的 getRoot1nActiveWindow(connection1d) 来 最 终 完 成 与 
AccessibilityManagerService 的 通信 。 


这 个 过 程 中 所 涉及 的 类 比较 多 ， 容 易 搞 混 ， 我 们 特别 以 如 下 UML 示 
例 图 来 帮助 大 家 理解 ， 如 图 11-41 所 示 。 








lAccessibilityServiceClientlmpl 









= (JAulomation 


HAccessibilityServiceClient mClient 


-iAutomationConnection mUiAutomationConnection 





UAutomationConnection 





AcoesstbilitylnteractionClient 





toetRootlaActiveWindowint connectionld)) connection eR 


UiAwtomation 中 的 
mUrAoutomationConnection 
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全 图 11-41 UML 示 例 图 


所 以 一 个 UiAutomator 测 试用 例 的 大 致 执行 流程 是 


UiOb ject/UiDevice/UiSelector—>QueryControl ler- 
>Ui Automator Br idge—>Ui Automat i on—>***—> 
Accessibi | ityManagerService->***- 
>Vi ewRoot/WindowManagerService/|InputManager o 


因为 AccessibilityManagerService 是 一 个 “中 介 ”， 其 所 涉及 的 
业务 范围 是 比较 广泛 的 。 比 如 为 了 获取 当前 系统 中 的 所 有 可 见 窗口 
(getWindows 接 口 ) ， 它 需要 与 WindowManagerService 有 交流 ; 而 为 了 
控制 输入 法 操作 ， 它 也 应 该 和 lnputManager 有 关联 ; 同样 为 了 获得 一 个 
窗口 中 的 U1 控件 ， 它 还 必须 与 ViewRoot 建 立 合作 关系 等 。 


以 getRoot1nActiveWindow 为 例 ， 其 最 终 会 调用 ViewRootlmp1 中 的 
findAccessibility NodelnfoByAccessibility1d， 而 后 经 过 多 次 中 转 
传递 后 再 由 AccessibilitylnteractionController 进 行 处 理 : 


/*frameworks/base/core/java/android/view/AccessibilityInteraction 

private void findAccessibilityNodeInfoByAccessibilityIdUiThread(M 
List<AccessibilityNodeInfo> infos = mTempAccessibilityNod 
infos.clear(); 


try { 
if (mViewRootImpl.mView == null || mViewRootImpl.mAtt 
return; 
F 


mViewRootImpl.mAttachInfo.mAccessibilityFetchFlags = 
View root = null; 
if (accessibilityViewId == AccessibilityNodeInfo.UNDE 
root = mViewRootImpl.mView; 
} else { 
root = findViewByAccessibilityId(accessibilityVie 


} 
if (root != null && isShown(root)) { 
mPrefetcher.prefetchAccessibilityNodeInfos(root, 


} 
} finally { 

try {... 
adjustIsVisibleToUserIfNeeded(infos, interactiveR 
callback.setFindAccessibilityNodeInfosResult (info 
infos.clear(); 

} catch (RemoteException re) { 
/* ignore - the other side will time out */ 

} 


假如 当前 ViewRoot 中 的 顶层 元 素 〈 即 mView) 为 空 ， 那 么 我 们 就 可 
以 直接 返回 了 。 否 则 再 根据 用 户 是 否 指 定 了 Accessibi1ityViewld 来 决 
定 下 一 步 操作 一 一 如 车 没有 特别 说 明 ， 那 么 mView 就 是 结果 值 了， 不 然 
还 得 调用 findViewByAccessibility1d 来 做 进一步 查找 。 最 后 ， 我 们 将 
结果 通过 1AccessibilitylnteractionConnectionCallback 这 个 事先 注 
册 的 回调 接口 来 传 回 给 用 户 。 


值得 一 提 的 是 ，AccessibilityService 一 方面 给 特定 用 户 带 来 了 不 
小 的 便利 ， 另 一 方面 也 可 能 会 被 用 来 完成 一 些 “ 意 料 之 外 ”的 事情 。 比 
如 迅速 走红 的 “ 抢 红 包 ” 神 器 实际 上 就 是 利用 了 辅助 服务 来 帮助 用 户 自 
动 打开 红包 的 。“ 水 可 载 舟 ， 亦 可 履 舟 ”， 事 物 通 常 具 有 两 面 性 ， 需 要 
大 家 自行 甄别 权衡 。 





“AAS suit, JAEK AKR” —— 
InputManagerService 与 输入 事件 


在 大 多 数 现代 操作 系统 中 ，“ 事 件 ” 束 是 它们 的 “活水 源头 ”。 正 
m a a 
能 “zh” 来 。 


Android 系 统 有 一 套 从 底层 Linux 内 核 到 上 层 应 用 程序 完整 的 消息 产 
生 、 投 递 及 处 理 机 制 一 一 这 同时 也 是 外 宽 与 Android 设 备 交 互 的 基础 。 
对 于 系统 层 的 开发 人 员 而 言 ， 他 们 经 常 要 根据 具体 的 硬件 配置 来 扩展 、 
ERT Neri) ea en i ee 


同样 ， 我 们 也 希望 应 用 开发 工程 师 能 熟练 掌握 Android 消 息 处 理 框 
染 。Android 系 统 发 展 到 今天 ， 已 经 在 手持 设备 之 外 的 很 多 领域 得 到 了 
广泛 的 应 用 。 而 不 同 的 产品 领域 通常 意味 着 环境 与 需求 的 差异 。 应 用 工 
程 师 只 有 在 理解 内 部 原理 的 基础 上 ， 才 可 能 在 多 样 的 需求 中 立 于 不 败 之 
地 ， 也 才能 为 用 户 提供 最 佳 的 体验 效果 。 


因此 ， 本 章 的 内 容 不 论 对 哪 一 层面 的 开发 人 员 来 说 ， 都 具有 一 定 的 
实用 价值 。 另 外 ， 建 议 读 者 把 本 章 与 上 一 章节 介绍 的 “View 中 的 消息 传 
递 ” 结 合 起 来 阅读 理解 。 


12.1 事件 的 分 类 
首先 应 该 明白 一 个 问题 一 一 什么 是 “事件 ”? 


从 广义 上 来 说 ， 事 件 的 发 生源 分 为 “软件 ”与 “硬件 ”两 类 ， 这 里 
侧重 于 对 后 者 的 讨论 。 也 就 是 说 ， 它 们 是 由 真实 物理 硬件 产生 的 消息 ， 
表明 设备 使 用 者 的 某 种 “意愿 ”。 例 如 用 户 点 击 了 触摸 屏 ， 而 相应 位 置 
上 是 音乐 播放 怖 的 “ 暂 俘 ” 键 ， 那 么 说 明 他 希望 暂停 当前 的 音乐 播放 。 
如 果 从 硬件 设备 角度 来 为 Android 系 统 中 的 事件 分 类 ， 最 重要 的 几 种 如 
下 。 


。 按键 事件 (KeyEvent) 


由 物理 按键 产生 的 事件 。 对 于 贬 入 式 设备 ， 通 常 不 会 配备 太 多 物理 
按键 。 比 如 手机 一 般 只 有 Home、Back、Menu、Volume Up, Volume Down 
和 Camera 等 常用 功能 键 。 


e。 触摸 事件 (TouchEvent) 


在 触摸 屏 上 点 击 、 拖 动 ， 以 及 由 它们 的 组 合 所 产生 的 各 种 事件 。 这 
是 Android 系 统 中 使 用 最 广泛 也 是 相对 复杂 的 一 种 事件 类 型 。 根 据 
Android 项 目 经 验 ， 应 用 开发 人 员 大 部 分 的 事件 处 理工 作 都 和 
TouchEvent 有 关 。 





。 鼠标 事件 (MouseEvent) 
鼠标 操作 引起 的 事件 ， 在 人 散 入 式 设 备 中 并 不 常用 。 
。 轨 迹 球 事件 (TrackBallEvent) 
轨迹 球 基本 已 经 被 淘汰 了 ， 因 而 我 们 在 本 章 中 不 做 过 多 介绍 。 
本 章 接 下 来 将 重点 分 析 两 种 事件 类 型 ， 即 KeyEvent 和 TouchEvent。 


读者 可 以 先 思 考 一 下 : 如 果 让 我 们 来 为 这 两 种 事件 设计 处 理 函数 ， 
应 该 怎么 做 呢 ? 


按键 事件 : 


按键 有 几 种 状态 ? 没 错 ， 理 论 上 只 有 两 个 一 一 要 么 按 下 ， 要 么 松 
开 ， 即 对 应 于 KeyDown 和 KeyUp。 不 过 实际 上 却 没 那么 简单 ， 为 什么 呢 ? 
因为 还 有 其 他 一 些 因 素 也 是 要 考虑 的 ， 如 长 按 、 短 按 ， 或 者 按键 组 合 
《多 个 按键 ) 的 情况 。 比 如 我 们 在 Wi ndows 操 作 系 统 中 同时 按 
ctr1+Alt+De1 组 合 键 可 以 调 出 任务 管理 器 ，Android 系 统 也 同样 支持 这 
些 操作 。 


所 以 总 结 起 来 ， 影 响 一 个 按键 事件 的 因素 包括 : 
。 按键 的 状态 ( 按 下 ， 松 开 ) ; 


。 状态 持续 的 长 短 ; 
。 按键 数量 。 


由 此 可 以 得 出 处 理 按键 事件 的 几 个 基础 接口 ， 如 下 所 示 。 


OnKeyDown(); 
onkeyUp(); 
onKeyLongPress(); 
onKeyMultiple(); 


触摸 事件 : 
触摸 事件 比 上 述 的 按键 事件 要 复杂 一 些 。 从 用 户 的 角度 来 看 ， 正 常 
的 “触摸 屏 ” 设 备 既 支 持 点 击 ， 也 同时 能 “感应 ”滑动 事件 (MOVE) 


一 一 这 可 以 说 是 它 和 按键 事件 最 大 的 区 别 。 


比如 iPhone 手机 经 典 的 滑动 解锁 表面 〈 见 图 12-1) ， 它 的 操作 分 解 
开 来 只 有 3 步 : 





全 图 12-1 iPhone 的 经 典 解 锁 样 式 


o ZERA; 
。 移动 滑 块 ; 
© AFIT. 


以 上 动作 将 产生 3 种 触摸 事件 ， 即 


。 触 摸 点 按 下 (TOUCH_DOWN) ; 
。 触 摸 点 移动 (TOUCH_MOVE) ; 
。 触 摸 点 释放 (TOUCH_UP) 。 


值得 一 提 的 是 ， 由 MOVE 事 件 还 可 以 派生 出 其 他 的 事件 ， 如 fling。 
应 用 程序 为 了 模拟 真实 的 世 而 ， 就 必须 遵循 一 定 的 物理 现象 。 举 个 例 
子 ， 我 们 在 地 面 上 拖 动 一 辆 小 车 ， 放 手 后 小 车 并 不 会 马上 停止 ， 而 是 会 
继续 向 前 再 前 进 一 段 时 间 。 应 用 到 上 面 的 解锁 场景 ， 就 是 当 用 户 的 手势 
已 经 释放 后 (TOUCH_UP〉， 滑 块 本 身 也 不 会 马上 停止 ， 而 是 转化 为 
ge E eee nemo pee gees 
TE iho 


触摸 事件 相关 的 因素 包括 : 


。 fk RRA GEE, AF) ; 

。 触摸 点 移动 〈 移 动 的 距离 大 小 、 速 度 等 ) ; 

。 触摸 点 的 数量 (需要 “触摸 屏 ” 设 备 的 支持 ， 并 不 是 所 有 设备 都 可 
以 多 点 操作 ) ; 

。 时 间 因 素 (长 按 、 短 按 等 ) 。 


由 此 可 以 得 出 处 理 触 摸 事 件 的 几 个 基础 接口 ， 如 下 所 示 : 








onTouchDown(); 
onTouchuUp(); 
onTouchMove(); 
onTouchLongPress(); 
onTouchMultiple(); 


有 了 上 述 的 理解 ， 再 来 分 析 Android 系 统 中 的 实现 就 容易 多 了 。 
针对 所 有 事件 的 共性 ， 我 们 需要 提取 一 个 统一 的 抽象 接口 ， 这 就 是 


InputEvent。 从 它 的 名 称 可 以 看 出 ，Event 属 于 1/0 设 备 中 的 Input 部 
分 。 

InputEvent 下 有 两 个 子 类 ，KeyEvent 和 MotionEvent。 按 键 
KeyEvent 很 容易 理解 ， 用 于 表达 按键 事件 ; 而 Mot ionEvent 则 是 将 所 有 


能 产生 Movement 的 事件 源 进 行 统一 管理 ， 如 Trackbal1、Finger、Mouse 
等 。 来 看 看 它们 的 关系 ， 如 图 12-2 所 示 。 


KeyLvent 










Inputkvent 


+describeContents( ) 
tgetDevice( ) 


+oetDeviceld() 


+getEventTime() 
+getSource() 


MotionEvent 





AW12-2 Android 系统 中 的 事件 类 关系 图 

InputEvent 提 供 了 几 个 非常 通用 的 接口 。 比 如 getDevice () 函数 ， 
可 以 得 到 当前 事件 的 “硬件 源 ”。 其 返回 值 为 InputDev ice 类 型 ， 目 前 
支持 的 设备 包括 : 

SOURCE_UNKNOWN ; 

SOURCE_KEYBOARD; 

SOURCE_DPAD; 

SOURCE_GAMEPAD ; 

SOURCE_ TOUCHSCREEN; 

SOURCE_MOUSE ; 

SOURCE_STYLUS; 

SOURCE_TRACKBALL ; 

SOURCE_TOUCHPAD ; 

SOURCE TOUCH_ NAVIGATION; 

SOURCE JOYSTICK; 

SOURCE_ANY. 


可 以 看 到 ， 以 上 这 些 Devi ce 类 型 基本 涵盖 了 市 面 上 所 有 常见 的 输入 
设备 。 

本 小 节 的 最 后 ， 我 们 来 看 看 上 层 应 用 程序 是 如 何 参 与 事件 处 理 的 。 
换 句 话说 ， 它 们 是 如 何 获 知事 件 的 产生 的 ? 


对 于 应 用 开发 人 员 来 说 ， 他 们 与 事件 的 “直接 接触 ”一 般 都 是 通过 
View 组 件 进行 的 。 比 如 : 


e setOnKeyListener(OnKeyListener); 

e setOnTouchListener(OnTouchListener); 

e setOnGenericMotionListener(OnGenericMotionListener); 
e setOnHoverListener(OnHoverListener); 

e setOnDragListener(OnDragListener); 


值得 一 提 的 是 ， 虽 然 上 面 的 接口 都 是 通过 回调 的 形式 实现 的 ， 但 这 
并 不 是 唯一 的 方法 。 比 如 还 可 以 通过 重 载 View 拓 里 的 函数 来 完成 同样 的 
功能 。 图 12-3 体 现 了 这 两 种 方法 的 区 别 。 


很 显然 ， 图 中 所 示 的 两 种 方式 各 具 特 点 ， 开 发 人 员 应 该 根据 实际 情 
况 来 选择 。 


监听 函数 中 会 带 有 此 Event 相 关 的 信息 ， 以 供应 用 程序 可 以 正确 处 
理 它们 。 比 如 KeyEvent 的 监听 函数 : 


public interface OnkKeyListener { 
boolean onKey(View v, int keyCode, KeyEvent event); 
J 


Event Event 






mOnEventListener 
handleEvent() 


| | 
Override | 
| | 

| handleE 
A m vent) 
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全 图 12-3 事件 处 理 的 两 种 方法 


整个 接口 的 定义 很 简洁 ， 各 参数 含义 如 下 。 


View: 处 理 此 KeyEvent 的 View 对 象 。 


keyCode: 具体 对 应 的 是 哪个 物理 按键 ， 如 数字 键 1、 英 文 键 E、 特 
殊 按 键 F1、 相 机 按键 Camera 等 。 


KeyEvent: 事件 描述 体 ， 通 过 这 个 变量 可 以 获取 到 更 多 的 按键 事件 
信息 ， 如 getRepeatCount () getScanCode(), getSource (等 。 


12.2 事件 的 投递 流程 

上 一 节 我 们 对 系统 中 的 事件 进行 了 分 类 和 梳理 特别 是 从 硬件 源 的 
角度 区 分 出 了 事件 的 种 类 ) 。 另 外 ， 我 们 还 从 应 用 开发 者 的 角度 分 析 了 
如 何 去 监 听 和 响应 这 些 事件 。 


从 中 可 以 发 现 Android 系 统 提 供 的 监听 上 函数 非常 多 ， 那 么 究竟 这 些 
接口 与 具体 的 “硬件 源 ” 之 间 有 什么 确切 的 关联 呢 ? 


解决 这 个 问题 的 关键 就 是 要 理 清 事件 的 投递 流程 。 


总 体 来 说 ，Android 输 入 事件 投递 系统 的 工作 流程 分 为 4 个 部 分 ， 如 
图 12-4 所 示 。 





ee 


从 图 12-4 事件 处 理 系 统 工作 流程 图 
按照 事件 的 处 理 顺序 分 别 是 : 
。 KK 
即 对 “硬件 源 ” 所 产生 的 原始 信息 进行 收集 的 过 程 。 它 需要 Linux 


内 核 驱动 的 支持 ，Android 系 统 则 通过 /dev/input 下 的 节点 来 访问 当前 
发 生 的 事件 。 


。 前 期 处 理 


我 们 称 上 一 步 采集 到 的 信息 为 “原始 数据 ”一 一 这 其 中 有 一 部 分 内 
容 对 应 用 程序 而 言 并 不 是 “必需 ”的 ， 而 且 格式 上 也 相对 烦琐 ， 所 以 需 
要 先 经 过 前 期 的 提炼 和 转化 。 


e WMS 分 配 


WindowManagerService 是 窗口 的 大 主管 ， 同 时 也 是 InputEvent 的 派 
发 者 。 这 样 的 设计 是 自然 而 然 的 ， 因 为 WMS 记录 了 当前 系统 中 所 有 窗口 
的 完整 状态 信息 ， 所 以 也 只 有 它 才 能 判断 出 应 该 把 事件 投递 给 哪 一 个 具 
体 的 应 用 进程 进行 处 理 。 其 派发 策略 也 因 事 件 类 别 的 不 同 而 有 所 差异 
一 一 比如 说 按键 消息 直接 发 送 给 “最 前 端 ”的 窗口 即 可 ; 而 如 果 是 触摸 
消息 则 要 先 计 算出 触摸 点 落 在 哪个 区 域 ， 然 后 才能 传递 给 相应 的 窗口 单 
JLo 


。 应 用 程序 处 理 
应 用 开发 人 员 的 工作 主要 体现 在 这 一 部 分 。 经 过 前 面 几 个 步骤 的 伟 


递 ， 应 用 程序 端 接 收 到 的 事件 已 经 相对 “可 理解 ”“ 好 人 处理” 了 。 接 下 
来 要 做 的 ， 融 是 充分 利用 这 些 事件 来 实现 软件 功能 。 





12.2.1  InputManagerService 


InputManager Service (IMS) 的 创建 过 程 和 W indowManagerServi ce 类 
似 ， 都 由 SystemServer 统 一 启动 : 


/*frameworks/base/services/java/com/android/server/SystemServer , j 
public void run() {.. 

inputManager = new InputManagerService(context, wmHandl 

wm = WindowManagerService.main(context, power, display, 
wmHandler, factoryTest != SystemServer ,FAC 
!firstBoot, onl 

ServiceManager .addService(Context.WINDOW_SERVICE, wm); 
ServiceManager .addService(Context.INPUT_SERVICE, inputM 


inputManager .setWindowManagerCallbacks(wm.getInputMonit 
inputManager.start(); 


由 上 述 代码 段 也 可 以 看 出 ，1nputManagerService 与 


WindowManagerService 有 紧密 的 联系 一 一 前 者 的 实例 直接 传 入 后 者 ， 以 
便 后 续 调用 。 另 外 ，1IMS 也 将 自己 注册 到 了 ServiceManager 中 ， 名 称 为 
Context. INPUT SERVICE= “input” 。 


ABZ, InputManagerService. start 0) 是否 男 外 开启 了 一 个 工作 线 
程 ? 


/*frameworks/base/services/java/com/android/server/input/Inpu 
public void start() { 
Slog.i(TAG, "Starting input manager"); 
nativeStart(mPtr );// 本 地 函数 


} 


Java 层 的 1MS 实 际 上 是 对 Native 层 InputManager 的 一 层 Java 包 装 ， 
因而 这 个 类 的 实现 中 有 大 量 的 本 地 函数 声明 。 上 述 函 数 start 直 接 调 用 
了 本 地 实现 nativeStart。 其 中 变量 mPtr 是 1MS 在 构造 过 程 中 ， 调 用 
he hs le ea 本 质 上 是 一 个 C++ 指 
针 ， 所 以 可 通过 int 类 型 进行 保存 : 


/*frameworks/base/services/jni/com_android_server_input_InputMana 
static void nativeStart(JNIEnv* env, jclass clazz, jint ptr) { 
NativeInputManager* im = reinterpret_cast<NativeInputManager* 
ptr 指 针 强 制 类 型 转换 为 NativeInputManager 对 象 */ 
status_t result = im->getInputManager()->start();/*getInputMa 
a a a 所 以 最 终 入 将 执行 的 是 InputManager . 








如 前 面 所 述 ，1MS 在 Nat ive 层 的 实现 主体 是 InputManager ， 如 
start: 


/*frameworks/base/services/input/InputManager .cpp*/ 

status_t InputManager::start() { 

status_t result = mDispatcherThread->run("InputDispatcher", PRIORI 
result = mReaderThread->run("InputReader", PRIORITY_URGENT_DI 


return OK; 


果然 ，InputManager 为 1IMS 创 建 了 新 的 线程 ， 而 且 还 是 两 个 : 


o InputReaderThread ; 
e InputDispatcherThread. 


MBER ale GS cet 它们 一 个 负责 “Reader” 〈 从 驱动 节点 中 读 取 


Event) ， 另 一 个 则 专职 “Dispatcher” (DE) 。 接 下 来 我 们 将 分 别 
e T 


12.2.2 1nputReaderThread 


InputReader Thr eadi jE ke RK Rize MIE a A aA Fen E E 
ee 它 的 工作 相对 单一 ， 即 不 断 地 轮 询 相关 设备 节点 是 否 有 新 
BHE. 


/*frameworks/base/services/input/InputReader .h*/ 
class InputReaderThread : public Thread { // 继 承 自 Thread 
public: 
InputReaderThread(const sp<InputReaderInterface>& reader); 
virtual ~InputReaderThread(); 
private: 
sp<InputReaderInterface> mReader; // 辅 助 类 
virtual bool threadLoop(); 


}; 


InputReaderThread 中 的 实现 核心 是 lnputReader 类。 这 一 部 分 的 代 
码 比 较 简 单 ， 我 们 不 进行 具体 分 析 ， 但 有 几 个 重点 需要 大 家 了 解 : 


e InputReader 实 际 上 并 不 直接 去 访问 设备 节点 ， 而 是 通过 EventHub 来 
Tae LIF; 

e EventHub 通 过 读 取 /dev/input/ 下 的 相关 文件 来 判断 是 否 有 新 事件 ， 

并 通知 InputReadet。 











12.2.3 InputDispatcherThread 


从 InputManagerService 的 构造 过 程 中 ， 我 们 可 以 知道 
InputDispatcherThread 和 lnputReaderThread 一 样 ， 也 是 一 个 独立 的 线 
程 ， 而 且 和 WindowManagerService 都 运行 于 系统 进程 中 。 另 外 ， 
InputDispatcherThread 中 的 实现 核心 是 InputDispatcher 类 。 


InputDispatcherThread 将 与 InputReaderThread 协 同 工 作 ， 以 保证 


事件 的 正确 派发 和 处 理 。 那 么 ， 它 们 具体 又 是 怎么 做 的 呢 ? 


还 记得 是 谁 创 建 了 这 两 个 线程 的 吗 ? 可 以 先 来 看 看 InputManager 中 
是 否 对 它们 进行 了 统一 管理 : 


/*frameworks/base/services/input/InputManager .cpp*/ 
InputManager: :InputManager(const sp<EventHubInterface>& eventHub, 
const sp<InputReaderPolicyInterface>& reader 
const sp<InputDispatcherPolicyInterface>& di 
mDispatcher = new InputDispatcher(dispatcherPolicy) ; 
mReader = new InputReader(eventHub, readerPolicy, mDispatcher 
/*#InputReader 5InputDispatcher #17 cK */ 
initialize(); 





可 见 InputReader 在 创建 之 初 就 与 InputDispatcher 产 生 了 紧密 的 关 
联 ， 这 是 它们 后 期 协作 的 一 个 重要 基础 。 比如 在 InputReader 的 
loopOnce () 循环 中 ， 会 把 发 生 的 事件 通过 InputDispatcher 实 例 告知 


Listener: 


/*frameworks/base/services/input/InputReader.cpp*/ 
void InputReader::loopOnce() {... 
We >flush(); // 这 个 变量 实质 上 是 上 面 npispatcher 的 进 一 





IX4F, InputDispatcher RE 入 源 不 断 地 获知 系统 Xe PSA AE 
的 事件 了 。 而 且 它 还 可 以 向 InputReader 注 册 监 听 多 种 事件 。 相 关 的 
cal | back AU TB Ata: 


notifyConfigurationChanged(const NotifyConfigurationChangedArgs* ) 
notifyKey(const NotifyKeyArgs*); 

notifyMotion(const NotifyMotionArgs* ); 

notifySwitch(const NotifySwitchArgs* ); 

notifyDeviceReset(const NotifyDeviceResetArgs*); 


下 面 我 们 以 notifyKey 为 例 来 分 析 一 下 具体 的 处 理 过 程 ， 如 图 12-5 
所 示 。 


InputRcader Thread 


Enguevelnbound 
EventLocked 


MInbound 
Queue 


Targets 





全 图 12-5 InputDispatcher 线 程 对 事件 的 处 理 


图 12-5 中 与 “分 发 ”策略 有 直接 关联 的 是 dispatchKeyLocked。 其 
核心 源码 如 下 : 


/*frameworks/base/services/input/InputDispatcher.cpp*/ 
bool InputDispatcher::dispatchKeyLocked(nsecs_t currentTime, KeyE 
* dropReason, nsecs_t* nextWakeupTime) { 

/*Step1. 前 期 处 理 ， 主 要 针对 按键 的 repeatCount */ 

…// 代 码 省 略 


/*Step2 .检查 是 否 INTERCEPT_KEY_RESULT_TRY_AGAIN_LATER。 如 果 是 的 话 ， 
要 求 与 否 一 如 果 不 满足 的 话 ， 直 接 返 回 */ 
.…// 代 码 省 略 


/*Step3 .在 将 事件 发 送出 去 前 ， 先 要 检查 当前 系统 集 略 (Policy ) 是 否 要 对 它 进行 
Home， 就 需要 先 由 WMS 来 处 理 */ 
oD RASA 


/*Step4. 判 断 是 否 要 放弃 当前 事件 */ 
..// 代 码 省 略 


/*Step5 .确定 事件 的 接收 方 (Targets)。 这 是 最 重要 的 一 步 */ 
Vector<InputTarget> inputTargets; 
int32_t injectionResult = findFocusedWindowTargetsLocked (curr 
input Targets 
/* 查 找 符合 要 求 的 事件 投递 目标 ， 下 面 会 针对 这 个 函数 进行 分 析 */ 

























































































setInjectionResultLocked(entry, injectionResult); 


dispatchEventLocked(currentTime, entry, inputTargets);/*Step6 
return true; 


上 述 函 数 很 长 ， 为 了 让 大 家 能 对 处 理 流 程 “ 一 目 了 然 ”， 我 们 只 保 
留 了 其 中 的 核心 部 分 ， 并 对 每 一 个 步骤 都 做 了 适当 的 前 述 。 可 以 看 出 ， 
Step1~-Step4 都 可 以 算是 “前 期 工作 ”， 包 括 预 处 理 、 事 件 拦截 、 
Policy 的 应 用 等 。 


需要 大 家 特别 关注 的 是 Step5， 即 InputDispatcher 如 何 查找 与 当前 
按键 事件 匹配 的 目标 呢 ? 前 面 我 们 说 过 ， 对 于 按键 消息 而 言 ， 只 要 找 
到 “最 前 端 ”的 窗口 即 可 。 当 然 ， 实 际 的 处 理 过 程 会 稍微 复杂 些 ， 如 下 
所 示 : 


int32_t InputDispatcher: :findFocusedWindowTargetsLocked(nsecs_t c 
EventEntry* entry, ector<InputTarget>& inputTargets, nsecs_t* nex 
int32_t injectionResult; 
if (mFocusedWindowHandle == NULL) {/* 如 果 当 前 并 没有 “最 前 端 ”( 即 获 1 
按照 Android 系 统 中 的 作法 ， 会 丢 充 这 一 事件 。 变 量 mFocusedwindowHandle 代 
if (mFocusedApplicationHandle != NULL) { 

injectionResult = handleTargetsNotReadyLocked(currentTi 

mFocusedApplicationHandle, NULL, 
/* 如 果 没 有 “最 前 端 ” 的 窗口 ， 但 却 有 “最 前 端 ”的 应 用 
程序 还 在 启动 过 程 中 ， 因 而 先 等 待 一 段 时 间 后 























goto Unresponsive; 


} 


injectionResult = INPUT_EVENT_INJECTION_FAILED; 
goto Failed;/v* 既 没有 焦点 窗口 ， 也 没有 焦点 应 用 的 情况 ， 程 序 将 报错 */ 


} 
/* 执 行 到 这 里 说 明 当 前 有 焦点 窗口 */ 
if (! checkInjectionPermission(mFocusedWindowHandle, entry->i 














injectionResult = INPUT_EVENT_INJECTION_PERMISSION_DENI 
goto Failed; 


} 


/* 如 果 当 前 窗口 处 于 暂停 状态 ， 也 需要 等 待 */ 
if (mFocusedWindowHandle->getInfo()->paused) {... 


























} 
/* 当 前 窗口 还 在 处 理 上 一 个 事件 ， 和 上 面 一 样 ， 都 需要 等 待 它 完成 */ 
if (!isWindowReadyForMoreInputLocked(currentTime, mFocusedwin 


} 


/* 成 功 找 到 符合 要 求 的 窗口 ， 并 且 状 态 值 都 正确 ， 此 时 可 以 将 它 加 入 ijnputTarget 

injectionResult = INPUT_EVENT_INJECTION_SUCCEEDED; 

addWindowTargetLocked(mFocusedWindowHandle, 
InputTarget::FLAG_FOREGROUND | InputTarg 
BitSet32(0), inputTargets); 























Failed: 
Unresponsive: 


/* … 异 常 处 理 部 分 ， 代 码 略 */ 
} 

















读者 可 能 会 觉得 奇怪 ， 为 什么 InputDispatcher 会 有 当前 焦点 窗口 
的 句柄 呢 ， 是 谁 向 它 提供 了 这 类 信息 ? 通过 查找 代码 ， 可 以 发 现 
mFocusedWindowHandle 是 由 InputMonitor 来 赋值 的 后 面 这 个 
InputMonitor 又 扮演 了 什么 样 的 角色 呢 ? 


简单 来 说 ， 它 是 WMS 与 1nputDispatcher 之 间 的 “中 介 ”。 





从 源码 的 角度 可 分 为 两 部 分 。 


e InputDispatcher— InputMonitor—>WMS 


Te SLE Y IMSAYWindowManagerCal Ibacks##0: 


/*frameworks/base/services/java/com/android/server/input/InputMan 
public interface WindowManagerCallbacks{ 


public 
public 
public 


public 


void notifyConfigurationChanged(); // 输 入 设备 的 配置 变更 
void notifyLidSwitchchanged(long，boolean);//Lid 开 关 
void notifyInputChannelBroken(InputWindowHandle); /* 连 j 
用 程序 的 Socket 通 道 。 接 下 芽 
long notifyANR(InputApplicationHandle, InputwindowHand 





Application Not Responding 错 误 */ 


public 
public 
public 
public 


public 


int interceptKeyBeforeQueueing(KeyEvent, int, boolean) 
int interceptMotionBeforeQueueingwhenScreenOff (int); 
long interceptKeyBeforeDispatching(InputwindowHandle, 
/* 以 上 3 个 回调 接口 保证 了 WMS 在 消息 处 理 中 拥有 绝对 
KeyEvent dispatchUnhandledKey(InputWindowHandle, KeyEv 
按键 事件 在 整个 投递 流程 中 没有 得 到 任何 处 理 ， 这 时 要 


int getPointerLayer(); 



























































e WMS—InputMonitor—InputDispatcher 


除了 上 述 回 调 接口 外 ，lnputMonitor 也 为 WMS 访问 InputDispatcher 
提供 了 一 系列 的 函数 实现 。 比 如 InputDispatcher 中 的 当前 焦点 窗口 ， 
就 是 WMS 通过 1nputMonitor 的 updatelnputWindowsLw () 告知 的 。 


现在 我 们 已 经 清楚 WMSs 与 nputDi spatcher 、lnputReader 三 者 间 的 
交互 关系 了 。 最 后 还 有 一 个 问题 ， 就 是 InputDispatcher 是 如 何 通知 应 
用 程序 窗口 有 按键 事件 的 。 换 句 话说 ， 它 和 IinputTarget 之 间 是 如 何 通 


信和 的? 


/*frameworks/base/services/input/InputDispatcher .h*/ 
struct InputTarget { 
enum {/* 这 个 枚 举 类 型 里 是 关于 目标 窗口 的 各 种 属性 值 描述 */ 


}; . 


























FLAG _FOREGROUND = 1 << 0，// 说 明 目 标 窗口 是 前 台 应 用 
.….// 其 他 FLAGS 省 略 





/* 就 是 这 里 了 ，InputDispatcher 通 过 inputChannel 与 窗口 建立 连接 */ 
sp<InputChannel> inputChannel; 





在 Android 系 统 中 ， 进 程 间 的 通信 大 多 是 基于 Binder 机 制 的 。 而 
InputDispatcher 和 应 用 程序 之 间 肯 定 也 是 跨 进 程 的 ， 那 么 这 个 
InputChanne1 是 不 是 Binder Server 呢 ? 


这 是 一 个 合理 的 猜测 ， 不 过 事实 并 非 如 此 。 我 们 来 看 看 它 的 类 型 定 
义 就 知道 了 : 


/*frameworks/base/include/androidfw/InputTransport.h */ 
class InputChannel : public RefBase { 
protected: 
virtual ~InputChannel(); 
public: 
InputChannel(const String8& name, int fd);/* 构 造 函 数 中 传 入 的 是 in 
有 点 类 似 于 文件 描述 符 */ 
static status_t openInputChannelPair(const String8& name, sp< 
outServerChannel, sp<InputChannel>& outClientChann 
一 个 Channe1 对 (因为 是 双 | 

















status_t sendMessage(const InputMessage* msg); 
status_t receiveMessage(InputMessage* msg); 
/* 发 送 和 接收 消息 */ 
private: 
String8 mName; // 通 道 名 称 
int mFd; // 重 点 就 是 这 个 jnt 类 型 代表 的 是 什么 
J; 


既然 InputDispatcher 是 通过 channe1 通 道 与 应 用 程序 FTES, 
那么 每 增加 一 个 应 用 程序 窗口 ， 都 得 新 建 一 对 1nputChanne1。 这 样 我 们 
就 可 以 从 WMS 新 增 窗口 的 相关 代码 入 手 ， 进 而 理 清 整个 过 程 : 


/*frameworks/base/services/java/com/android/server/wm/WindowManag 
public int addWindow(Session session, IWindow client, int seg, Wi 
int viewVisibility, int displayId, Rect outContentInsets, InputCh 
{ 


String name = win.makeInputChannelName(); // 为 当前 的 通道 取 名 
InputChannel[] inputChannels = InputChannel.openInputChannel 
/打开 一 对 通道 */ 


经 过 JNI 及 一 系列 函数 调用 ， 打 开通 道 的 本 地 实现 代码 如 下 : 


/*frameworks/base/include/androidfw/InputTransport.cpp*/ 
status_t InputChannel: :openInputChannelPair(const String8& name,s 
outServerChannel, 
sp<InputChannel>& outClientChannel) { 
int sockets[2];/* 终 于 水 落石 出 了 ， 原 来 是 通过 Unix Domain Socket 
if (socketpair (AF_ UNIX, SOCK_SEQPACKET, ©, sockets)) {/* 本 篇 的 
已 经 介绍 过 Unix Domain Socket 的 使 用 方法 了 。 这 里 唯一 的 不 同 就 是 直接 采用 了 
而 简化 了 双方 通信 的 工作 */ 
status_t result = -errno; 




















return result; 


J 


int bufferSize = SOCKET_BUFFER_SIZE; 

setsockopt(sockets[0], SOL_SOCKET, SO_SNDBUF, &bufferSize, si 

setsockopt(sockets[0], SOL_SOCKET, SO_RCVBUF, &bufferSize, si 

setsockopt(sockets[1], SOL_SOCKET, SO_SNDBUF, &bufferSize, si 

setsockopt(sockets[1], SOL_SOCKET, SO_RCVBUF, &bufferSize, si 
/* 设 置 通信 双方 各 自 的 缓冲 区 大 小 */ 

String8 serverChannelName = name; 

serverChannelName.append(" (server)"); 

outServerChannel = new InputChannel(serverChannelName, socket 

字 是 在 NMS 传 过 来 的 名 称 基 础 上 再 加 上 后 缀 。 并 且 在 以 后 的 通信 中 作 

String8 clientChannelName = name; 

clientChannelName.append(" (client)"); 

outClientChannel = new InputChannel(clientChannelName, socket 














return OK; 


通过 这 个 函数 的 分 析 可 知 ，lnputChanne1 中 的 mFd 实 际 上 是 socket 


至 此 ，1lnputReader、 InputDispatcher、 WMS 和 应 用 程序 的 关系 已 
relate 。 读 者 在 理解 了 这 四 者 间 的 关系 后 ， 可 以 有 针对 性 地 再 自 
了 分 析 其 他 事件 的 处 理 流程 。 


12.2.4 ViewRoot1mp1 对 事件 的 派发 


到 目前 为 止 ， 我 们 的 分 析 已 经 上 覆盖 了 Android 事 件 投递 系统 的 前 3 部 
分 ， 最 后 就 只 剩 下 应 用 程序 这 边 的 处 理 了 。 一 方面 ，ViewRoot1lmp1 是 
WN 与 应 用 程序 窗口 间 的 “桥梁 ”， 就 如 InputMonitor 与 WMS 之 间 的 关系 
一 样 ; 另 一 方面 ，ViewRoot Imp1 还 是 应 用 进程 中 担当 事件 派发 与 管理 的 


最 佳 “ 人 ” 选 


接着 前 一 小 节 的 讲解 ， 当 有 事件 产生 后 ，lnputDispatcher 会 通知 
到 相应 的 接收 者 ; 而 后 者 则 负责 对 事件 做 进一步 的 派发 与 处 理 。 在 
ViewRoot1Imp1 中 ， 一 旦 获知 InputEvent， 它 首先 调用 
enqueue1nputEvent 进 行事 件 “ 入 队 ”。 此 时 分 为 两 种 情况 。 


。 紧急 事件 


如 果 是 “紧急 事件 ”， 变 量 processlmmediately 为 true， 那 么 
enqueue1nputEvent 会 直接 调用 doProcess1lnputEvents 进 行 处 理 。 


。 其 他 事件 


如 果 事 件 本 身 并 不 是 “刻不容缓 ”的 ， 那 么 enqueue1lnputEvent 会 
通过 scheduleProcesslnput Events 来 把 这 个 1nputEvent 推 送 到 消息 队 
列 中 ， 然 后 按 顺 序 处 理 。 


无 论 是 哪 一 种 情况 ，ViewRoot1mp1 都 需要 (只 是 处 理 顺 序 的 差异 ) 
对 这 一 InputEvent 进 行 派发 ， 并 最 终 由 ViewTree 中 的 某 一 特定 View 对 象 
来 做 具体 的 事件 处 理 。 详 细 流 程 在 前 一 节 已 经 讨论 过 ， 这 里 不 再 准 述 。 


12.3 事件 注入 


正常 情况 下 ，Android 系 统 中 的 各 种 Event 是 由 用 户主 动 发 起 而 产生 
的 。 壁 如 用 户 点 击 设 备 屏幕 产生 的 触 屏 事件 ; 按压 物理 按键 产生 的 
KeyEvent 等 。 但 是 ， 在 某 些 特殊 的 情况 下 “比如 自动 化 测试 的 场景 
A i eee 此 时 就 需要 事件 
注 — To 


事件 注入 的 方式 有 很 多 种 ， 包 括 但 不 限于 : 
e 通过 Input Manager 提 供 的 内 部 API 接 口 


Input Manager 提 供 了 让 开发 者 可 以 注入 事件 的 接口 ， 摘 述 如 下 : 
/*frameworks/base/core/java/android/hardware/input/InputManager . j 


* Injects an input event into the event system on behalf of 
* @hide 
*/ 


public boolean injectInputEvent(InputEvent event, int mode) { 


不 过 这 个 接口 是 hide 的 ， 意 味 着 普通 的 开发 者 无 权 在 应 用 程序 中 使 
用 它 (当然 ， 这 并 不 是 绝对 的 ， 在 某 些 Android 版 本 中 我 们 可 以 通过 一 些 
特殊 的 方法 来 绕 过 这 些 限制 ) 。 因 而 这 种 方式 较 常 见于 Android 工 程 自 身 
的 各 个 模块 中 ， 比 如 下 面 的 例子 摘自 hdmi server 的 实现 中 : 


static void injectKeyEvent(long time, int action, int keycode 
KeyEvent keyEvent = KeyEvent.obtain(time, time, action, k 
repeat, 0, KeyCharacterMap.VIRTUAL_KEYBOARD, 0, KeyE 
InputDevice.SOURCE_HDMI, null); 
InputManager.getInstance().injectInputEvent(keyEvent, 
InputManager .INJECT_INPUT_EVENT_M 
keyEvent.recycle(); 


e 利用 Insttumentation 提 供 的 接口 


Instrumentat ion 也 提供 了 一 些 辅助 事件 注入 的 接口 ， 璧 如 : 


/*frameworks/base/core/java/android/app/Instrumentation. java*/ 
LER 
* Sends an up and down key event sync to the currently focus 


* 


* @param key The integer keycode for the event. 
*/ 
public void sendKeyDownUpSync(int key) { 
sendKeySync(new KeyEvent(KeyEvent.ACTION_DOWN, key)); 
sendKeySync(new KeyEvent(KeyEvent.ACTION_UP, key)); 


这 种 方式 比 第 一 种 在 使 用 上 方便 一 些 ， 但 缺点 很 明显 ， 融 是 只 对 本 
应 用 程序 自己 有 效 。 换 句 话说 ， 如 有 果 我 们 面临 的 是 跨 应 用 进程 的 测试 场 
景 则 无 法 起 到 任何 作用 。 


。 通过 system/bin 目 录 下 的 input 程 序 


System/bin 目 录 下 保存 着 一 系列 非常 有 用 的 程序 ， 如 monkey、am、 
dex2oat 等 ， 其 中 与 事件 注入 相关 的 是 input。 如 图 12-6 所 示 。 





PUXP-XP-x root 2615-61-21 : idlestat 

lruxruxrux root ~ 2615-88-22 : ifconfig 一 > toolbox 
lruxruxrux root 2015-08-22 : iftop 一 > toolbox 
PUXP-xXP-xX root shell 2615-61-21 : ime 

PUXP-xXP-x root shell 2615-61-21 z input 


lruxruxrux root root 2015-08-22 : insmod 一 > toolbox 
PUXP-XP-x root shell 2615-61-21 z installd 
lruxruxrux root root 2015-08-22 : ioctl -> toolbox 
lruxr-xr-x root shell 2615-61-21 : ionice 一 > toolbox 
PUXE-xXP-x root shell 285252 2615-61-21 : iozone 





全 图 12-6 相关 的 input 


我 们 可 以 通过 adb shel | 来 使 用 这 个 input 工 具 。 如 果 不 知道 命令 格 
式 的 话 ， 可 以 查询 它 的 帮助 ， 如 图 12-7 所 示 。 


=: Wsers\xs@>adb shell 
hell@hwmt?:/ $ input 
input 


sage: input [<source>] <command> [<arg>...] 


he sources are: 
trackball 
joystick 
touchnavigation 
mouse 
ke yboard 
gamepad 
touchpad 
dpad 
stylus 
touchscreen 


he commands and default sources are: 
text <string> (Default: touchscreen> 
keyevent [--longpress] <key code number or name> ... (Default: keyboard> 
tap <x> <y> (Default: touchscreen?) 
swipe <x1l> yl> <x2> <y2> [duration<ms)] (Default: touchscreen) 
press (Default: trackball> 
roll <dx> <dy> (Default: trackball> 





全 图 12-7 帮助 


举 一 个 例子 来 说 ， 通 过 下 面 的 语句 可 以 向 设备 发 送 一 个 HOME 按键 事 
F, ERREIAN: 


input keyevent 3 


其 中 数字 3 对 应 的 是 HOME 按键 。 其 他 数值 与 具体 功能 的 对 应 关系 可 
以 通过 阅读 源码 获得 。 


。 直接 写 入 数据 到 /dev/input/event 久 节点 中 


我 们 知道 ，input 目 录 下 的 节点 是 kerne1 向 Android 提 供 事件 信息 
的 “桥梁 中 介 ”， 因 而 直接 向 这 些 eventX 写 入 数据 相当 于 从 “源头 ”来 
空 制 事件 的 产生 。 也 正 是 因为 这 个 原因 ，Android 系 统 为 这 些 节点 设置 
了 较 高 的 权限 ， 禁 止 普 通 的 应 用 程序 直接 向 它们 注入 数据 ， 如 图 12-8 所 


小 。 


she ll@hwmt?:/dev/input $ 11 


root input 2615-69-14 : event@ 
root input 2615-69-14 z eventi 
root input 2615-89-14 s event2 
root input 2615-69-14 : event3 
root input 2615-69-14 : event4 
root input 2615-89-14 z euent5 
root input 2615-69-14 : mice 

root input 2615-89-14 : mouseg 
root input 2615-69-14 : mousel 





全 图 12-8 输出 界面 


所 以 ， 如 果 希 望 采用 这 种 方式 来 完成 事件 的 注入 ， 那 么 需要 对 
Android 设 备 做 一 些 特殊 的 处 理 。 大 家 可 以 自行 查阅 相关 资料 来 做 一 下 
验证 。 


oo 
应 用 不 再 同 质 化 一 一 音频 系统 


对 于 一 部 藤 入 式 设 备 来 说 ， 除 了 若干 基础 功能 外 《比如 手机 通话 、 
短信 ) ， 最 重要 的 可 能 就 是 多 媒体 了 一 一 首先 我 们 要 问 自己 一 个 简单 的 
问题 : 什么 是 多 媒体 呢 ? 


这 个 术语 对 应 的 英文 单词 是 “Multi-Media”， 直 详 过 来 就 是 多 媒 
体 一 一 名 称 本 身 很 好 地 解释 了 它 的 含义 ， 我 们 也 可 以 参见 Wikipedia 上 
的 详细 定义 。 
Multi-media is media and content that uses a combination of diffe 
bination of text, audio, still images, animation, video, or inter 


通俗 地 讲 ，Multi-media 是 多 种 形式 的 媒体 内 容 〈 比 如 文本 、 音 
频 、 视 频 、 图 片 、 动 画 等 ) 的 组 合 。 可 以 说 ， 它 是 一 款 产 品 能 否 在 众 
多 “ 同 质 化 ”严重 的 市 场 中 脱颖而出 的 关键 。 另 外 ， 由 于 不 同 的 产品 在 
音频 处 理 、 视 频 解 码 等 芯片 方面 或 多 或 少 都 存在 差异 ， 原 生态 的 
Android 系 统 不 可 能 上 履 盖 市 面 上 的 所 有 硬件 方案 ， 所 以 这 部 分 功能 的 移 
植 与 二 次 开发 就 成 了 设备 研发 中 的 重头 戏 一 一 当然 ，Android 系 统 在 设 
计 之 初 也 充分 考虑 到 了 这 点 ， 它 提供 了 一 整套 灵活 的 多 媒体 解决 方案 ， 
以 应 对 厂商 的 定制 化 需求 。 


对 于 应 用 开发 人 员 来 说 ， 多 媒体 的 另 一 个 “代名词 ”或 许可 以 说 
是 “MediaPlayer 和 MediaRecorder” (这 样 说 多 少 有 点 “武断 ”， 不 过 
是 很 多 开发 人 员 的 共识 ) ， 而 深 藏 在 这 两 个 类 中 的 实现 细节 却 鲜 有 人 
知 。 这 也 是 Android 的 一 大 优点 一 一 高 度 封 装 ， 让 研发 人 员 可 以 把 精力 
放 在 自己 “需要 做 的 事情 上 ”， 各 司 其 职 ， 从 而 极 大 地 提高 了 产品 的 开 


发 效率 。 


不 过 ， 这 种 封装 也 同时 让 我 们 付出 了 一 些 代 价 。 比 如 整个 多 媒体 系 
统 显得 异常 庞大 ， 各 种 类 定义 、C++ 库 、Java 实 现 让 人 应 接 不 上 最 一 一 这 
无 疑 给 大 家 剖析 多 媒体 系统 的 内 部 实现 带 来 了 不 少 障碍 。 为 此 ， 本 章 特 
别 选 取 音 频 系 统 〈“ 其 中 又 以 “音频 回放 ”为 分 析 核 心 ) 作为 学 习 的 重 


点 。 通 过 深入 分 析 音 频 系统 ， 来 为 大 家 理解 Android 多 媒体 系统 打开 一 
个 “缺口 ” 


本 章 的 内 容 编排 是 由 下 而 上 的 ， 即 从 音频 基础 知识 、 底 层 框架 讲 
起 ， 然 后 才 逐 步 扩展 延伸 到 上 层 应 用 。 其 主要 包括 如 下 几 个 核心 。 


。 音频 的 基础 知识 
理解 音频 的 一 些 基 础 知识 ， 对 于 大 家 分 析 整 个 音频 系统 大 有 宰 蔓 。 
它 可 以 让 我 们 从 实现 的 层面 去 思考 音频 系统 的 “目标 是 什么 ”， 然 后 才 
是 “怎么 样 去 达到 这 个 目标 ”。 
e AudioFlinger, AudioPolicyService 和 AudioTrack/AudioRecorder 


抛 开 MediaPlayer、MediaRecorder 这 些 与 应 用 开发 有 直接 关联 的 部 
分 ， 整 个 音频 系统 的 核心 就 是 由 这 三 者 构建 而 成 的 。 其 中 前 两 者 都 属于 
System Service， 驻 留 在 mediaserver 进 程 中 ， 负 责 不 断 地 处 理 
AudioTrack/AudioRecorder 的 请 求 。 另 外 ， 音 频 的 “回放 和 录制 ”从 总 
体 流 程 上 分 析 都 是 类 似 的 ， 所 以 本 章 侧重 于 对 回放 过 程 的 分 析 。 


。 音频 的 数据 流 


数据 流 处 理 是 音频 系统 管理 的 重点 和 难点 之 一 ， 至 少 有 以 下 几 点 是 
需要 设计 者 充分 考虑 的 〈 以 音频 回放 为 例 ) 。 


o 正确 规划 音频 流 的 路 径 (AudioPolicy) 
通常 Android 产 品 会 配备 多 种 音频 回放 设备 《如 了 喇叭、 耳机 、 蓝 
=) ， 而 且 同 一 个 “时 间 点 ”系统 也 很 可 能 会 播放 多 种 音频 一 一 我 们 如 
何 正确 处 理 音 频 的 混 音 ， 并 将 结果 输出 到 对 应 的 音频 回放 设备 中 ? 


o 如 何 保证 音频 流 以 合理 的 速度 传输 到 音频 设备 








然 ， 音 频数 据 的 太 快 或 者 太 慢 传输 都 会 是 缺陷 。 


显然 ， 
。 跨 进程 的 数据 传递 
从 Apk 应 用 程序 创建 一 个 MediaPlayer 开 始 ， 到 音频 能 真正 从 设备 中 
回放 出 来 ， 这 个 过 程 涉及 多 个 进程 间 的 通信 。 如 何在 这 些 进程 之 间 做 好 
数据 的 准确 传递 ， 也 是 设计 者 应 该 重点 思考 的 。 
© 音频 系统 的 上 层 建 筑 


在 理解 了 音频 系统 的 实现 核心 后 ， 我 们 再 从 上 层 应 用 的 角度 来 思 
考 : 如 何 为 应 用 开发 人 员 提 供 简 捷 高 效 的 “音频 使 用 和 控制 ”的 解决 方 


13.1 音频 基础 
13.1.1 声波 
从 物理 学 的 角度 来 说 ， 声 波 是 机 械 波 的 一 种 。 


机 械 波 〈Mechanical Wave) 是 由 机 械 振荡 产生 的 ， 所 以 它 的 传播 
需要 介质 的 支持 。 


另外 ， 机 械 波 还 有 如 下 特点 。 
© 介质 本 身 并 不 会 随 着 机 械 波 不 断 地 前 进 。 比 如 我 们 拌 动 一 条 绳子 产 
生 的 绳 波 ， 绳 子 上 的 某 个 点 只 是 在 一 定 范 围 内 做 上 下 和 运动， 没有 因 
为 波 的 传递 而 脱离 绳子 。 因 而 机 械 波 是 能 量 的 传递 ， 而 不 是 质量 的 
传递 。 
。 在 不 同 的 介质 中 ， 传 播 速 度 是 不 一 样 的 。 
那么 ， 作 为 机 械 波 的 一 种 ， 声 音 有 哪些 重要 属性 呢 ? 
e ‘tq (Loudness) 
响 度 就 是 人 类 可 以 感知 到 的 各 种 声音 的 大 小 ， 即 俗称 的 “音量 ”。 
响 度 与 声波 的 振幅 有 直接 关系 一 一 理论 上 振幅 越 大 ， 响 度 也 就 越 大 。 
e 音调 (Pitch) 
我 们 常 说 某 人 唱 高 音 很 好 ， 或 者 低音 很 棒 ， 这 就 是 音调。 音调 与 声 
音 的 频率 有 关系 一 一 当 声 音 的 频率 越 大 时 ， 人 耳 所 感知 到 的 音调 就 越 
高 ， 否 则 就 越 低 。 
e 音色 (Quality) 
同一 种 乐器 使 用 不 同 的 材质 来 制作 ， 所 表现 出 来 的 音色 效果 则 不 一 
样 ， 这 是 由 物体 本 身 的 结构 特性 所 决定 的 它 直 接 影 响 了 声音 的 音色 


属性 。 同 样 的 道理 ， 不 同 的 演唱 者 因为 他 们 发 声 部 位 的 先天 差异 ， 从 而 
造就 了 更 具 嗓 首 特 色 的 音乐 才子 。 








声音 的 这 几 个 属性 ， 是 所 有 音频 效果 处 理 的 基础 。 换 句 话 说 ， 任 何 
对 音频 数据 的 调整 手段 最 终 都 将 反映 到 这 些 属性 上 。 


13.1.2 音频 的 录制 、 存 储 与 回放 


上 面 我 们 对 多 媒体 的 定义 还 从 侧面 反映 出 一 个 结论 ， 即 Multi- 
Media 并 不 是 专门 为 计算 机 而 生 的 一 一 只 不 过 后 者 的 出 现 极 大 地 推动 了 
e eee neue enn genau anne ere 
些 区 别 呢 ? 


一 个 很 明显 的 问题 是 : 我 们 如 何 将 各 种 媒体 源 数字 化 呢 ? 之 所 以 有 
这 个 疑问 ， 是 因为 早期 的 音频 信息 存储 在 录音 带 中 ， 并 以 模拟 信号 的 形 
式 保存 。 而 到 了 计算 机 时 代 ， 这 些 音频 数据 必须 通过 一 定 的 处 理 手段 才 
E RE ee 遇 到 的 一 个 常见 问 


如 图 13-1 所 示 就 是 音频 从 录制 到 播放 的 一 个 典型 操作 流程 。 
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全 图 13-1 音频 的 录制 、 存 储 和 回放 


引用 自 http://en.wikipedia.org/wiki/File:A-D-A_Flow.svg。 
(1) 录制 过 程 
。 首先 ， 音 频 采 集 设备 (比如 Microphone) 捕获 声音 信息 (初始 数据 
是 模拟 信号 ) 
采集 到 的 模拟 信号 通过 模 - 数 转换 器 (ADC) 处 理 成 计算 机 能 接受 
的 二 进 制 数据 。 





。 上 一 步 得 到 的 数据 按照 需求 进行 必要 的 渲染 处 理 ， 如 音效 调整 、 过 
滤 等 。 

处 理 后 的 音频 数据 理论 上 已 经 可 以 存储 到 计算 机 设备 中 了 ， 邵 硬 
盘 、USB 设 备 等 。 不 过 由 于 这 时 的 音频 数据 体积 相对 较 大 ， 不 利于 
保存 和 和 传输， 通常 我 们 还 会 对 其 进行 压缩 处 理 。 比 如 和 常 见 的 mp3 音 
乐 ， 实 际 上 就 是 对 原始 数据 采用 相应 的 压缩 算法 后 得 到 的 。 压 缩 过 
程 根据 采样 率 、 位 深 等 因素 的 不 同 ， 最 终 得 到 的 音频 文件 可 能 会 有 
一 定 程度 的 失真 。 


另外 ， 音 视频 的 “编码 和 解码 ” 既 可 以 由 纯 软 件 处 理 ， 也 可 以 借助 
于 专门 的 硬件 心 片 来 完成 。 


(2) 回放 过 程 
回放 过 程 基本 上 是 录制 过 程 的 逆向 操作 ， 即 : 


从 存储 设备 中 取出 音频 文件 ， 并 根据 录制 过 程 采 用 的 编码 方式 进行 
对 应 的 解码 ; 

音频 系统 为 这 一 播放 实例 选取 最 匹配 的 音频 回放 设备 (比如 耳机 、 
喇叭、 蓝牙 ) ; 

解码 后 的 数据 经 过 音频 系统 设计 的 路 径 进 行 传输 ; 

音频 数据 信号 通过 数 - 模 转 换 器 (DAC) 变换 成 模拟 信和 号 ; 

音频 模拟 信号 经 过 回放 设备 ， 还 原 出 原始 声音 ; 


本 章 着 重 讲解 的 是 音频 的 “回放 过 程 ”。 











13.1.3 音频 采样 


前 面 说 过 ， 数 字音 频 系统 需要 将 声波 的 波形 信号 通过 ADC 转 换 成 计 
算 机 支持 的 二 进 制 ， 进 而 保存 成 音频 文件 ， 这 一 过 程 叫 做 音频 采样 
(Audio Sampling) 。 音 频 采 样 是 众多 数字 信和 号 处 理 的 一 种 RIE 
T (比如 视频 的 采样 和 音频 采样 本 质 上 没有 太 大 
XJ) 。 


可 想 而 知 ， 采 样 (Sampling) 的 核心 是 把 连续 的 模拟 信号 转换 成 离 
散 的 数字 信号 。 它 涉及 如 下 几 个 因素 。 





e 样本 (Sample) 
即将 被 采样 的 原始 资料 ， 如 一 段 连续 的 声音 波形 。 
e。 和 采样 器 (Sampler) 
采样 器 是 将 样本 转换 成 终 态 信号 的 关键 。 它 可 以 是 一 个 子 系统 ， 也 
可 以 指 一 个 操作 过 程 ， 甚 至 一 个 算法 ， 取 决 于 不 同 的 信号 处 理 场景 。 理 
想 的 采样 器 要 求 尽 可 能 不 产生 信号 失真 。 
。 量 化 (Quantization) 
采样 后 得 到 的 值 还 需要 通过 量化 ， 即 将 连续 值 近似 为 某 个 范围 内 有 
限 多 个 离散 值 的 处 理 过 程 。 原 始 数据 是 模拟 的 连续 信号 ， 而 数字 信号 则 
是 离散 的 ， 且 数值 表达 范围 是 有 限 的 ， 所 以 量化 是 必 不 可 少 的 一 个 步 


TB 


ae) 


e 编码 (Coding) 


在 计算 机 的 世 开 里， 所 有 数值 都 是 用 二 进 制 表示 的 ， 因 而 我 们 还 需 
要 把 量化 值 进行 二 进 制 编码 。 这 一 步 通常 与 量化 同步 进行 。 


整个 流程 如 图 13-2 所 示 。 






Sampler 








全 图 13-2 PCM 流 程 


PCM (Pulse-code modulation) 俗称 “脉冲 编码 调制 ”， 是 将 模拟 
信号 数字 化 的 一 种 经 典 方式 ， 得 到 非常 广泛 的 应 用 。 比 如 数字 音频 在 计 
算 机 、DVD 以 及 数字 电话 等 系统 中 的 标准 格式 采用 的 就 是 PCM。 它 的 基本 
原理 就 是 上 面 的 几 个 流程 ， 即 对 原始 模拟 信号 进行 抽样 、 量 化 和 编码 ， 
从 而 产生 PCM 流 。 另 外 ， 我 们 可 以 调整 PCM 的 以 下 属性 来 达到 不 同 的 采样 


© 采样 速率 (Sampling Rate) 


在 将 连续 信号 转化 成 离散 信号 时 ， 融 涉及 采样 周期 的 选择 。 如 果 采 
样 周期 太 长 ， 虽 然 文件 大 小 得 到 控制 ， 但 采样 后 得 到 的 数据 很 可 能 无 法 
准确 表达 原始 信息 ; 反之 ， 如 果 采 样 频率 过 快 ， 则 最 终 产生 的 数据 量 会 
大 幅 增加 。 这 两 种 情况 都 是 我 们 不 愿意 看 到 的 ， 因 而 在 项 目 中 需要 根据 
实际 情况 来 选择 合适 的 采样 速率 。 


由 于 人 耳 所 能 辨识 的 声音 范围 是 20~20kHz， 所 以 人 们 一 般 都 选用 
44. 1kHz (CD) ，48kHz 或 者 96kHz 来 作为 采样 速率 。 





。 采样 深 度 (Bit Depth) 


我 们 知道 量化 (Quantization) 是 将 连续 值 近似 为 菜 个 范围 内 有 限 
多 个 离散 值 的 处 理 过 程 。 那 么 这 个 范围 的 宽度 以 及 可 用 离散 值 的 数量 会 
直接 影响 到 音频 采样 的 准确 性 ， 这 就 是 采样 深度 的 意义 。 


图 13-3 是 一 个 采用 4 位 深度 进行 量化 后 得 到 的 PCM。 因 为 4b it 最 多 只 
能 表达 16 个 数值 (0O~15) ， 所 以 图 中 最 终 量化 后 的 数值 依次 为 7、9、 
11, 12, 13, 14, 15 等 。 这 样 的 结果 显然 是 相对 粗糙 的 ， 存在 一 定 程 度 
的 失真 。 位 深 越 大 ， 所 能 表达 的 数值 范围 越 广 ， 上 图 中 纵 坐 标的 划分 也 
束 越 细致 ， 从 而 使 得 量化 的 值 越 接近 原始 数据 。 





全 图 13-3 采用 4-bit 深 度 的 PCM 范 例 {-:-} ( 4] A Wikipedia) 
13. 1.4 Nyquist - Shannon 采 样 定 律 


“Nyquist - Shannon” 是 由 Harry Nyquist 和 Claude Shannon 总 结 
出 来 的 采样 规律 ， 为 我 们 选择 合适 的 采样 频率 提供 了 理论 依据 。 这 个 规 
律 又 被 称 为 “Nyquist sampling theorem” 或 者 “The sampling 
theorem”， 通 常 译 为 “ 奈 硅 斯 特 采 样 理论 ”。 它 的 中 心思 想 是 : 


“ 当 对 被 采样 的 模拟 信号 进行 还 原 时 ， 其 最 高 频率 只 有 采样 频率 的 
一 半 。 33 


换 句 话说 ， 如 果 我 们 要 完整 重 构 原 始 的 模拟 信号 ， 则 采样 频率 就 必 
须 是 它 的 两 倍 以 上 。 比 如 人 的 声音 范围 是 20~ 一 20kHz， 那 么 选择 的 采样 
频率 就 应 该 在 40kHz 左 右 一 一 数值 太 小 则 声音 将 产生 失真 现象 ; 数值 太 
人 另 一 方面 无 法 明显 提升 人 耳 所 能 感知 到 的 音 





13.1.5 声 道 和 立体 声 


我 们 在 日 常生 活 中 会 经 常 听 到 单 声 道 、 双 声 道 这 些 专 业 词 语 ， 它 们 
代表 什么 意思 呢 ? 


一 个 声 道 (Audio Channel) 简单 来 讲 就 代表 了 一 种 独立 的 音频 信 
号 ， 所 以 双 声 道理 论 上 就 是 两 种 独立 音频 信号 的 混合 。 具 体 而 言 ， 如 果 
我 们 录制 声音 时 在 不 同 空间 位 置 放置 两 套 采 集 设备 〈 或 者 一 套 设 备 多 个 
REL) ， 融 可 以 录制 两 个 声 道 的 音频 数据 了 。 后 期 对 采集 到 的 声音 j 
行 回 放 时 ， 通 过 与 录制 时 相同 数量 的 外 放 扬 声 器 来 分 列 播放 各 声 道 的 音 
频数 据 ， 就 可 以 尽 可 能 还 原 出 录制 现场 的 真实 声音 环境 。 


声 道 的 数量 发 展 经 历 了 几 个 重要 阶段 ， 分 别 是 : 
e Monaural ( 单 声 道 ) 
早期 的 音频 录制 是 单 声 道 的 ， 它 只 记录 一 种 音源 ， 所 以 在 处 理 上 相 


对 简单 。 播 放 时 理论 上 也 只 要 一 个 扬声器 即 可 一 一 即便 有 多 个 扬声器 ， 
它们 的 信号 源 也 是 一 样 的 ， 达 不 到 很 好 的 效果 。 





e Stereophonic (立体 声 ) 


之 所 以 称 为 立体 声 ， 是 因为 人 们 可 以 感受 到 声音 所 产生 的 空间 感 。 
大 自然 中 的 声音 融 是 立体 的 ， 如 办 公 室 里 键盘 艇 击 声 、 马 路 上 汽车 鸣 
笛 、 人 们 的 说 话 声 等 。 那 么 ， 这 些 声音 为 什么 会 产生 立体 感 呢 ? 


我 们 知道 ， 当 “音源 ”发 声 后 〈 比 如 在 你 的 右前 方 有 人 在 讲话 ) ， 
音频 信号 将 分 别 先 后 到 达 人 类 的 双 耳 。 在 这 个 场景 中 ， 是 先 传递 到 右 耳 
然后 左 耳 ， 并 且 右 边 的 声音 比 左边 稍 强 。 这 种 细微 的 差别 通过 大 脑 处 理 
后 ， 人 们 就 可 以 判断 出 声 源 的 方位 了 。 


这 个 简单 的 原理 现在 被 应 用 到 了 多 种 场景 。 在 音乐 会 的 录制 现场 ， 
如 果 我 们 只 使 用 单 声 道 采集 ， 那 么 后 期 回放 时 所 有 的 音乐 器 材 都 会 从 一 
个 点 出 来 ; 反之 ， 如 果 能 把 现场 各 方位 的 声音 单独 记录 下 来 ， 并 在 播放 
时 模拟 当时 的 场景 ， 那 么 就 可 以 营造 出 音乐 会 的 逼真 氛围 。 


为 了 加 深 读者 的 理解 ， 我 们 特别 从 某 双 声 道 音频 文件 中 提取 出 它 的 
波形 ， 如 图 13-4 所 示 。 


顺便 以 上 面 这 个 图 为 例 再 说 一 下 音频 的 采样 频率 。 我 们 把 上 图 进行 
放大 ， 如 图 13-5 所 示 。 


图 中 共有 3 个 采样 点 ， 时 间 间 隔 是 从 4:26. 790863 到 4:26. 790908, 
即 在 大 约 0. 000045 秒 的 时 间 里 采集 了 两 个 点 ， 因 而 采样 频率 就 是 : 


1/ (0. 000045/2) =44kHz， 这 和 此 音频 文件 所 标记 的 采样 率 是 一 致 
的 。 


e 4.1 Surround Sound (4.1 环 绕 立 体 声 ) 


随 着 技术 的 发 展 和 人 们 认 知 的 提高 ， 单 纯 的 双 声 道 已 不 能 满足 需求 
了 。 于 是 更 多 的 声 道 数 逐 渐 成 为 主流 ， 其 中 被 广泛 采用 的 就 有 四 声 道 环 
绕 立 体 声 。 

其 中 的 “4” 代 表 了 4 个 音源 ， 位 置 分 别 是 前 左 (Front-Left) 、 前 
A (Front-Right) 、 后 左 (Rear-Left) 、 后 右 (Rear-Right) 。 而 小 
数 点 后 面 的 {， 则 代表 了 一 个 低音 喇叭 (Subwoofer) ， 专 门 用 于 加 强 低 


频 信号 效果 。 














全 图 13-4 双 声 道 音频 文件 


426.79086 4:26 79087, 4:25 .79088 4:26.79089 4:25 .79090 426.79091 





全 图 13-5 采样 频率 实例 
e 5.1 Surround Sound (5.1 环 绕 立 体 声 ) 


相信 大 家 都 听 过 杜 比 数字 技术 ， 这 是 众多 5. 1 环绕 声 中 的 典型 代 
表 。 男 外 ， 还 有 DTS，SDDS 等 都 属于 5. 1 技术 。5. 1 相对 于 4. 1 多 了 一 个 声 
道 ， 位 置 排列 分 别 是 前 左 、 前 右 、 中 置 (Center Channel) 和 两 个 
Surround Channe1， 外 加 一 个 低音 喇叭 。 


根据 ITU (International Telecommunication Union) 的 建议 ， 
5. 1 环绕 技术 各 扬声器 位 置 如 图 13-6 所 示 。 





全 图 13-6 ITU 发 布 的 5.1 环 绕 技 术 推 荐 方位 图 
从 图 13-6 中 可 以 得 出 。 
。 各 扬声器 和 听 者 距离 是 一 致 的 ， 因 而 组 成 一 个 圆 形 。 
。 角度 分 布 : 前 左 和 前 右 分 别 是 +22.5/22.5 度 〈 看 电影 时 ) ， 以 及 


+30//30 度 (THAR) ; 中 置 的 角度 总 是 为 0; 后 面 的 两 个 环绕 器 
分 别 为 +110//110 度 。 




















13.1.6 BABE Weber - Fechner law 


估计 知道 这 个 定律 的 人 比较 少 ， 它 是 音频 系统 中 计算 声音 大 小 的 一 
个 重要 依据 。 严 格 来 讲 ， 它 并 不 只 适用 于 声音 感知 ， 而 是 人 体 各 种 感 观 


〈 昕 觉 、 视 觉 、 触 觉 ) 与 刺激 物理 量 之 间 的 一 条 综合 规律 。 其 中 心思 想 
用 公式 表达 就 是 : 
Al/I=C 


其 中 A1 表 示 差 别 国 值 ，1 是 原先 的 刺激 量 ， 而 5C 则 是 常量 。 换 句 话 
说 ， 就 是 能 引起 “ 感 观 变化 ”的 刺激 差别 量 与 原先 的 刺激 量 比值 是 固定 
的 。 这 样 说 可 能 比较 抽象 ， 我 们 举 个 例子 来 讲解 下 。 


场合 1 去 商店 买 一 瓶 水 ， 原 本 2 元 钱 的 东西 卖 到 了 5 元 钱 。 
场合 2， 买 一 辆 奔驰 车 ， 原 先 价格 是 一 百 万 元 ， 现 在 涨 了 3 元 钱 。 


上 述 两 种 场合 下 ， 前 后 的 商品 价格 差 虽然 都 只 有 3 元 ， 但 对 我 们 造 
成 的 主观 感受 是 有 很 大 不 同 的 。 显 然 在 第 一 种 情况 下 ， 我 们 会 觉得 这 瓶 
水 很 贵 而 可 能 选择 不 买 ; 而 后 一 种 情况 则 对 我 们 基本 不 会 产生 任何 影 
响 。 这 是 因为 引起 “感官 变化 ”的 刺激 量 并 不 仅仅 取决 于 前 后 变化 量 的 
绝对 差 值 ， 同 时 也 与 原来 的 刺激 量 有 很 大 关系 。 对 于 特定 的 场合 ， 上 述 
公式 中 的 0 值 是 固定 的 。 比 如 有 的 人 觉得 2 元 钱 的 东西 卖 3 元 就 是 咯 了 ， 
有 的 人 则 能 接受 2 元 钱 的 东西 卖 4 元 ， 不 同 的 人 对 于 C 值 是 会 有 差异 的 。 


这 就 是 德国 心理 物理 学 家 Ernst Heinrich Weber 发 现 的 规律 ， 后 来 
他 的 学 生 Gustav Fechner 把 这 一 发 现 用 公式 系统 地 表达 了 出 来 ， 就 是 上 
面 的 韦伯 定律 。 


再 后 来 ，Fechner 在 此 基础 上 又 做 了 改进 。 他 提出 刺激 量 和 感知 是 
呈 对 数 关 系 的 ， 即 当 刺 激 强 度 以 几何 级 数 增长 时 ， 感 知 强度 则 以 算术 级 
数 增加 。 这 就 是 Weber - Fechner Law， 公 式 如 下 : 


S=ClogR 
那么 ， 这 对 音频 系统 有 什么 指导 意义 呢 ? 


我 们 知道 ， 系 统 音量 是 可 调 的 ， 如 分 为 0~20 个 等 级 。 这 些 等 级 又 
分 别 对 应 不 同 的 输出 电 平 值 ， 那 么 我 们 如 何 确定 每 一 个 等 级 下 应 该 设置 
的 具体 电 平 值 呢 ? 你 可 能 会 想到 平均 分 配 。 没 错 ， 这 的 确 是 一 种 方法 ， 
只 不 过 按照 这 样 的 算法 所 输出 的 音频 效果 在 用 户 听 来 并 不 是 最 佳 的 一 一 
因为 声音 的 变化 不 连续 。 


一 个 更 好 的 方案 就 是 遵循 Weber -Fechner Law， 即 采用 对 数 的 方 
式 。 在 Android 系 统 中 ， 这 一 部 分 计算 过 程 对 应 的 具体 实现 代码 在 
audiosystem. cpp 文 件 中 ， 有 兴趣 的 读者 可 以 自行 阅读 了 解 。 


13.1.7 音频 文件 格式 


前 面 小 节 的 内 容 分 析 了 音频 采样 的 基本 过 程 ， 它 将 连续 的 声音 波形 
转换 成 若干 范围 内 的 离散 数值 ， 从 而 将 音频 数据 以 二 进 制 的 形式 在 计算 
机 系统 中 表示 出 来 。 不 过 音频 的 处 理 并 没有 结束 ， 我 们 通常 还 需要 对 上 
述 过 程 产生 的 数据 进行 格式 转化 ， 然 后 才 最 终 存储 到 设备 中 。 


要 特别 注意 文件 格式 (File Format) 和 文件 编码 器 (Codec) 的 区 
别 。 编 码 器 负责 对 原始 数据 进行 一 定 的 前 期 处 理 ， 如 采用 压缩 算法 以 减 
小 体积 ， 然 后 才 以 某 种 特定 的 文件 格式 进行 保存 。Codec 和 Fi le Format 
Se ae 如 常见 的 AV1 就 支持 多 种 音频 和 视频 编码 方 
I\ o 


理论 上 可 以 把 数字 音频 格式 分 为 以 下 几 类 。 
。 不 压缩 的 格式 (UnCompressed Audio Format) 
比如 前 面 所 提 到 的 PCM 数 据 ， 就 是 采样 后 得 到 的 未 经 压缩 的 数据 。 


PCM 数 据 在 Windows 和 Mac 系 统 上 通常 分 别 以 wav 和 aiff 后 组 名 进行 存储 。 
可 想 而 知 ， 由 此 产生 的 文件 大 小 是 比较 可 观 的 。 


。 无 损 压 缩 格式 (Lossless Compressed Audio Format) 


这 种 压缩 的 前 提 是 不 破坏 音频 信息 ， 即 后 期 可 以 完整 地 还 原 出 原始 
数据 ; 同时 它 在 一 定 程度 上 可 以 减 小 文件 体积 。 目 前 已 有 多 种 实现 ， 如 
FLAC, APE(Monkey’ s Audio), WV WavPack) , da (Apple Lossless) 


。 有 损 压缩 格式 (Lossy Compressed Audio Format) 


无 损 压 缩 技术 能 减 小 的 文件 体积 相对 有 限 ， 因 而 在 满足 一 定 音 质 要 
求 的 情况 下 ， 我 们 还 可 以 进行 有 损 压缩 。 其 中 ， 最 为 人 所 熟知 的 当然 是 
MP3 格 式 以 及 iTunes 上 使 用 的 AAC。 通 常 这 些 格式 都 可 以 指定 压缩 的 比率 
一 一 比率 越 大 ， 文 件 体 积 越 小 ， 但 效果 也 越 差 。 


ae a 种 格式 ， 大 家 要 视 具 体 的 使 用 场景 而 定 ， 并 没有 固定 


13.2 IMER 


Android 的 音频 系统 在 很 长 一 段 时 间 内 都 是 外 青 诉 病 的 焦点 。 的 
确 ， 早 期 的 Android 系 统 在 音频 处 理 上 相 比 于 i0S 有 一 定 的 差距 ， 这 也 是 
很 多 专业 的 音乐 播放 软件 开发 商 没 有 推出 Android 平 台 产品 的 一 个 重要 
原因 。 但 这 并 不 代表 它 的 音频 框架 一 无 是 处 ， 基 于 Linux 系 统 的 Android 
平台 却 有 很 多 值得 我 们 学 习 的 地 方 。 


13.2.1 Linux 中 的 音频 框架 


在 计算 机 发 展 的 早期 ， 电 脑 的 声音 处 理 设备 是 由 一 个 非常 简易 的 
LoudSpeaker 外 加 发 声 器 (Tone Generator) 构成 的 ， 功 能 相对 局 限 。 
后 来 人 们 想到 了 以 Plug-in 的 形式 来 扩展 音频 设备 ，“Sound 
Blaster” 就 是 其 中 很 有 名 的 一 个 。 这 种 早期 的 声卡 以 插件 方式 连接 到 
电脑 主板 上 ， 并 提供 了 各 种 复杂 的 音频 设备 。 但 是 ， 独 立 的 硬件 设计 也 
意味 着 成 本 的 增加 ， 于 是 随 着 技术 的 发 展 又 出 现 了 “ 板 载 声卡 ”， 即 我 
们 俗称 的 “和 集成 声卡 ”。“ 板 载 声 卡 ” 又 分 为 “ 软 声卡 ”和 “ 硬 声 
如 果 声 卡 本 身 没 有 “ 主 处 理 ” 芯 片 ， 而 只 有 解码 芯片 ， 需 要 通 
过 CPU 运算 来 执行 处 理工 作 ， 那 么 就 是 “ 软 声 卡 ”; 反之 就 是 “ 硬 声 
ey 通常 面向 低 端 市 场 的 计算 机 都 会 包含 一 个 集成 的 声卡 设备 以 降低 


一 个 典型 的 声卡 通常 包含 3 个 部 分 。 





e Connectors 


用 于 声卡 与 外 放 设 备 ， 如 扬声器 、 耳 机 的 连接 ， 又 被 称 
为 “jacks”。 


e Audio Circuits 


声卡 的 主要 实现 体 ， 负 责 信号 的 放大 、 混 音 以 及 模拟 数字 信号 转换 
等 操作 。 


e Interface 


连接 声卡 与 计算 机 总 线 的 单元 ， 如 PC1 总 线 。 


我 们 可 以 通过 “cat /proc/asound/cards” 命 令 来 查看 计算 机 中 安 
装 的 声卡 设备 ， 如 范例 所 示 。 
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目前 市 面 上 声卡 的 种 类 众多 ， 既 有 复杂 的 高 性 能 的 ， 也 有 低 端的 简 
另 的 。 那 么 对 于 一 个 操作 系统 来 说 ， 它 如 何 党 理 这 些 音 频 设备 并 向 上 层 
应 用 提供 统一 的 接口 呢 ? 


Android 严 格 来 讲 只 是 一 个 Linux 系 统 ， 它 依赖 于 内 核 提 供 的 各 种 驱 
动 支持 ， 其 中 自然 也 包括 音频 驱动 。 因 此 ， 我 们 有 必要 先 花 点 时 间 来 学 
习 下 Linux 平 台 下 两 种 主要 的 音频 驱动 架构 。 


e OSS (Open Sound System) 


早期 Linux 版 本 采用 的 是 0SS 框 架 ， 它 也 是 UN1X 及 类 UN1X 系 统 中 广泛 
使 用 的 一 种 音频 体系 。0SS 既 可 以 指 0SS 接 口 本 身 ， 也 可 以 用 来 表示 接口 
的 实现 。0SS 的 作者 是 Hannu Savolainen， 就 职 于 4Front Technologies 
公司 。 由 于 涉及 知识 产权 问题 ，0SS 后 期 的 支持 与 升级 不 是 很 好 ， 这 也 
是 Linux 内 核 最 终 放弃 0SS 的 一 个 重要 原因 。 


AW, OSSH#REA MBS TAMAR. ECA: 

对 音频 新 特性 的 支持 不 中 ; 

缺乏 对 最 新 内 核 特性 的 支持 等 。 

当然 ，0SS 作 为 UNIX 下 音频 系统 的 早期 实现 ， 本 身 算 是 比较 成 功 
的 。 它 符合 “一 切 都 是 文件 ”的 设计 理念 ， 而 且 作 为 一 种 体系 框架 ， 其 
更 多 地 只 是 规定 了 应 用 程序 与 操作 系统 音频 驱动 之 间 的 交互 ， 这 给 各 厂 


商 进行 产品 定制 开发 提供 了 很 多 灵活 性 。 总 的 来 说 ，0SS 使 用 了 如 表 13- 
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表 13-1 0SS 采 用 的 设备 节点 





/dev/dsp 问 此 文件 写 数 据 > 输出 到 外 放 Speaker 
回 此 文件 读数 据 ”> 通过 Microphone 进 行 录音 


混 首 器 ， 用 于 对 首 频 设备 进行 相关 设置 ， 如 首 量 
调 市 


第 一 个 MIDI 端 口 ， 还 有 midi01，midi02 等 


用 于 访问 合成 器 (synthesizer) ， 常 用 于 游戏 音 
/dev/sequencer 效 的 产生 





更 多 详情 可 以 参考 0SS 的 官方 说 明 。 
e ALSA(Advanced Linux Sound Architecture) 


ALSA 是 Li nux 社 区 为 了 取代 0SS 而 提出 的 一 种 框架 ， 是 一 个 源 代 码 完 
全 开放 的 系统 (遵循 GNU GPL 和 GNU LGPL) 。ALSA 在 Kernel 2. 5 版 本 中 
被 正式 引入 后 ，0SS 就 逐步 被 排除 在 内 核 之 外 。 当 然 ，0SS 本 身 还 是 在 不 
断 维护 的 ， 只 是 不 再 为 Kerne1 所 采用 而 已 。 


ALSA 相 对 于 0SS 提 供 了 更 多 也 更 为 复杂 的 AP1 接 口 ， 因 而 开发 难度 相 


对 来 说 比较 大 。 为 此 ，ALSA 专 门 提供 了 一 个 供 开 发 者 使 用 的 工具 库 ， 以 
帮助 他 们 更 好 地 利用 ALSA 的 AP1。 根 据 官方 文档 的 介绍 ，ALSA 有 如 下 特 
性 。 


e 高 效 地 支持 大 多 数 类 型 的 Audio Interface (不 论 是 消费 型 还 
是 专业 型 的 多 声 道 声卡 ) 。 

° 高 度 模块 化 的 声音 驱动 。 

° SMP 及 线程 安全 (Thread-Safe) 设计 。 


° 在 用 户 空间 提供 了 alsa-1ib 来 简化 应 用 程序 的 编写 。 


° 与 0SS AP1 保 持 兼 容 ， 这 样 可 以 保证 老 的 0SS 程 序 在 系统 中 能 


常 运 行 。 
ALSA 主 要 由 表 13-2 所 示 的 几 个 部 分 组 成 。 


表 13-2 Alsa-Project Package 





ic, pen 
river 
aoib ee 





包含 了 很 多 实用 的 小 程序 ， 如 alsactl: 用 于 保存 设备 
配置 amixer: 是 一 个 命令 行程 序 ， 用 于 音量 和 其 他 声 
音 控制 alsamixer: amixer 的 ncurses 厂 acconnect 和 
aseqview: 用 于 制作 MIDI 连 接 以 及 检查 已 连接 的 端口 
列表 aplay 和 arecord: 两 个 命令 行程 序 ， 分 别 用 于 播放 
和 录制 多 种 格式 的 音频 


包含 一 系列 工具 程序 


音频 固件 文 持 包 


插件 包 ， 如 jack，pulse，maemo 


ica | 用 于 兼容 OSS 的 模拟 包 
用 于 编译 Python 版 本 的 alsa lib 





Alsa 主 要 的 文件 节点 如 下 : 
(1) Information Interface (/proc/asound) ; 
(2) Control Interface (/dev/snd/controlCx) ; 
(3) Mixer Interface (/dev/snd/mixerCXDX) ; 
(4) PCM Interface (/dev/snd/pcmCXDxX) ; 
(5) Raw MIDI Interface (/dev/snd/midiCXDX) ; 
(6) Sequencer Interface (/dev/snd/seq) ; 
(7) Timer Interface (/dev/snd/timer) 。 


关于 ALSA 的 更 多 知识 ， 建 议 读者 自行 参阅 相关 文档 ， 这 对 于 后 续 理 
解 Android 中 的 Audio 系 统 架 构 大 有 神 益 。 


13.2.2 TinyAlsa 


看 到 “Tiny” 这 个 词 ， 大 家 应 该 能 猜 到 这 是 一 个 ALSA 的 缩减 版 本 。 
实际 上 在 Android 系 统 的 其 他 地 方 也 可 以 看 到 类 似 的 做 法 一 一 因为 我 们 
既 想 用 开源 项 目 ， 又 担心 工程 太 大 太 烦 琐 ， 怎 么 办 ? 那 就 只 能 瘦身 ， 于 
是 很 多 Tiny-XXX 就 出 现 了 。 


早期 版 本 中 ，Android 系 统 的 音频 架构 主要 是 基于 ALSA 的 ， 其 上 层 
实现 可 以 看 作 ALSA 的 一 种 “应 用 ”。 后 来 可 能 是 由 于 ALSA 所 存在 的 一 些 
不 足 ，Android 系 统 开始 不 再 依赖 于 ALSA 提 供 的 用 户 空间 层 的 实现 。 这 
也 是 我 们 在 它 的 库 文件 夹 中 逐渐 找 不 到 alsa 相 关 1ib 的 原因 ， 如 图 13-7 
所 示 。 





| 8 @lib 





& egl 
& hw 
B invoke mock media player. so 5292 
国 1ibEGL. so 136732 
(=) 1ibETC1. so 9320 
国 LibFFTEm. so 185604 
>) 1ibGLES_trace. so 266268 
=) 1ibGLESv1_CH. so 21560 
E| 1ibGLESv1_enc. so 115924 
E] 1ibGLESv2. so 21560 
E| 1ibGLESv2_enc. so 95444 
国 1ibOpenMAXAL. so 9328 
国 1ibOpenSLES. so 9328 
B lib0penglSystemCommon. so 9436 
E] 1ibRS. so 541808 
国 1ibSR_AudioIn. so 5280 
B libtinnEngDic. so 1192648 
国 lib¥nnJpnDic. so 1341536 
B lib_renderControl_enc. so 13532 
=) libaah_rtp. so 99604 
E| libandroid. so 58580 
E] libandroid_runtime. so 635420 
B libandroid_servers. so T2040 
B| libandroidfw. so 202160 
E| libasan_preload. so 58696 
| B libaudioeffect_jni. so 17956 


libaudioflinger. so 3086 
libaudioutils. so 9328 
Tihhee en ATRAAT? 





piup mp 





E| 1ibOpenMAXAL. so 5548 
=) 1ibOpenSLES. so 9680 
=) libOpenVG. so 255824 
=) libQceomUT. so 9680 
=) 1ibRS. so 565588 
=) 1ibSR_AudioIn. so 5432 
=) 1ibTRIM. so 389488 
B Lib#¥StreamControlAPI_L3. so 2455800 
=) libace. so 35100 
=) libaddrsdetection. so 1854924 
=) libalbum_util2. so 9968 
国 libandroid. so 60960 
国 libandroid_runtime. so 945832 
=) libandroid_servers. so 78540 
B libandroid_simlock. so 5520 
B libaricentomxplugin. so 1540276 
E| libaudeal. so 1201296 
E| libaudcal_nel. so 1205328 
=) libaudcalwb. so 1205360 
B libaudioalsa. so 9512 
=) libaudioeffect_jni. so 16212 
È libaudioflinger. so 

=) libaudiofp. so TT1168 
=) libbce. so 4512772 


全 图 13-7 Android 新 老 版 本 在 音频 库 上 的 区 别 


而 取代 它 的 是 tinyalsa 相 关 的 库 文 件 ， 如 图 13-8 所 示 。 


| libsysutils. so 21716 








E| libthread_db. so 5332 
È libtinyalsa. so 

国 libttscompat. so 9580 
E| libttspico. so 199260 
|=) libui. so 33996 
EN asa 11 i name 


A 13-8 Tinyalsa 取 代 Alsa-lib 


同时 我 们 可 以 看 到 ，extern1 目 录 下 多 了 一 个 “tinyalsa” 文 件 
夹 ， 其 中 包含 了 为 数 不 多 的 几 个 源码 文件 ， 如 表 13-3 所 示 。 


表 13-3 Tiny-alsa 工 程 文件 







Source File Description 


include/tinyalsa/asoundlib.h xe | 





可 见 TinyAlsa 与 原版 Al sa 的 差异 还 是 相当 大 的 ， 它 只 是 部 分 支持 了 
其 中 的 两 种 Interface。 而 像 Raw MID1、Sequencer 、Timer 等 Interface 
则 没有 涉及 一 一 当然 这 对 于 一 般 的 能 入 式 设 备 来 说 还 是 足够 了 。 


TinyAlsa 作 为 Alsa-1ib 的 一 个 替代 品 ， 自 面世 以 来 得 到 的 公众 评价 
有 到 有 贬 ， 不 能 一 概 而 论 一 一 对 于 厂商 来 说 ， 适 合 自己 的 就 是 最 好 的 ; 
而 且 各 厂商 也 可 以 在 此 基础 上 扩展 自己 的 功能 ， 真 正 地 把 ALSA 应 用 到 极 
致 。 


13.2.3 ”Android 系 统 中 的 音频 框架 
一 个 好 的 系统 架构 需要 尽 可 能 地 降低 上 层 实现 与 具体 硬件 设备 的 耦 


合 一 一 这 其 实 是 操作 系统 的 设计 目标 之 一 ， 当 然 也 同样 适用 于 音频 系 
统 。 音 频 系 统 的 欠 形 框架 可 以 简单 地 用 图 13-9 来 表示 。 


在 简 图 中 ， 除 去 Linux 本 身 的 Audio 驱 动 外 ， 整 个 Android 音 频 体系 
都 被 看 成 了 User。 因 而 我 们 可 以 认为 Audio Driver 就 是 上 层 用 户 与 硬件 
间 的 “隔离 板 ”。 但 是 如 果 单 纯 采 用 上 图 所 示 的 框架 来 设计 音频 系统 ， 
对 于 使 用 音频 功能 的 上 层 应 用 则 是 个 不 小 的 负担 。 显 然 “ 绝 顶 聪 明 ” 的 
Android 开 发 团队 还 会 进一步 细 化 “User ”部 分 。 


细 化 的 依据 自然 还 是 Android 的 几 个 层次 结构 ， 包 括 应 用 层 、 
framework 层 、 库 层 和 HAL 层 ， 如 图 13-10 所 示 。 


Audio Driver 


Hardware 





全 图 13-9 ”音频 系统 的 锥 形 框 架 图 


/ N 
全 
YZ 


Framework 


Audio Lib 


全 图 13-10 ”音频 框架 在 Andtoid 系 统 中 的 进一步 细 化 


我 们 可 以 结合 目前 已 经 学 习 过 的 知识 ， 思 考 一 下 图 13-10 中 每 一 个 
层次 所 需要 完成 的 任务 先 不 考虑 蓝牙 音频 部 分 ) 。 


1. APP 


这 是 整个 音频 体系 的 最 上 层 。 比 如 厂商 根据 特定 需求 写 的 一 个 音乐 
播放 器 ; 游戏 中 的 音效 控制 ; 或 者 调节 音频 属性 的 应 用 软件 等 。 





2. Framework 


相信 读者 可 以 立即 想到 MediaPlayer 和 MediaRecorder， 因 为 这 是 我 
们 在 开发 音频 相关 产品 时 使 用 最 广泛 的 两 个 类 。 另 外 ，Android 系 统 中 
还 有 另外 两 个 专门 用 于 音频 管理 的 类 ， 即 AudioTrack 和 AudioRecorder 
MediaPlayerService 内 部 的 音频 实现 其 实 就 是 通过 它们 来 完成 的 。 
我 们 后 面 还 会 有 详细 介绍 。 

除 此 之 外 ，Android 系 统 还 为 我 们 控制 音频 系统 提供 了 
AudioManager 、AudioServi ce 及 AudioSystem 类 。 这 些 都 是 framework 层 


面向 应 用 开发 者 设计 的 封装 实现 。 


3. Libraries 





我 们 知道 ，Framework 层 的 很 多 Java 类 实际 上 只 是 APK 应 用 程序 与 
Android 库 文件 的 “中 介 ” 而 已 。 因 为 上 层 应 用 程序 采用 Java 语 言 编 
写 ， 它 们 需要 最 直接 的 Java 接 口 的 支持 ， 这 也 是 Framework 层 存在 的 意 
义 之 一 。 而 作为 “中 介 ”， 它 们 并 不 会 真正 去 实现 或 者 说 只 实现 了 其 中 
的 一 小 部 分 功能 一 一 真正 的 “主角 ”隐藏 在 底层 库 中 。 


需要 特别 说 明 的 是 ，Android 系 统 中 与 音频 相关 的 库 有 很 多 。 


比如 上 面 的 AudioTrack、AudioRecorder 、MediaPlayer 和 
MediaRecorder 等 在 底层 库 中 都 能 找到 相对 应 的 类 〈 这 部 分 库 的 源码 集 
中 放置 在 工程 的 frameworks/av/media/1ibmedia 中 ， 多 数 是 以 C++ 语 言 
编写 的 ) o 


除了 上 面 各 种 类 库 的 实现 外 ， 音 频 系统 还 需要 一 个 “核心 中 控 ”。 
或 者 更 通俗 地 说 ， 需 要 一 个 系统 服务 〈 类 似 于 WindowManagerService、 
LocationManagerService、ActivityManagerService 等 ) ， 这 就 是 
AudioFlinger 和 AudioPolicyService。 它 们 的 源码 放置 在 
frameworks/av/services/audioflinger 目 录 中 ， 生 成 的 最 主要 的 库 名 
叫 作 1ibaudioflinger。 


音频 体系 中 另 一 个 重要 的 系统 服务 是 MediaPlayerService， 它 的 位 
置 在 frameworks/av/media/ libmediaplayerservice 中 。 


因为 涉及 的 库 和 相关 类 很 多 ， 建 议 读者 在 学 习 的 时 候 分 为 两 条 线 


其 一 ， 以 “ 库 ” 为 线索 。 比 如 AudioPolicyService 和 AudioFlinger 
都 封装 在 1ibaudioflinger 库 中 ; 而 AudioTrack，AudioRecorder 等 一 系 
列 实现 则 在 1ibmedia 库 中 。 


其 二 ， 以 “进程 ”为 线索 。“ 库 ”并 不 代表 一 个 进程 ， 进 程 则 依赖 
于 库 来 运行 。 虽 然 有 的 类 是 在 同一 个 库 中 实现 的 ， 但 并 不 代表 它们 会 在 
同一 个 进程 中 被 调用 。 比 如 AudioFlinger 和 AudioPolicyService 都 驻 留 
于 名 为 mediaserver 的 系统 进程 中 ; 而 AudioTrack/AudioRecorder 和 
MediaPlayer/MediaRecorder 一 样 实际 上 只 是 应 用 进程 的 一 部 分 ， 它 们 
通过 Binder 服 务 来 与 其 他 系统 进程 通信 。 


人 aires 
方向 ” . 


4. HAL 


从 设计 层面 来 看 ， 音 频 的 硬件 抽象 层 的 服务 对 象 是 AudioF 1 inger 。 
这 一 方面 说 明了 AudioFlinger 可 以 不 用 直接 调用 底层 的 音频 驱动 ; 另 一 
方面 AudioFlinger 的 上 层 〈 包 括 和 它 同一 层 的 MediaPlayerService) 模 
块 只 需要 与 它 进 行 通信 就 可 以 实现 音频 相关 的 功能 了 。 因 而 我 们 可 以 认 
为 AudioF 1inger 才 是 Android 音 频 系统 中 真正 的 “隔离 板 ” 一 一 无 论 下 
面 如 何 变化 ， 上 层 的 实现 都 可 以 保持 兼容 。 


音频 方面 的 硬件 抽象 层 主 要 分 为 两 个 核心 ， 即 AudioF 1inger 和 
AudioPolicyService。 实 际 上 后 者 (Policy) 并 不 是 一 个 真实 的 设备 ， 
人 


抽象 层 的 任务 是 将 AudioFlinger/AudioPolicyService 真 正 地 与 硬 
件 设备 关联 起 来 ， 但 又 必须 提供 灵活 的 结构 来 应 对 变化 特别 是 对 于 
Android 这 个 更 新 相当 频繁 的 系统 。 比 如 早期 Android 系 统 中 的 Audio 体 
系 依赖 于 内 核 的 ALSA-1ib， 后 来 就 变 为 了 tinyalsa， 这 样 的 转变 不 应 该 
也 不 允许 对 上 层 造成 “破坏 ”。 因 而 Audio HAL 提 供 了 统一 的 接口 来 定 
义 它 与 AudioFlinger/AudioPolicy Service 之 间 的 通信 方式 ， 这 就 是 
audio hw device, audio stream in 及 audio stream out 等 结构 体 存 在 
的 目的 。 这 些 Struct 数 据 类 型 内 部 大 多 只 包含 了 对 函数 指针 的 定义 ， 或 
者 说 是 一 些 “ 壳 ”。 当 AudioFlinger/AudioPolicyService 初 始 化 时 ， 
它们 会 去 寻找 系统 中 最 匹配 的 实现 〈 这 些 实现 驻 留 在 以 





audio. primary. *Mzaudio. a2dp. *AZWSAE) 来 填充 这 
此 an i 

根据 具体 产品 的 不 同 ， 音 频 设 备 存在 很 大 差异 。 在 Android 的 音频 
架构 中 ， 这 些 差异 问题 都 是 由 HAL 层 的 audio. primary 等 库 来 解决 的 ， 而 
不 需要 大 规模 地 修改 上 层 实 现 。 


基于 上 面 的 分 析 ， 我 们 给 出 一 个 完整 的 Android 首 频 系 统 框 架 供 读 
者 参考 〈 没 有 列 出 Linux 层 的 实现 ， 如 ALSA Dr iver 等 ) ， 如 图 13-11 所 
不 。 

本 章 剩余 小 节 将 分 别 介绍 上 述 框架 图 里 的 几 个 重点 模块 ， 包 括 
AudioFlinger, AudioTrack/ AudioRecorder、 
AudioManager/AudioPolicyService， 并 简单 地 介绍 音频 上 层 建 筑 中 的 
一 些 核心 模块 如 MediaPlayerService 等 。 
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全 图 13-11 Android 音 频 系 统 框 架 全 图 





13.3 音频 系统 的 核心 


在 上 面 的 框架 图 中 ， 我 们 可 以 看 到 AudioF linger 〈 下 面 简 称 AF) 是 
整个 音频 系统 的 核心 与 难点 。 作 为 Android 系 统 的 音频 中 枢 ， 它 同时 也 
是 一 个 系统 服务 ， 起 到 承 上 〈 为 上 层 提供 访问 和 管理 音频 的 接口 ) AE 

(通过 HAL 来 管理 音频 设备 ) 的 作用 。 只 有 理解 了 AudioFlinger， 才 能 
以 此 为 基础 扩展 深入 其 他 模块 的 学 习 中 ， 因 而 我 们 把 它 放 在 前 面 分 析 。 


AudioF | inger 


13.3.1 AudioFlinger 服 务 的 启动 和 运行 


我 们 知道 ，Android 中 的 系统 服务 分 为 两 类 ， 分 别 是 Java 层 和 
Native 层 的 System Services。 其 中 AudioFlinger 和 SurfaceFlinger 一 
样 ， 都 属于 后 者 。Java 层 服务 通常 在 SystemServer. java 中 启动 ， 如 后 
面 即 将 看 到 的 AudioService 就 属于 这 种 情况 ; 而 Native 层 服务 则 通常 是 
各 服务 方 按照 自己 的 部 署 来 决定 何 时 局 动 以 及 如 何 局 动 的 。 例 如 
AudioFlinger 就 是 利用 一 个 Linux 程 序 来 间接 创建 的 ， 如 下 所 示 : 


/*frameworks/av/media/mediaserver/Main mediaserver.cpp*/ 

int main(int argc, char** argv) 

{..//4.3 版 本 中 考虑 了 MediaLogService， 但 不 影响 我 们 的 分 析 ， 可 以 直接 略 过 
sp<ProcessState> proc(ProcessState::self()); 
sp<IServiceManager> sm = defaultServiceManager(); 
ALOGI("ServiceManager: %p", sm.get()); 

AudioFlinger: :instantiate(); 
MediaPlayerService: :instantiate(); 
CameraService: :instantiate(); 
AudioPolicyService: :instantiate()j; 
registerExtensions(); 
ProcessState::self()->startThreadPool(); 
IPCThreadState: :self()->joinThreadPool(); 


这 个 mediaserver 的 目录 下 只 有 少数 几 个 文件 。 它 的 任务 很 简单 ， 
就 是 把 所 有 媒体 相关 的 native 层 服务 “包括 AudioF linger, 
MediaPlayerService，CameraService 和 AudioPolicyService) 启动 起 
来 。 可 以 参考 其 Android. mk: 


LOCAL_SRC_FILES:= \ 
main_mediaserver .cpp 


LOCAL_SHARED_LIBRARIES := \ 
libaudioflinger \ 
libcameraservice \ 
libmedialogservice \ 
libcutils \ 
libnbaio \ 
libmedia \ 
libmediaplayerservice \ 


LOCAL_MODULE:= mediaserver 


根据 前 面 的 分 析 ，AudioFlinger 的 源码 实现 是 放 在 
libaudioflinger 库 中 的 ， 因 而 在 编译 mediaserver 时 要 引用 这 个 库 ， 其 
他 服务 也 是 类 似 的 做 法 。 编 译 生成 的 mediaserver 可 执行 文件 将 被 烧 录 
到 设备 的 /system/bin/mediaserver 路 径 中 ， 然 后 当 系 统 开 机 时 由 init 
进程 局 动 ， 其 在 Init. rc 中 的 对 应 配置 是 : 


service media /system/bin/mediaserver 
class main 
user media 
group audio camera inet net_bt net_bt_admin net_bw_acct drmrp 
ioprio rt 4 


值得 一 提 的 是 ，AudioF linger: :instantiate() 并 不 属于 
AudioFlinger 内 部 的 静态 函数 ， 而 是 BinderService 类 的 一 个 实现 。 包 
括 AudioFlinger，AudioPolicyService 等 在 内 的 几 个 服务 都 继承 自 这 个 
统一 的 Binder 服 务 类 。 比 如 : 


class AudioFlinger : 
public BinderService<AudioFlinger>, 
public BnAudioFlinger... 


从 名 称 上 看 ，BinderService 应 该 是 实现 了 Binder 跨 进程 通信 相关 
的 一 些 功能 。 实 际 上 它 是 一 个 模板 类 ， 其 中 的 函数 instantiate 用 于 把 
模板 中 指定 的 服务 创建 出 来 ， 并 添加 到 ServiceManager 中 : 


/*frameworks/native/include/binder/BinderService.h*/ 
template<typename SERVICE> ... 
static status_t publish(bool allowIsolated = false) { 
sp<IServiceManager> sm(defaultServiceManager()); 
return sm->addService(Stringi6(SERVICE: :getServiceName() ) 


} 
static void instantiate() { publish(); } // 调 用 publish 


回头 看 看 AudioF |inger 的 构造 函数 ， 发 现 它 只 是 简单 地 为 内 部 一 些 
变量 做 了 初始 化 ， 除 此 之 外 就 没有 任何 有 效 的 代码 了 其 他 部 分 源码 与 
log 和 debug 有 关 ， 可 以 忽略 不 计 ) : 


AudioFlinger: :AudioFlinger() 
:BnAudioFlinger(),mPrimaryHardwareDev(NULL), mHardwareStatus( 
mMasterVolume(1.0f), mMasterMute(false), mNextUniquelId(1), 
mMode(AUDIO_MODE_INVALID),mBtNrecIsOff(false) {... 


读者 可 能 会 党 得 疑惑 ， 即 AudioF 1inger 在 什么 情况 下 会 开始 执行 实 
际 的 工作 呢 ? 没 错 ， 是 在 onFirstRef (中 。BnAudioFlinger 是 由 
RefBase 层 层 继承 而 来 的 ， 并 且 1ServiceManager : :addService 的 第 二 个 
参数 实际 上 是 一 个 强 指针 引用 (const sp<lBinder>&) ， 因 而 
AudioFlinger 具 备 了 “ 强 指针 被 第 一 次 引用 时 调用 onFirstRef” 的 程序 
逻辑 。 如 果 读 者 不 是 很 清楚 这 些 细节 ， 可 以 参考 下 本 书 的 强 指 针 章 节 ， 
REAR: 


void AudioFlinger: :onFirstRef() 


{ 
int rc = 0; 
Mutex::Autolock _1(mLock); 
char val_str[PROPERTY_VALUE_MAX] = { 0 }; 
if (property_get("ro.audio.flinger_standbytime_ms", val_str, 
uint32_t int_val; 
if (1 == sscanf(val_str, "%u", &int_val)) { 
mStandbyTimeInNsecs = milliseconds(int_val); 
ALOGI("Using %u mSec as standby time.", int_val); 
} else { 
mStandbyTimeInNsecs = kDefaultStandbyTimeInNsecs; 
} 
} 
mMode = AUDIO_MODE_NORMAL; 
J 


属性 ro. audio. flinger_standbyt ime_ms 为 用 户 调整 standby 时 间 提 
供 了 一 个 接口 ， 早 期 版 本 中 这 个 时 间 值 是 固定 的 。 接 下 来 程序 会 初始 化 
几 个 重要 的 内 部 变量 一 一 和 前 面 AudioFlinger 构 造 函 数 中 的 做 法 不 同 的 
是 ， 这 里 赋予 各 变量 的 都 是 有 效 的 值 。 


从 这 时 开始 ，AudioF1inger 就 是 一 个 “有 意义 ”的 实体 了 。 接 下 来 
其 他 进程 可 以 通过 Service Manager 来 访问 AudioFlinger， 并 调用 








createTrack，open0utput 等 一 系列 接口 来 驱使 AudioFlinger 执 行 音频 
处 理 操作 ， 我 们 在 后 续 小 节 会 做 详细 讲解 。 


13.3.2 AudioFlinger 对 音频 设备 的 管理 


虽然 AudioF1inger 实 体 已 经 成 功 创建 并 初始 化 ， 但 到 目前 为 止 它 还 
没有 涉及 具体 的 工作 。 


从 职能 分 布 上 来 讲 ，AudioPolicyService 是 策略 的 制定 者 ， 如 什么 
时 候 打 开 音 频 接 口 设 备 、 某 种 Stream 类 型 的 音频 对 应 什么 设备 等 都 由 其 
决定 。 而 AudioF linger 则 是 策略 的 执行 者 ， 如 具体 如 何 与 音频 设备 进行 
通信 、 如 何 维护 现 有 系统 中 的 音频 设备 以 及 多 个 音频 流 的 “ 混 音 ”如 何 
处 理 等 都 得 由 它 来 完成 。 


目前 Aud io 系统 中 支持 的 音频 设备 接口 (Audio Interface) 分 为 3 
AX, Bl: 


/*frameworks/av/services/audiof linger/AudioFlinger.cpp*/ 
static const char * const audio_interfaces[] = { 
AUDIO_HARDWARE_MODULE_ID_PRIMARY, // 主 音频 设备 ， 必 须 存 在 
AUDIO_HARDWARE_MODULE_ID_A2DP, // 蓝 牙 A2DP 音 频 
AUDIO_HARDWARE_MODULE_ID_USB，//USB 音 频 ， 早 期 的 版 本 不 支持 
}; 


每 种 音频 设备 接口 由 一 个 对 应 的 “so 库 ” 来 提供 支持 。 那 么 
AudioFlinger 怎 么 会 知道 当前 设备 中 支持 上 述 的 哪些 接口 ， 每 种 接口 又 
支持 哪些 具体 的 音频 设备 呢 ? 这 是 AudioPolicyService 的 责任 之 一 ， 即 
根据 用 户 配 置 来 指导 AudioF1inger 加 载 设备 接口 。 


当 AudioPolicyManagerBase (AudioPolicyService 中 持 有 的 Policy 
管理 者 ， 后 面 小 节 有 详细 介绍 ) 构造 时 ， 它 会 读 取 厂商 关于 音频 设备 的 
描述 文件 (audio_policy. conf) ， 然 后 据 此 来 打开 以 上 3 类 音频 接口 
《如 果 存 在 的 话 ) 。 这 一 过 程 最 终 会 调用 
|loadHwModule@AudioFlinger, 20 Atm: 
/*frameworks/av/services/audiof linger */ 


audio_module_handle_t AudioFlinger::loadHwModule(const char *name 
interfaces 数 组 成 员 中 的 字符 串 */ 


if (!settingsAllowed()) { 
return 0; 


} 
Mutex: :Autolock _1(mLock); 
return loadHwModule_1l(name) ; 


这 个 函数 没有 做 实质 性 的 工作 ， 只 是 执行 了 加 锁 动 作 ， 然 后 接着 调 
用 下 面 的 函数 : 


audio_module_handle_t AudioFlinger::loadHwModule_1l(const char *na 


/*Step 1. eA OE 条 添加 过 这 个 ijnterface?*/ 
for (size_t i = 0; i < mAudioHwDevs.size(); i++) { 
if (strncmp(mAudioHwDevs.valueAt (i) ->moduleName(), name, 
ALOGW("loadHwModule() module %s already loaded", name 
return mAudioHwDevs.keyAt(i); 


} 


/*Step 2. 加 载 audio interface*/ 
audio_hw_device_t *dev; 
int rc = load_audio_interface(name, &dev); 


/*Step 3. 初始 化 */ 

mHardwareStatus = AUDIO_HW_INIT; 
= dev->init_check(dev); 

mHardwareStatus = AUDIO_HW_IDLE; 


/*Step 4. 添加 到 全 局 变量 中 */ 
audio_module_handle_t handle = nextUniqueId(); 
mAudioHwDevs.add(handle, new AudioHwDevice(name, dev,flags)); 





return handle; 


Step1@loadHwModule_|. dag tery vee tla B 经 添加 了 
变量 name 所 指示 的 audio interface， 如 果 是 就 直接 返回 。 第 一 次 进入 
时 mAudioHwDevs 的 size 为 0， 所 以 


Step2@ loadHwModule_1。 加 载 指定 的 audio interface, 
Qo “primary” “a2dp” 3# “usb” . Æ load audio_interface 用 来 
加 载 设备 所 需 的 库 文件 ， 然 后 打开 设备 并 创建 一 个 audio_hw_device_t 
实例 。 音 频 接 口 设备 所 对 应 的 库 文件 名 称 是 有 一 定格 式 的 ， 如 a2dp 的 模 
块 名 可 能 是 audio. a2dp. so 或 者 audio. a2dp. default. so 等 。 查 找 路 径 主 
要 有 两 个 ， 即 : 


/** Base path of the hal modules */ 
#define HAL_LIBRARY_PATH1 "/system/1ib/hw" 
#define HAL_LIBRARY_PATH2 "/vendor/1lib/hw" 


当然 ， 因 为 Androi d 是 完全 开源 的 ， 各 开发 商 可 以 根据 自己 的 需求 
来 进行 相应 的 修改 。 比 如 下 面 是 某 手 机 设备 的 音频 库 截 图 ， 如 图 13-12 
所 示 。 
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全 图 13-12 音频 库 实例 


Step3@ loadHwModule 1。 进行 初始 化 操作 。 其 中 init_check 是 为 
了 确定 这 个 audio interface 是 否 已 经 成 功 初 始 化 ，0 是 成 功 ， 其 他 值 表 
示 失 败 。 接 下 来 如 果 这 个 device 支 持 主 音量 ， 我 们 还 需要 通过 
set_master_volume 进 行 设 置 。 应 该 特别 注意 的 是 ， 每 次 操作 devi ce 
前 ， 都 要 求 先 改变 mHardwareStatus 的 状态 值 ， 操作 结束 后 再 将 其 复原 
为 AUD10_HW_IDLE 〈 根 据 源 这 样 做 是 为 了 方便 dump 时 正确 
输出 内 部 状态 ， 我 们 就 不 去 深究 了 


Step4@ loadHwModule 1。 把 加 载 后 的 设备 添加 入 mAudioHwDevs 键 
值 对 中 ， 其 中 key 的 值 是 由 nextUniqueld 生 成 的 ， 这 样 做 保证 了 这 个 
audio interface 拥 有 全 局 唯一 的 id 号 。 


完成 了 audio interface 的 模块 加 载 只 是 万 里 长 征 的 第 一 步 。 因 为 
每 一 个 interface 包 含 的 设备 通常 不 止 一 个 ，Android 系 统 目前 支持 的 音 
频 设 备 如 表 13-4 所 示 。 


表 13-4 Android 系统 支持 的 音频 设备 〈 输 出 ) 


| Device Name (ia 
AUDIO_DEVICE_OUT_EARPIECE 
AUDIO_DEVICE_OUT_SPEAKER 


AUDIO_DEVICE_OUT_WIRED_HEADSET 


AAUDIO_DEVICE_OUT_WIRED_HEADPHONE 
AUDIO_DEVICE_OUT_BLUETOOTH_SCO 


AUDIO_DEVICE_OUT_BLUETOOTH_SCO_HEADSET 


AUDIO_DEVICE_OUT_BLUETOOTH_SCO_CARKIT 


AUDIO_DEVICE_OUT_BLUETOOTH_A2DP 





WR | AUX 


AUDIO_DEVICE_OUT_ANLG DOCK_HEADSET 


AUDIO_DEVICE_OUT_DGTL_DOCK_HEADSET 


AUDIO_DEVICE_OUT_USB_ ACCESSORY 
AUDIO_DEVICE_OUT_USB_ DEVICE 


AUDIO_DEVICE_OUT_REMOTE_SUBMIX 


AUDIO_DEVICE_OUT_DEFAULT 默认 i 


AUDIO_DEVICE_OUT_ALL 





AUDIO _ DEVICE OUT ALL A2DP 蓝牙 相关 


AUDIO_DEVICE_OUT_ALL_ SCO 


AUDIO_DEVICE_OUT_ALL_USB 





读者 可 能 会 有 疑问 : 


e 这 么 多 的 输出 设备 ， 那 么 当 我 们 回放 音频 流 (录音 也 是 类 似 的 情 
况 ) 时 ， 该 选择 哪 一 种 呢 ? 
o 而且 当前 系统 中 audio interface 也 很 可 能 不 止 一 个 ， 应 该 如 何 选择 ? 





显然 这 些 决策 工作 将 由 AudioPolicyService 来 完成 ， 我 们 会 在 下 一 
小 节 做 详细 站 述 。 在 此 之 前 大 家 可 以 先 来 了 解 下 ，AudioFlinger 是 如 何 
打开 一 个 0utput 通 道 的 〈 一 个 audio interface 可 能 包含 若干 个 
output) 。 


打开 音频 输出 通道 《output) 在 AF 中 对 应 的 接口 是 open0utput () , 
即 : 


audio_io_handle_t AudioFlinger: :openOutput(audio_module_handle_t 
*pDevices, uint32_t *pSamplingRate, aud 

audio_channel_mask_t *pChann 
uint32_t *pLatencyMs, audio_ 


/* 入 参 中 的 module 是 由 前 面 的 loadHwModule 获 得 的 ， 它 是 一 个 audio interfa 
通过 此 id 在 mAudioHwDevs 中 查找 到 对 应 的 AudioHwDevice 对 象 */ 

status_t status; 

PlaybackThread *thread = NULL; 


audio_stream_out_t *outStream = NULL; 


s 


jabs 


audio_hw_device_t *outHwDev; 


/*Step 1. 查找 相应 的 audio interface 
outHwDev = findSuitableHwDev_l(module, *pDevices); 


/*Step 2., 为 设备 打开 一 个 输出 流 */ 

audio_hw_device_t *hwDevHal = outHwDev->hwDevice(); 

audio_io_handle_t id = nextUniqueld(); 

mHardwareStatus = AUDIO _HW_OUTPUT_OPEN; 

status = outHwDev->open_output_stream(hwDevHal, id, *pDevices 
(audio_output_flags_t)flags, &c 

mHardwareStatus = AUDIO_HW_IDLE; 


if (status == NO_ERROR && outStream != NULL) { 
/*Step 3. 生 成 AudioStreamOut*/ 
AudioStreamout *output = new AudioStreamOut(outHwDev, outst 
/*Step 4.) PlaybackThread*/ 
if ((flags & AUDIO_OUTPUT_FLAG_DIRECT)||(config.format != A 
|| (config.channel_mask != AUDIO CHANNEL_O 
thread = new DirectOutputThread(this, output, id, *pD 
} else { 
thread = new MixerThread(this, output, id, *pDevices); 





} 
mPlaybackThreads.add(id, thread); // 添 加 播放 线程 

















/*Step 5.Primary output 情 况 下 的 处 理 */ 
if ((mPrimaryHardwareDev == NULL) &&flags & AUDIO OUTPUT_ 

ALOGI("Using module %d has the primary audio interfac 
mPrimaryHardwareDev = outHwDev; 
AutoMutex lock(mHardwareLock); 
mHardwareStatus = AUDIO _HW_SET_MODE; 
hwDevHal->set_mode(hwDevHal, mMode); 
mHardwareStatus = AUDIO_HW_IDLE; 











} 

return id; 
} 
return 0; 
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是 围绕 outHwDev 这 个 变量 所 做 的 一 系列 操作 。 即 














。 查 找 合 适 的 音频 接口 设备 (findSuitableHwDev_l) ; 
。 创建 音频 输出 流 〈 通 过 open_output_stteam 获 得 一 个 
audio_stream_out_t) ; 


e J]J} AudioStreamOut2* £ 3 audio_stream_out_t- audio_hw_device_t; 

© 创建 播放 线程 (PlaybackThread) ; 

。 如 果 当 前 设备 是 主 设备 ， 则 还 需要 进行 相应 的 设置 (比如 模式 设 
置 ) o 


显然 ，outHwDev 用 于 记录 一 个 打开 的 音频 接口 设备 ， 它 的 数据 类 型 
是 audio_hw_device t， 是 由 HAL 规 定 的 一 个 音频 接口 设备 所 应 具有 的 属 
性 集合 ， 如 下 所 示 : 


struct audio_hw_device { 
struct hw_device_t common; 














int (*set_master_volume)(struct audio_hw_device *dev, float 

int (*set_mode)(struct audio_hw_device *dev, audio_mode_t m 

int (*open_output_stream)(struct audio_hw_device *dev, 
audio_io_handle_t handle, 
audio_devices_t devices, 
audio_output_flags_t flags, 
struct audio_config *config, 
struct audio_stream_out **st 


其 中 common 代 表 了 所 有 硬件 设备 在 HAL 层 都 要 实现 的 共有 属性 ; 
set master volume、set mode、open output stream 分 别 为 我 们 设置 
audio interface 的 主音 量 、 设 置 音频 模式 类 型 (比如 
AUD10_MODE_RINGTONE，AUD10_MODE_IN_CALL 等 ) 、 打 开 输 出 数据 流 提 
供 了 接口 。 


Fe DREAMT A. 


Step1@AudioFlinger::openOutput. #fopenOutput#, ike 
outHwDev 是 通过 查找 当前 系统 的 记录 得 到 的 。 代 码 如 下 : 


AudioFlinger: :AudioHwDevice* AudioFlinger: :findSuitableHwDev_1(au 
audio_devi 





if (module == 0) {// 特 殊 的 module 值 ， 此 时 需要 加 载 所 有 interface 
ALOGW( "findSuitableHwDev_1() loading well know audio hw 
for (size_t i = 0; i < ARRAY_SIZE(audio_interfaces); i+ 
loadHwModule_1(audio_interfaces[i]); 





for (size_t i = 0; i < mAudioHwDevs.size(); i++) {// 然 后 再 


AudioHwDevice *audioHwDevice = mAudioHwDevs. value. 
audio_hw_device_t *dev = audioHwDevice->hwDevice( 
if ((dev->get_supported_devices != NULL) && 
(dev->get_supported_devices(dev) & devic 
return audioHwDevice; 











} 
} else {// 直 接 从 已 有 记录 中 查找 device 
AudioHwDevice *audioHwDevice = mAudioHwDevs.valueFor (modu 
if (audioHwDevice != NULL) { 
return audioHwDevice; 
} 
} 


return NULL; 


变量 module 值 为 0 的 情况 ， 是 为 了 兼容 之 前 的 Audio Policy 而 做 的 
特别 处 理 。 当 module 等 于 0 时 ， 首 先 加 载 所 有 已 知 的 音频 接口 设备 ， 然 
后 才能 根据 devices 来 确定 其 中 符合 要 求 的 设备 。 入 人 参 devices 的 值 实际 
上 来 源 于 表格 “ 表 13-4 Android 系 统 支持 的 音频 设备 〈 输 出 ) ”所 示 的 
设备 。 可 以 看 到 ，enum 中 每 个 设备 类 型 都 对 应 一 个 特定 的 比特 位 ， 因 而 
上 述 代 码 段 中 可 以 通过 “与 运算 ”来 找到 匹配 的 设备 。 


当 modules 为 非 0 值 时 ， 说 明 Audio Policy 指 定 了 具体 的 设备 id 号 ， 
ER ioHwDevs 变 量 来 确认 是 否 存 在 符合 要 求 的 设 


DefaultKeyedVector<audio_module_handle_t, AudioHwDevice*> mAudio 


变量 mAudioHwDevs 是 一 个 Vector ， 以 audio_module_handle +t 为 
key， 每 一 个 handle 唯 一 确定 了 已 经 添加 的 音频 设备 。 那 么 ， 我 们 在 什 
么 时 候 添 加 设备 呢 ? 


一 种 情况 就 是 前 面 看 到 的 modules 为 0 时 ， 会 1oad 所 有 潜在 设备 ; D 
一 种 情况 就 是 AudioPol icy ManagerBase 在 构造 裔 数 中 会 预 加 载 所 有 
audio_policy. conf 中 所 描述 的 output (后 续 小 节 有 详细 介绍 ) 。 不 管 
是 哪 一 种 情况 ， 最 终 都 会 调用 loadHwModuleloadHwModule 1， 这 个 函数 
我 们 开头 就 已 分 析 过 。 


Step2@AudioFlinger: :open0utput。 调 用 open_output_stream 打 开 
一 个 audio_stream_out t。 如 果 从 理论 角度 讲解 这 个 函数 ， 读 者 可 能 会 
得 很 抽象 ， 所 以 这 里 我 们 提供 一 个 具体 硬件 方案 上 的 实现 范例 。 原 生 








态 代码 中 就 包含 了 一 些 具体 音频 设备 的 实现 ， 如 samsung 的 tuna。 其 源 
码 如 下 : 


/*device/samsung/tuna/audio/Audio_hw.c*/ 
static int adev_open_output_stream(..struct audio_stream_out **str 


{ 


struct tuna_audio_device *ladev = (struct tuna_audio_device * 
struct tuna_stream_out *out; 


*stream_out = NULL; 
out = (struct tuna_stream_out *)calloc(1, sizeof(struct tuna 


out->stream.common.set_parameters= out_set_parameters,... 
*stream_out = &out->stream; 


我 们 去 掉 了 其 中 的 大 部 分 代码 ， 只 留 下 核心 源码 。 可 以 看 到 ， 
tuna_stream_out 类 型 包含 了 audio_stream_out， 后 者 就 是 最 后 要 返回 
的 结果 。 这 种 方式 在 HAL 层 的 实现 中 很 常见 ， 读 者 应 该 熟悉 这 样 的 写 
法 。 而 对 于 audio_stream_out 的 操作 ， 无 非 就 是 根据 入 人 参 需要 为 它 的 函 
数 指 针 做 初始 化 ， 如 set_parameters 的 实现 就 最 终 指 向 了 
out_set_parameters。 接 下 来 的 实现 就 涉及 Linux 驱 动 了 ， 我 们 这 里 先 
不 往 下 分 析 ， 后 面 音 量 调节 小 节 还 会 再 遇 到 这 个 函数 。 


Step3@AudioF linger: :open0utput。 生 成 AudioStream0ut 对 象 。 这 
个 变量 没什么 特别 的 ， 它 把 audio_hw_device_t 和 audio_stream_out 七 


作为 一 个 整体 来 封装 。 


Step4@AudioFlinger: :open0utput。 既 然 通 道 已 经 打开 ， 那 么 由 谁 
K MEE “GA” KAW? 这 就 是 PlaybackThread。 而 且 分 两 种 不 同 的 
情况 : 





e DirectOutput 
如 果 不 需 要 混 首 。 
e Mixer 


me db SA te 
Th Sc /EE A o 


这 两 种 情况 分 别 对 应 Di rectOutput Thread 和 MixerThread 两 种 线 
程 。 我 们 以 后 者 为 例 来 分 析 下 PlaybackThread 的 工作 模式 ， 也 会 为 后 面 
小 节 的 内 容 打 下 基础 。 


图 13-13 描 述 了 包括 PlaybackThread 在 内 的 各 回放 线程 的 继承 关 


ThreadBase 


—uint32_t mDevice; 
—uintl6_t mChannelCount 





—audio format_t mFormat 


+initCheck() 
+exit() 
AN 


PlaybackThread 


—mTracks 


—AudioStreamOut *mOutput 
—float mMaster Volume 


+ready ToRun() 
+threadLoop() 
A 八 


MixerThread . 
DireciOutputThread 


—AudioMixer* mAudioMixer 
- —mActiveTrack 
+threadLoop_mix() 


+threadLoop_standby() 





+threadLoop mix() 
+threadLoop_sleepTime() 





+threadLoop_write() 
A 


DuplicatingThread 
—mOutputTracks 


+threadLoop_mix() 
+threadLoop_standby() 





+threadLoop_write() 


全 图 13-13 Playback 各 线程 类 关系 图 


如 图 所 示 ， 用 于 Playback 的 线程 种 类 不 少 ， 它 们 的 “ 基 类 ”都 是 
Thread。 


AudioFlinger 中 用 于 记录 Record 和 Playback 线 程 的 有 两 个 全 局 变 
Bo 如 下 : 


DefaultKeyedVector< audio_io_handle_t, sp<PlaybackThread>> mPlay 
DefaultKeyedVector< audio_io_handle_t, sp<RecordThread>> mReco 


在 open0utput 中 ， 加 入 mPlaybackThreads 的 是 一 个 新 建 的 线程 类 实 
例 ， 如 MixerThread。 它 的 构造 函数 如 下 : 


AudioFlinger: :MixerThread: :MixerThread(...) :PlaybackThread(audioFli 
device, type),... 


mAudioMixer = new AudioMixer(mNormalFrameCount, mSampleRate) ; 
if (mChannelCount != FCC_2) {// 非 双 声 道 的 情况 下 
ALOGE("Invalid audio hardware channel count %d", mChannel 





mOutputSink = new AudioStreamOutSink(output->stream) ; 
if (initFastMixer) { 


} else { 
mFastMixer = NULL; 
} 


首先 生成 一 个 AudioMixer 对 象 ， 这 是 混 音 处 理 的 关键 ， 我 们 在 后 面 
会 有 详细 介绍 。 然 后 检查 声 道 数量 ， 在 Mi xer 情 况 下 肯定 不 止 一 个 声 
道 。 接 着 创建 一 个 NBA10 (Non-blocking audio 1/0 interface) 
Sink ( 即 AudioStream0utSink) ， 并 进行 negotiate。 最 后 根据 配置 
CinitFastMixer) 来 判断 是 否 使 用 fast mixer. 


可 以 想象 一 下 ， 一 个 放 音 线程 的 任务 就 是 “不 断 ” 处 理 上 层 的 音频 
数据 回放 请 求 ， 然 后 将 其 传递 到 下 一 层 ， 最 终 写 入 硬件 设备 。 但 是 在 上 
面 这 个 也 数 中 ， 似 乎 并 没有 看 到 程序 去 局 动 一 个 新 线程 ， 也 没有 看 到 进 
入 线程 循环 的 地 方 ， 或 者 去 调用 其 他 可 能 引起 线程 创建 的 函数 。 那 么 ， 


究竟 在 什么 情况 下 Mi xerThread 才 会 真正 进入 线程 循环 呢 ? 


不 知 读者 有 没有 注意 到 之 前 mPlaybackThreads 的 定义 ， 我 们 再 次 列 
出 如 下 : 


DefaultKeyedVector< audio_io_handle_t, sp<PlaybackThread>> mPlay 


它 实 际 上 是 由 audio io handle t 和 PlaybackThread 强 指针 所 组 成 
的 键 值 对 ; 同时 也 可 以 判断 出 ，PlaybackThread 类 的 祖先 中 一 定 会 
RefBase。 上 有 具体 来 说 ， 就 是 它 的 “ 父 类 ”Thread 继 承 自 RefBase: 


/*frameworks/native/include/utils/Thread.h*/ 
class Thread : virtual public RefBase 


根据 强 指 针 的 特性 ， 目 标 对 象 在 第 一 次 被 引用 时 是 会 调用 
onFirstRef 的 ， 这 点 在 前 面 小 节 分 析 AudioFlinger 时 也 见 过 。 涵 数 实现 
如 下 : 


void AudioFlinger::PlaybackThread: :onFirstRef() 


run(mName, ANDROID_PRIORITY_URGENT_AUDIO); 


很 简单 ， 只 是 调用 了 run 方 法 ， 从 而 启动 一 个 新 线程 并 间接 调用 
TE E 不 断 地 处 理 Mix 业 务 。 这 样 我 们 就 明白 一 个 
PlaybackThread 是 如 何 进 入 线程 循环 的 ， 至 于 循环 中 需要 做 些 什么 
在 下 一 小 节 做 详细 介绍 


Step5@ AudioFlinger::open0utput。 到 目前 为 止 ， 我 们 已 经 成 功 
地 建立 起 一 个 音频 通道 ， 就 等 着 AudioTrack 往 里 “ 丢 ” 数 据 了 。 不 过 假 
如 当前 的 output 是 “pr imary” 的 ， 则 还 有 一 些 额外 的 工作 要 做 ， 如 模 
式 的 设置 。 


我 们 来 整理 下 这 个 小 节 所 阐述 的 内 容 。 


e X AudioPolicyManagerBase 74 造 时 ， 它 会 根据 用 户 提 供 的 
audio_bolicy.conf 来 分 析 系 统 中 有 哪些 Audio Interface (primary, a2dp 
以 及 usb) , % Ja at AudioFlinger::loadHwModule Jn # 4 Audio 
Intetface 对 应 的 库 文件 ， 并 依次 打开 其 中 的 Output(openOutpub 和 





Input(openInput) . 

。 我 们 详细 分 析 了 openOutput 所 做 的 工作 ， 包 括 打 开 一 个 
audio_stream_out t 通 道 ， 生 成 AudioStreamOut 对 象 ， 以 及 新 建 
PlaybackThread 等 。 此 时 “万 事 俱 备 ， 只 欠 东 风 ”， 只 要 AudioTrack 
不 断 和 AudioFlinger 传 递 数据 ， 整 个 音频 回放 就 开始 了 。 当 然 ， 这 其 
中 还 涉及 状态 的 管理 、 路 由 切换 以 及 数据 的 跨 进 程 通信 等 事宜 ， 这 
些 都 是 我 们 后 面 内 容 所 要 解决 的 。 





13.3.3 PlaybackThread 的 循环 主体 


当 一 个 PlaybackThread 进 入 主 循环 后 (threadLoop) ， 音 频 事 务 就 
正式 开局 了 。 仔 细 观 察 ， 就 会 发 现 这 个 循环 中 会 不 断 地 调用 
以 “threadLoop ”开头 的 若干 接口 ， 如 threadLoop_mix'、 
threadLoop sleepTime, threadLoop standby=. M “threadLoop” 的 
前 缀 开头 ， 是 因为 这 些 函 数 都 是 在 threadLoop 这 个 主体 里 被 调用 的 ， 可 
以 说 代表 了 这 个 PlaybackThread 所 需要 完成 的 各 个 操作 步骤 。 


从 前 一 小 节 可 以 了 解 到 ， 当 程序 执行 到 
PlaybackThread: :onFirstRef 时 会 去 启动 一 个 线程 来 承载 threadLoop 的 
运行 。 接 下 来 我 们 具体 看 看 这 个 循环 体 中 的 处 理 流 程 : 


bool AudioFlinger: :PlaybackThread: :threadLoop() 


while (!exitPending())/*Step 1. 注 意 循 环 条 件 */ 
{... 
processConfigEvents();/*Step 2. */ 
{ FERRARE ERRA BER Hl A LA a, Mat eS 
Mutex: :Autolock _1(mLock); 











i /*Step 3，Standby 判 断 */ 
if (CC_UNLIKELY((!mActiveTracks.size() && systemTime( 
| |is 
if (!mStandby) { 
threadLoop_standby();//#Astandby 
mStandby = true; 


} 
/*Step 4. 准 备 音频 数据 */ 
mMixerStatus = prepareTracks_l(&tracksToRemove) ; 


} 
/*Step 5.8m, Fraamix*/ 
if (CC_LIKELY(mMixerStatus == MIXER_TRACKS_READY)) { 
threadLoop_mix(); 
} else { 
threadLoop_sleepTime();// 和 否则 休眠 一 段 时 间 
} 


/*Step 6.*/ 
if (sleepTime == 0) {//sleepTime 为 090， 代表 我 们 必须 写 入 音频 硬件 # 
threadLoop_write(); 





mStandby = false; 
} else { 
usleep(sleepTime); // 进 入 休眠 ， 时 间 长 短 是 SleepTime 





} 
/*Step 7.*/ 
threadLoop_removeTracks(tracksToRemove); // 移 除 相 关 Track 
tracksToRemove.clear() >}... 
}//while (!exitPending())4# 





releaseWakeLock(); 
return false; 


Step1@ PlaybackThread: :threadLoop。 循 环 的 条 件 
是 !exitPending (为 true。 这 个 函数 属于 Thread 类 ， 它 主要 通过 判断 内 
部 变量 mExitPending 的 值 来 得 9 出 是 否 要 结束 线程 恋 量 mExitPending 在 
Thread 初 始 化 时 为 fasle， 如 果 后 面 有 人 通过 requestExit () ， 
requestExitAndWait 等 函数 来 请 求 主 动 退 出 ， 这 个 值 就 会 改变 ， 从 而 使 
得 PlaybackThread 结 束 循 环 。 


Step2@PlaybackThread: :threadLoop。 处 理 config 事 件 。 当 有 配置 
变更 的 事件 发 生 时 ， 可 以 通过 sendConfigEvent 来 通知 
PlaybackThread。 这 个 函数 将 把 事件 添加 到 mConfi gEvents 全 局 变 
中 ， 以 供 processConf igEvents 进 行 处 理 。 AAF 


enum io_config_event { 
OUTPUT_OPENED, //Output#] Jf 
OUTPUT_CLOSED, //Output%ň] 
OUTPUT_CONFIG_CHANGED，//0utput 配 置 改变 
INPUT_OPENED，//Input 打 开 
INPUT_CLOSED，//Input 关 闭 
INPUT_CONFIG_CHANGED, //Input 配 置 改 变 


STREAM_CONFIG_CHANGED, //Stream 配 置 改变 
NUM_CONFIG_EVENTS 


F 


Step3@ PlaybackThread: :threadLoop。 判 断 当 前 是 否 符 合 @Standby 
的 条 件 ， 如 果 是 就 调用 threadLoop_standby。 这 个 函数 最 终 还 是 通过 
HAL 层 的 接口 来 实现 ， 如 下 所 示 : 


mOutput->stream->common.standby(&mOutput ->stream->common) ; 


Step4@ PlaybackThread: :threadLoop。 进 行 数据 准备 ， 
prepareTracks_| 这 个 函数 非常 长 ， 我 们 先 用 伪 代 码 的 形式 整理 一 下 它 
所 做 的 工作 ， 如 下 所 示 : 


AudioFlinger: :PlaybackThread: :mixer_state AudioFlinger: :MixerThre 
{ 

/*Step 工 ， 当 前 活跃 的 Track 数量 */ 

size_t count = mActiveTracks.size(); 














/*Step 2. 循环 处 理 每 个 Track， 这 是 函数 的 核心 */ 
for (size_t i=0 ; i<count ; i++) { 
Track* track = mActiveTracks[i];// 伪 代码 没有 考虑 强 指针 























/*Step 3. FastTrack 下 的 处 理 */ 
if(track is FastTrack?) 


//do something; 


} 
/*Step 4. 准备 数据 ， 细 分 为 以 下 几 个 小 步骤 来 完成 */ 
audio_track_cblk_t* cblk = track->cblk(); //Step 4.1 数据 块 


/*Step 4.2 回放 音频 ， 至 少 需要 准备 多 少 帧 数据 ? */ 
uint32_t minFrames = 1;// 初 始 化 
// 具 体 计算 minFrames 的 过 IF.. 


/*Step 4.3 如 果 数 据 已 经 准备 完毕 ， 那 么 : 

// 调 整 音 量 

// 其 他 参数 设置 */ 
}//for 循 环 结束 


ee 5， 后 续 判 断 */ 
返回 结果 ， 指 明 当 前 状态 已 经 ready 














现在 ， 我 们 针对 上 面 的 步骤 来 做 “填空 ”。 


Step1@MixerThread: :prepareTracks |。mActiveTracks 的 数据 类 
型 是 Sortedyector ， 用 于 记录 当前 活跃 的 Track。 它 会 随 着 新 的 
AudioTrack 的 加 入 而 扩大 ， 也 会 在 必要 的 情况 下 (AudioTrack 工 作 结 束 
或 者 出 错 等 ) remove 相 应 的 Track。 


Step2&Step3@MixerThread: :prepareTracks 1。 循环 的 条 件 就 是 要 
逐个 处 理 该 PlaybackThread 中 包含 的 所 有 Tracks。 假 如 当前 是 一 个 
FastTrack， 我 们 还 要 做 一 些 额外 的 准备 工作 ， 暂 时 不 去 涉及 具体 细 
节 


che 
° 


Step4@ MixerThread::prepareTracks |。 这 一 步 是 准备 工作 中 最 
重要 的 ， 即 缓冲 数据 。 在 学 习 代码 细节 前 ， 我 们 先 来 了 解数 据 传 输 时 最 
容易 出 现 的 underrun 问 题 。 


什么 是 Buffer Underrunie? 
当 两 个 设备 或 进程 间 形 成 “生产 者 -消费 者 ”关系 上 时， 如果 生产 的 
速度 不 及 消费 者 消耗 的 速度 ， 就 会 出 现 Underrun。 以 音频 回放 为 例 ， 此 


时 用 户 听 到 的 声音 就 可 能 是 断断续续 的 ， 或 者 是 重复 播放 当前 buffer 中 
的 数据 《取决 于 具体 的 实现 ) 。 


如 何 避 免 这 种 异常 的 发 生 呢 ? 这 是 AudioTrack 和 AudioF1inger 需 要 
协同 解决 的 问题 。 我 们 可 以 先 看 看 “消费 者 ”端的 处 理 。 


Step4 分 为 以 下 几 个 子 步骤 。 
© Step 4.1 准 备 音频 数据 块 : 
audio_track_cblk_t* cblk = track->cblk(); 


关于 audio_track_cblk_t 的 更 多 描述 ， 可 以 参见 后 面 的 数据 流 小 
Te 


© Step 4.2 计 算 此 次 回放 音频 所 需 的 最 少 帧 数 ， 初 始 值 为 1: 


uint32_t minFrames = 1; 
if ((track->sharedBuffer() == 0) && !track->isStopped() & 
(mMixerStatusIgnoringFastTracks == MIXER_TRACKS_R 
if (t->sampleRate() == (int)mSampleRate) { 
minFrames = mNormalFrameCount; 





} else { 
minFrames = (mNormalFrameCount * t->sampleRate()) / m 
minFrames += mAudioMixer ->getUnreleasedFrames(track-> 
ALOG_ASSERT(minFrames <= cblk->frameCount ); 


“4track—>sharedBuffer () 为 0 时 ， 说 明 这 个 AudioTrack 不 是 STATIC 
即 数据 不 是 一 次 性 传送 的 《可 以 参见 AudioTrack 小 节 的 摘 
。 全 局 变量 mSamp1eRate 是 通过 m0utput->stream-> 
common. get_sample_rate 获 得 的 ， 它 由 HAL 提 供 ， 代 表 的 是 设备 的 
Sampling Rate. 


如 果 两 者 一 致 ， 就 采用 mNorma1FrameCount， 这 个 值 在 
read0utputParameters 函 数 中 进行 初始 化 ; 如 果 两 者 不 一 致 ， 就 要 预 留 
多 余 空间 做 rounding (+1) 和 interpolation (+1) 。 另 外 ， 还 需要 考虑 未 
释放 的 空间 大 小 ， 也 就 是 getUnreleasedFrames 得 到 的 。 Pa 
minFrames 必 须 小 于 数据 块 的 总 大 小 ， 因 而 最 后 有 个 ASSERT。 通 常情 
下 frameCount 分 配 的 是 一 个 buffer 的 两 倍 ， ti 
例子 。 


© Step 4.3 数 据 是 否 准备 就 绪 。 


上 一 步 我 们 计算 出 了 数据 的 最 小 帧 值 ， 即 minFrames。 接 下 来 就 应 
该 判断 当前 的 实际 情况 是 否 符合 这 一 指标 了 。 代 码 如 下 : 


if ((track->framesReady() >= minFrames) && track->isReady() & 
&& !track->isTerminated() ) 
{// BREE RA, Fb ready tkAs 
mixedTracks++;// 需 要 mix 的 Track 数量 增加 1 


/* 计 算 音 量 值 */ 
uint32_t vl, vr, va; //3 个 变量 分 别 表 示 左 、 右 声 道 和 AuXx Levi 
if (track- >isPausing() | |mStreamTypes[track->streamTy 
vl = vr = va = 0; // 当 静音 时 ， 变 量 直 接 赋 0 
if (track- >isPausing()) { 
track->setPaused(); 


























} 
} else { 
/* 这 里 获得 的 是 针对 每 个 stream 类 型 设置 的 音量 值 ， 也 就 是 后 
后 执行 到 的 地 方 ， 在 这 里 就 起 到 作用 了 */ 
float typeVolume = mStreamTypes[track->streamType()]. 
float v = masterVolume * typeVolume; // 主 音量 和 类 型 




















ServerProxy *proxy = track->mServerProxy; 
uint32_t vlr = proxy->getVoLumeLR() ;// 这 里 得 到 的 vlr 
vl = vlr & QxFFFF; //vlr 的 高 低位 分 别 表示 vr 和 v1 
vr = vlr >> 16; 
if (vl > MAX_GAIN_INT) { // 对 v1 进行 合理 值 判断 
ALOGV("Track left volume out of range: %04X", 
vl = MAX_GAIN_INT; 




















} 

if (vr > MAX_GAIN_INT) {// 对 vr 进行 合理 值 判 断 
ALOGV( "Track right volume out of range: %04X" 
vr = MAX_GAIN_INT; 

} 

// now apply the master volume and stream type vo 

vl = (uint32_t)(v * vl) << 12; 

vr = (uint32_t)(v * vr) << 12; 

uint16_t sendLevel = proxy->getSendLevel_U4_12(); 


va = (uint32_t)(v * sendLevel); 


Me 


mAudioMixer ->setParameter(name, param, AudioMixer::VO 
mAudioMixer ->setParameter(name, param, AudioMixer::VO 
mAudioMixer ->setParameter(name, param, AudioMixer: :AU 


} else {// 数 据 未 准备 就 绪 的 情况 下 ， 源 代码 略 .. 


对 于 音量 的 设置 还 有 很 多 细节 ， 读 者 有 兴趣 的 可 以 自行 研究 下 。 在 
得 到 v1，vr 和 va 的 值 后 ， 需 要 把 它们 应 用 到 AudioMixer 里 。 不 过 在 
prepareTracks_| 中 还 只 是 调用 mAudioMi xer->se tParameter 设 置 了 这 
些 参数 ， 真 正 的 实现 是 在 thrsadLoop_mix 中 ， 我 们 后 面 会 讲 到 这 个 函 
数 。 





Step5@ MixerThread: :preparelracks 1。 通过 对 每 个 Track 执行 上 
述 处 理 后 ， 最 后 要 返回 一 个 结果 。 这 通常 取决 于 : 


(1) 是 否 有 active track; 

(2) active track 的 数据 是 否 已 经 准备 就 绪 。 

返回 的 最 终 值 将 影响 到 threadLoop 的 下 一 步 操作 。 

完成 了 prepareTracks_1 的 分 析 ， 我 们 再 回 到 前 面 的 threadLoop。 


Step5@ PlaybackThread: :threadLoop。 如 果 上 一 步 的 数据 准备 工 


作 已 经 完成 〈 即 返回 值 是 MIXER_TRACKS_READY) ， 就 开始 进行 真正 的 混 
音 操 作 ， 即 threadLoop_mix， 否 则 会 休眠 一 定 的 时 间 一 一 如 此 循环 往复 
直到 退出 循环 体 : 


void AudioFlinger: :MixerThread::threadLoop_mix() 


{ 
int64_t pts; 


mAudioMixer ->process(pts); 


IX AF RUE A Audi Mixer kt ET, RIET hA — a7 aT 


假如 数据 还 没有 准备 就 结 ， 那 么 AudioFlinger 将 调用 
threadLoop_sleepTime 来 计算 需要 休眠 多 长 时 间 〈 变 量 sleepTime) ， 
并 在 threadLoop 主 循环 的 末尾 〈 在 remove track 之 前 ) 执行 usleep 进 入 
休眠 。 


Step6@ PlaybackThread: :threadLoop。 将 数据 写 到 HAL 中 ， 从 而 借 
助 后 者 逐步 写 入 硬件 设备 中 : 


void AudioFlinger: :PlaybackThread: :threadLoop_write() 
{ 





mLastwriteTime = systemTime();// 记 录 上 次 写 入 时 间 
mInWrite = true; 

int byteswritten; 

if (mNormalSink != ©) {//NBAIO 的 情况 下 





ssize_t framesWritten = mNormalSink->write(mMixBuffer, co 


} else { 
byteswritten = (int)mOutput->stream->write(mOutput->strea 
if (byteswritten > ©) mBytesWritten += mixBufferSize; 


mNumwrites++; 
mInWrite = false; 


分 为 两 种 情况 : 


° 如 果 是 采用 了 NBA10 (Non-blocking Audio 1/0), BÆ 
mNormalSink 不 为 空 的 情况 下 ， 则 通过 它 写 入 HAL 设 备 。 


° 否则 使 用 普通 的 AudioStream0ut 〈 即 m0utput 变 量 ) 将 数据 输 
出 。 


Step7@ PlaybackThread: :threadLoop。 移 除 tracksToRemove 中 指 
示 的 Tracks。 是 否 移 除 一 个 Track 是 在 prepareTracks_ 1 中 判断 ， 可 以 概 
括 为 以 下 几 种 情况 。 


对 于 Fast Track， 如 果 它 的 状态 (mState) 是 STOPPING_2， 
PAUSED，TERMINATED，STOPPED，FLUSHED， 或 者 状态 是 ACTIVE 但 
underrun 的 次 数 超过 限额 (mRetryCount) ， 则 会 被 加 入 
tracksToRemove 列 表 中 。 


e 在 当前 的 Track 数据 未 准备 就 绪 的 情况 下 ， 且 是 STATIC TRACK 
或 者 已 经 停止 /暂停 ， 也 会 被 加 入 tracksToRemove 列 表 中 。 


在 tracksToRemove 列 表 中 的 Track， 与 其 相关 的 output 将 收 到 stop 
lak 〈 由 AudioSystem: : stop0utput 发 起 ) 。 


关于 AudioFlinger 中 与 AudioTrack，AudioPolicyService 交 互 的 部 
分 ， 我 们 接 下 来 将 继续 前 述 。 


13.3.4 AudioMixer 


每 一 个 Mi xerThread 都 有 一 个 唯一 对 应 的 AudioMi xer (在 
MixerThread 中 用 mAudioMixer 表 示 ) 对 象 ， 它 的 作用 就 是 完成 首 频 的 混 
音 操 作 ， 其 示意 图 如 图 13-14 所 示 。 


如 图 13-14 所 示 ，AudioMixer 对 外 开放 的 接口 主要 涉及 
Parameter (如 setParameter) , Resampler (如 setResampler) 、 
Volume (如 ad justVolumeRamp) 、Buffer (如 setBufferProvider) 及 
Track (如 getTrackName) 5 个 部 分 。 


ufo oe] TS 


tracks| MAX NUM TRACKS} 





A 13-14 ”AudioMixet 示 意 


在 内 部 的 实现 中 ，MixerThread 的 核心 是 一 个 mState 变 量 (state t 
类 型 ) ， 所 有 的 混 音 工作 都 会 在 这 个 变量 中 体现 出 来 一 一 特别 是 其 中 的 
tracks 数 组 ， 如 下 所 示 : 


struct state_t { 

uint32_t enabledTracks; 

uint32_t needsChanged; 

size_t frameCount; 

void (*hook)(state_t* state, int64_t pts); // one 

int32_t *outputTemp; 

int32_t *resampleTemp; 

NBLog:: Writer* mLog; 

int32_t reserved[1]; 

track_t tracks[MAX_NUM_TRACKS]; _ attribute ((aligne 
}; 


MAX_NUM_TRACKS=32， 即 最 多 支持 32 路 同时 混 音 ， 这 在 大 部 分 情况 
下 肯定 足够 了 。 数据 类 型 track_t 是 对 每 个 Track 的 换 述 可 想 而 知 类 
似 setParameter 的 设置 接口 ， 最 终 影 响 的 就 是 Track 的 属性 : 





struct track_t { 








union { 

inti6_t volume [MAX_NUM_CHANNELS]; 

int32_t volumeRL; 

};// 音 量 相关 的 属性 

int32_t prevVolume[MAX_NUM_CHANNELS]; 

int32_t volumeInc[MAX_NUM_CHANNELS]; 

uint8_t channelCount; // 只 能 是 1 或 2 

uint8_t format; // 总 是 16 

uint16 t enabled; // 实际 是 布尔 类 型 
audio_channel_mask_t channelMask; 

AudioBufferProvider* bufferProvider ; 
mutable AudioBufferProvider::Buffer buffer; // 8 bytes 
hook_t hook; 

const void* in; //buffer 中 的 当前 位 置 

AudioResampler* resampler; 

uint32_t sampleRate; 

int32_t* mainBuf fer; 

int32_t* auxBuf fer; 

bool setResampler(uint32_t sampleRate, uint32_t de 
bool doesResample() const { return resampler != NU 
void resetResampler() { if (resampler != NULL) res 
void adjustVolumeRamp(bool aux); 


size_t getUnreleasedFrames() const { return resampler != 
resampler ->getUnreleas 


}; 


AudioFlinger 的 threadLoop 中 ， 通 过 不 断 调 用 prepareTracks_| 来 
准备 数据 ， 而 每 次 prepare 实 际 上 都 是 对 所 有 Tracks 的 一 次 调整 。 如 果 
属性 有 变化 ， 就 会 通过 setParamter 来 告知 AudioMixer 。 


在 前 一 个 小 节 中 ，threadLoop_mix 在 内 部 就 是 通过 AudioMixer 来 实 
现 混 音 的 。 具 体 如 下 : 


void AudioMixer: :process(int64_t pts) 


mState.hook(&mState, pts); 


“hook” MTHS, ATAMxKTtAa rie? 一 个 原因 可 能 是 
hook 指 向 的 实体 是 变化 的 一 一 所 以 就 好 像 钧 子 一 样 ， 需 要 灵活 地 依附 于 
各 种 物体 之 上 。 从 代码 层面 来 看 ，hook 是 一 个 函数 指针 ， 它 根据 不 同 场 


景 会 分 列 指 向 以 下 几 个 函数 实现 。 


process validate: 根据 当前 的 具体 情况 ， 进 一 步 将 hook 导 向 下 
面 的 几 个 函数 。 


process nop: 初始 值 。 


process OneTrack16BitsStereoNoResamp! ing: 只 有 一 路 Track， 
16 比 特 立体 声 ， 不 重 采 样 。 


process__genericNoResampling: 两 路 (包含 ) 以 上 Track， 不 重 
采样 。 


process genericResampling: 两 路 (包含 ) 以 上 Track， 重 采 
样 。 


hook 在 以 下 几 种 情况 下 会 被 重新 赋值 。 
° AudioMixer 初 始 化 时 ，hook 指 向 process_nop。 


° 状态 改变 或 者 参数 变化 时 〈 比 如 setParameter ) ， 调 用 


invalidateState，hook 指 向 process validate。 
e Audi oMixer: :process 是 外 部 程序 调用 hook 的 入 口 。 


我 们 以 简 图 来 摘 述 一 下 ， 大 家 也 许 会 看 得 更 清楚 些 ， 如 图 13-15 所 
7J“ o 


process. validate 





process OneTrack  6BisStereaNoResampling 
process _genericNoResampling 


全 图 13-15 hook 的 使 用 





其 中 ，process_validate 的 代码 实现 如 下 : 
void AudioMixer::process validate(state t* state, int64_t pts) 


int countActiveTracks = 0; 
bool alli16BitsStereoNoResample = true; 
bool resampling = false}... 
uint32_t en = state->enabledTracks; 
while (en) { 
const int i = 31 - __builtin_clz(en); 
en &= ~(1<<1); 
countActiveTracks++; //enabled 状态 的 Track 计数 


} 

state->hook = process nop; 

if (countActiveTracks) { 
if (resampling) { 


state->hook = process__genericResampling; 
} else { 


state->hook = process__genericNoResampling; 
if (alli6BitsStereoNoResample && !volumeRamp) { 
if (countActiveTracks == 1) { 
state->hook = process__OneTracki6BitsStereoNo 
} 


J 


state->hook(state, pts); 


这 个 函数 先 通过 whi le 循环 逐个 分 析 处 于 enabled 状 态 的 Track， 统 
计 其 内 部 各 状态 位 〈 如 NEEDS_AUXMASK、NEEDS_RESAMPLEMASK 等 ) 情 
况 ， 得 出 countAct iveTracks、resampling、volumeRamp 及 
al116BitsStereoNoResample 的 合理 值 ， 最 后 基于 这 几 个 变量 来 选择 正 
确 的 hook 实 现 ， 并 调用 这 个 hook 函 数 执行 具体 工作 。 


e PAE ENS E ER 数据 的 ， 我 们 将 在 音频 流 小 节 做 统 
一 分 析 。 





13.4 策略 的 制定 者 


在 AudioF 1inger 小 节 ， 我 们 反复 强调 它 只 是 策略 的 执行 者 ， 而 
AudioPol icyService 才 是 策略 的 制定 者 。 这 种 分 离 设计 有 效 地 降低 了 整 
个 音频 系统 的 耦合 性 ， 而 且 为 各 个 模块 独立 扩展 功能 提供 了 基础 保障 。 


AudioPol icyService 


13.4.1 AudioPolicyService 概 述 


汉语 中 有 很 多 与 策略 有 关联 的 俗语 ， 如 “因地制宜 ”“ 具 体 问题 具 
体 分 析 ”; 战争 中 只 遵照 兵书 来 制定 战术 的 行为 也 被 称 为 “ 纸 上 谈 
兵 ”“ 死 读书 ”。 这 些 都 告诉 我 们 ， 了 解 策 略 的 执行 环境 非常 重要 ， 只 
有 清晰 地 青 定 出 “问题 是 什么 ”， 才 能 有 的 放 和 天 地 制定 出 正确 的 Pol icy 
以 解决 问题 。 


从 功能 的 角度 来 讲 ，Android 系 统 中 的 声音 被 划分 为 多 个 种 类 。 具 
体 如 下 所 示 : 


/*frameworks/base/media/java/android/media/AudioSystem.java*/ 
public static final int STREAM_VOICE_CALL = 0; /* 通话 声音 */ 
public static final int STREAM_SYSTEM = 1; /* 系统 声音 */ 
public static final int STREAM_RING = 2; /* 电话 铃声 和 短信 提示 * 
public static final int STREAM_MUSIC = 3; /* 音乐 播放 */ 
public static final int STREAM_ALARM = 4; /* W4 */ 
public static final int STREAM_NOTIFICATION = 5; /* 通知 声音 *, 


/* 下 面 几 个 是 隐藏 类 型 ， 不 对 上 层 应 用 开放 */ 

public static final int STREAM_BLUETOOTH_SCO = 6; /* 蓝 牙 通 话 */ 

public static final int STREAM_SYSTEM_ENFORCED = 7; /* WRillH 4 
BER Ta RSA TA ART 4 

public static final int STREAM_DTMF = 8; /* DTMF 声 音 */ 

public static final int STREAM_TTS = 9; /* 即 text to speech (7 


针对 这 么 多 音频 类 型 ，AudioPol icyService 至 少 面临 如 下 几 个 问 





题 


。 问题 1: 这 些 类 型 的 声音 需要 输出 到 哪些 对 应 的 音频 回放 设备 中 ? 
比如 一 部 典型 的 手机 ， 它 既 有 了 听 简 、 耳 机 接口 ， 还 有 蓝牙 设备 。 假 


设 默认 情况 下 播放 音乐 是 通过 听 简 喇叭 输出 的 ， 那 么 当 用 户 插入 耳机 
时 ， 这 个 策略 就 会 改变 一 一 从 耳机 输出 ， 而 不 再 是 听 简 ; 又 如 在 机 器 插 





着 耳机 时 ， 播 放 音 乐 不 应 该 从 喇叭 输出 ， 但 是 当 有 来 电 铃 声 时 ， 融 需要 
同时 从 喇叭 和 耳机 输出 音频 。 这 些 “ 音 频 策略 ”的 制定 ， 其 主导 者 就 是 


AudioPolicyService。 
o 问题 2: 声音 的 路 由 策略 如 何 ? 


如 果 把 一 个 音乐 播放 实例 〈 比 如 用 MediaPlayer 播 放 一 首 SD 卡 中 的 
歌曲 ) 比 作 源 1P， 那 么 上 一 问题 中 找到 的 音频 播放 设备 就 是 目标 IP。 在 
TCPZIP 体 系 中 ， 从 源 1P 最 终 到 达 目 标 1P 通 常 需要 经 过 若干 个 路 由 器 节点 
一 一 由 路 由 器 根据 一 定 的 算法 来 决定 下 一 个 匹配 的 节点 是 什么 ， 从 而 制 
定 出 一 条 最 佳 的 路 由 路 径 ， 如 图 13-16 所 示 。 


Destination 


0 
Aa 





全 图 13-16 路 由 器 示意 图 


AudioPolicyService 所 要 解决 的 问题 与 路 由 器 类 似 。 因 为 系统 中 很 


可 能 存在 多 个 Audio Interface, 每 一 个 Audio Interface 包 含 若干 个 
output， 而 每 个 output 又 同时 支持 若干 种 音频 设备 一 一 这 就 意味 着 从 播 
放 实 例 到 终端 设备 需要 经 过 Audio lnterface 和 output 的 选择 ， 被 称 为 
AudioPolicyService 的 路 由 功能 。 


。 问题 3: 每 种 音频 类 型 的 音量 调节 是 否 一 样 ? 


不 同类 型 的 音频 ， 其 音量 的 可 调节 范围 是 不 一 样 的 。 比 如 有 的 是 0 
~ 15， 而 有 的 则 是 1 一 20; 而 且 它 们 的 默认 值 也 是 有 差别 的 ， 我 们 看 看 
AudioManager 中 的 定义 : 


public static final int[] DEFAULT_STREAM_VOLUME = new int[] { 
4, // STREAM_VOICE_CALL 
7, // STREAM_SYSTEM 
5, // STREAM_RING 
11, // STREAM_MUSIC 
6, // STREAM_ALARM 
5, // STREAM_NOTIFICATION 
7, // STREAM_BLUETOOTH_SCO 
7, // STREAM_SYSTEM_ENFORCED 
11, // STREAM_DTMF 
11 // STREAM_TTS 





}; 
关于 音量 的 调节 后 面 我 们 用 专门 的 小 节 来 介绍 


为 了 让 读者 对 AudioPolicyService 有 个 感性 的 认识 ， 我 们 以 图 13- 
17 来 形象 地 表示 它 与 AudioTrack 及 AudioFlinger 的 关系 。 


图 13-17 中 的 元 素 包 括 了 AudioPolicyService、AudioTrack、 
AudioFlinger 、PlaybackThread 以 及 两 个 音频 设备 (喇叭 、 耳 机 ) 。 它 
们 之 间 的 关系 如 下 《特别 注意 i 
系 ， 有 些 细节 方面 后 续 还 会 做 进一步 -3 


。 一 个 PlaybackThread 的 输出 对 应 了 一 种 设备 。 


比如 图 中 有 两 个 设备 ， 就 有 两 个 PlaybackThread 与 之 对 应 。 左 边 的 
Thread 最 终 混 首 后 输出 到 是 只， 而 右边 的 则 输出 到 耳机 。 


STREAM MUSIC 


STREAM VOICE CALL 


m 
AudioTrack | | Audio Track AudioTrack 


yY I 
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AudioPolicyService 


=| 


PlaybackThread 
AudioFlinger 


w 





全 图 13-17 AudioPolicyService 4 AudioTrack. AudioFlingert) K A A 
。 在 特定 的 时 间 ， 同 一 类 型 的 音频 对 应 的 输出 设备 是 统一 的 。 

也 就 是 说 ， 如 果 当 前 STREAM_MUS1C 对 应 的 是 喇叭 ， 那 么 所 有 该 类 型 
的 音频 都 会 输出 到 喇叭 。 结 合 上 一 点 我 们 还 可 以 得 出 一 个 结论 ， 即 同一 
类 型 音频 对 应 的 P| aybackThread 也 是 一 样 的 。 

e AudioPolicySetvice 起 到 了 路 由 器 的 作用 。 


AudioPol i cyServ i ce 在 整 选择 过 程 中 的 作用 有 点 类 似 于 网 络 路 由 
aS, a eee “SONATE” BZ 
会 “ 流 ” 向 哪个 设备 ， i 关 者 的 
数据 包 下 一 步 应 该 传递 弟 给 哪个 节点 一 样 。 


接 下 来 我 们 从 以 下 几 方 面 来 考查 AudioPolicyServi ce: 
(1) 从 启动 过 程 来 看 AudioPol icyService 的 工作 方式 ; 


(2) AudioPolicyService 如 何 通过 AudioFlinger 去 管理 音频 设 


(3) 结合 上 面 的 关系 图 详细 分 析 AudioPol icyService 是 如 何 完 
成 “路 由 功能 ” 的 ; 


(4) 分 析 Android 系 统 中 默认 的 “路 由 策略 ”。 


其 中 AudioPolicyService 的 “路 由 实现 ”因为 与 AudioTrack 关 系 紧 
密 ， 我 们 特地 把 它们 结合 起 来 进行 讲解 。 


13.4.2 AudioPolicyService 的 启动 过 程 


Mics A MRIS 分 析 AudioF linger 的 局 动 时 ， 曾经 看 到 过 
AudioPolicyService 的 “影子 ” 吗 ? 没 错 ， 它 和 AudioFlinger 是 驻 留 在 
司 一 个 进程 中 的 。 如 下 所 示 : 


/*frameworks/av/media/mediaserver/Main mediaserver.cpp*/ 
int main(int argc, char** argv) 


AudioFlinger::instantiate(); 
AudioPolicyService: :instantiate(); 


ProcessState: :self()->startThreadPool(); 
IPCThreadState: :self()->joinThreadPool(); 


因而 从 理论 上 讲 ，AudioFlinger 和 AudioPolicyService 是 可 以 直接 


进行 函数 调用 的 。 不 过 ， 实 际 上 它们 仍然 采用 标准 的 Binder 接 口 进行 通 
信 (同一 进程 中 的 Binder 通 信 细 节 ， 读 者 可 以 参考 本 书 Binder 章 节 的 描 
述 ) 。 


AudioPolicyService 的 局 动 方式 和 AudioF linger 也 类 似 ， 这 里 不 再 


Sk, BRK CHIMERA: 


AudioPolicyService: :AudioPolicyService() 


{ 


: BnAudioPolicyService() , mpAudioPolicyDev(NULL) , mpAudioPol 


char value[PROPERTY_VALUE_MAX]; 
const struct hw_module_t *module; 
int forced_val; 

int rc; 


rc = hw_get_module(AUDIO_POLICY_HARDWARE_MODULE_ID, &module); 


rc = audio_policy_dev_open(module, &mpAudioPolicyDev);//Step 


re = mpAudioPolicyDev->create_audio_policy(mpAudioPolicyDev, 
&mpAudioPolicy);//S 


rc = mpAudioPolicy->init_check(mpAudioPolicy); //Step 4. 初 始 化 

//Step 5. 加 载 音 频 效 果 配 置 文件 

if (access(AUDIO_EFFECT_VENDOR_CONFIG_FILE, R_OK) == 0) { 
loadPreProcessorConfig(AUDIO_EFFECT_VENDOR_CONFIG_FILE 


} else if (access(AUDIO_EFFECT_DEFAULT_CONFIG_FILE, R_OK) == 
loadPreProcessorConfig(AUDIO_EFFECT_DEFAULT_CONFIG_FIL 
} 


我 们 将 上 述 代 码 段 分 为 5 个 步骤 来 讲解 。 


Step1@AudioPolicyService::AudioPolicyService。 得 到 Audio 


PolicyHYhw module t， 原 生态 系统 中 Audio Policy 的 实现 有 两 个 地 
Fis Pidio poli eds tlud ool ey. hal con: 默认 情况 下 系统 选择 
的 是 后 者 (对 应 的 库 是 |ibaudiopolicy legacy) o 


Step2Q@AudiopPolicyService: :AudioPolicyService。 通 过 上 一 步 得 
到 的 hw_module_t 打 开 Audio Policy 设 备 〈 这 并 不 是 一 个 传统 意义 的 硬 
件 设备 ， 而 是 把 Policy 虚 拟 成 一 种 设备 。 这 种 实现 方式 让 开发 商 在 制定 
自己 的 音频 策略 时 多 了 不 少 灵 活性 ) 。 原 生态 代码 中 audio_policy 
_dev_open 调 用 的 是 legacy ap dev :eno No policy_hal. cpp， 最 终 
生成 的 Policy Device 是 legacy ap device。 


Step3@AudioPolicyService::AudioPolicyService。 通 过 上 述 的 
Audio Policy 设 备 来 产生 一 个 策略 ， 其 对 应 的 具体 实现 方法 是 
he nh 这 个 函数 首先 生成 一 个 
legacy audio policy@Audio policy_hal. cpp 对 象 ， 而 mpAudioPolicy 
对 应 的 则 是 legacy_audio_policy: :policy。 除 此 之 外 ， 
legacy_audio_policy 还 包含 如 下 重要 的 成 员 变量 : 


struct legacy_audio policy { 
struct audio policy policy; 
void *service; 
struct audio_policy_service_ops *aps_ops; 
AudioPolicyCompatClient *service_client; 
AudioPolicyInterface *apm; 


}; 


其 中 aps_ops 是 由 AudioPol icyService 提 供 的 函数 指针 
(aps_ops) ， 其 中 的 函数 集合 是 AudioPol icyServi ce 与 外 珊 沟 通 的 接 
口 ， 后 面 还 会 经 党 遇 到 。 


最 后 一 个 apm 是 AudioPol icyManager 的 简写 ， 
AudioPolicylnterface 是 其 基 类 。 We 
AudioPol icyManagerDefault 对 象 ， 它 是 在 create_legacy_ap 中 创建 
的 : 


static int create_legacy_ap(const struct audio_policy_device *dev 
struct audio_policy_service_ops *aps_ 
void *service, 
struct audio_policy **ap) 


struct legacy_audio_policy *lap; 


lap->apm = createAudioPolicyManager(lap->service_client); 


函数 createAudioPolicyManager 默 认 情 况 下 对 应 的 是 
AudioPolicyManagerDefault. cpp 中 的 实现 ， 所 以 它 将 返回 一 个 
AudioPol icyManagerDefault. 


是 不 是 觉得 “Policy” 相 关 的 类 越 来 越 多 了 ， 那 为 什么 需要 这 么 多 
类 呢 ? 我 们 先 来 看 一 下 它们 之 间 的 关系 ， 如 图 13-18 所 示 。 


看 起 来 很 复杂 ， 其 实 概括 一 下 束 以 下 几 点 。 


e AudioPolicyService 持 有 的 只 是 一 个 类 似 于 接口 类 的 对 象 ， 即 
audio_bolicy。 换 名 话 说 ，AudioPolicyService 是 一 个 “母体 ”， 而 
audqio_policy 则 是 一 个 符合 要 求 的 插件 。 插 件 与 壳 之 间 的 接口 是 固定 
不 变 的 ， 而 内 部 实现 却 可 以 根据 厂商 自己 的 需求 来 做 。 

。 我 们 知道 ，audio_policy 实 际 上 是 一 个 C 语 言 中 的 struct 数 据 类 型 ， 内 
部 包含 了 各 种 函数 指针 ， 如 get_output，statt_output 等 。 这 些 函 数 指 
针 在 初始 化 时 ， 需 要 指向 具体 的 函数 实现 ， 这 就 对 应 
Audio_policy_hal 中 的 ap_get_output， ap_statt_output 等 。 

。 上 面 提 到 的 各 数据 类 型 更 多 的 只 是 一 个 “过 ”， 而 真正 的 实现 者 是 
AudioPolicyManager。 与 此 相关 的 又 有 三 个 类 : AudioPolicyInterface 
是 它们 的 基 类 ，AudioPolicyManagerBase 实 现 了 一 些 基础 的 策略 ， 而 
AudioPolicyManagerDefault 则 是 最 终 的 实现 类 。 除 了 
AudioPolicyService， 后 面 这 两 个 类 也 是 我 们 研究 Audio Policy 的 重 
点 


IMO 















E Audio policy hal 中 Audio policy hal 内 部 实现 使 
A 









+gel_oulpul() tap ect output) 
+start_output() tap start_output() 

+stop outpul() tap stop output() 
trelease_output() tap telease_output() 
+inil_siream_volume() tap init stream volume() 

tset stream volume index() tap set stream volume index() 
+get stream volume index() ap gel stream volume index( 
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audio policy *mpAudioPolicy 
—audio_policy_device #mpAudioPolicy Dev 
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—audio policy policy 


-AudioPolicylnterface *ap aa 
-AudioPolicyCompatChent *service_chent 
struct audio policy service ops * aps. ops = l 
evpul) 

+startOutpul() 
+stopQutput() 
+releascOutput() 
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+tsetdtream Volumelndex() 
+getStream Volumelndext ) 
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A 13-18 Audio Policy 相关 类 的 关系 图 


Step4@AudioPol icyService: :AudioPolicyService。 进 行 初 始 化 检 
测 ， 原 生态 的 实现 直接 返回 0。 


Step5@AudioPolicyService: :AudioPolicyService。 加 载 音频 效果 
文件 “如 果 存 在 的 话 ) ， 文 件 路 径 如 下 : 


AUDIO_EFFECT_DEFAULT_CONFIG_FILE "/system/etc/audio_effects.conf" 
AUDIO_EFFECT_VENDOR_CONFIG_FILE "/vendor/etc/audio_effects.conf" 


这 样 AudioPolicyService 束 完成 了 构造 过 程 ， 而 且 它 在 
ServiceManager 中 的 注册 名 称 为 "media. audio policy"。 其 中 包含 的 
mpAudioPolicy 变 量 是 实际 的 策略 制定 者 ， 而 它 也 是 通过 HAL 层 的 库 来 创 
建 的 。 换 句 话说 ， 是 根据 硬件 厂商 自己 的 “意愿 ”来 制定 的 策略 。 


13.4.3 AudioPolicyService 与 音频 设备 


在 AudioF linger 的 “设备 管理 ”小 节 ， 我 们 曾 简单 提 及 
AudioPol icyService 将 通过 解析 配置 文件 来 加 载 当 前 系统 中 的 音频 设 
备 。 具 体 而 言 ， 当 AudioPol icyService 构 造 时 创建 了 一 个 AudioPol icy 
Device (mpAudioPolicyDev) 并 由 此 打开 一 个 
AudioPol icy (mpAudioPol icy) 一 一 这 个 Policy 默 认 情 况 下 的 实现 是 
legacy_audio_policy::policy〈 数 据 类 型 audio_policy) ; 同时 ， 
legacy_audio_policy 还 包含 了 一 个 AudioPolicylnterface 成 员 变 量 ， 
它 会 被 初始 化 为 一 个 AudioPolicyManagerDefault， 这 些 知识 点 都 是 我 
们 在 前 一 个 小 节 分 析 过 的 。 


那么 ，AudioPolicyService 在 什么 时 候 会 通过 AudioFlinger 去 加 载 
音频 设备 呢 ? 


除了 后 期 的 动态 添加 外 ， 另 外 一 个 重要 途径 就 是 通过 
AudioPolicyManagerDefault 的 父 类 ， 即 AudioPolicyManagerBase 的 构 
造 浮 数 来 加 载 育 频 设备 : 


AudioPolicyManagerBase: :AudioPolicyManagerBase(AudioPolicyClientI 
Interface)... 
{ mpClientInterface = clientInterface; 


if (loadAudioPolicyConfig(AUDIO_POLICY_VENDOR_CONFIG_FILE) != 
if (loadAudioPolicyConfig(AUDIO_POLICY_CONFIG_FILE) != NO 
defaultAudioPolicyConfig(); 
} 
} 


for (size_t i = 0; i < mHwModules.size(); i++) { 
mHwModules[i]->mHandle = mpClientInterface->lLoadHwModule( 
if (mHwModules[i]->mHandle == 0) { 
continue; 
} 


for (size_t j = 0; j < mHwModules[i]->mOutputProfiles.siz 


const I0Profile *outProfile = mHwModules[i]->mOutputPr 
if (outProfile->mSupportedDevices & mAttachedOutputDev 
AudioOutputDescriptor *outputDesc = new AudioOutpu 
outputDesc->mDevice = (audio_devices_t)(mDefaultOu 
outProfile->m 

audio_io_handle_t output = mpClientInterface->openOutp 





不 同 的 Android 产 品 在 音频 硬件 的 设计 上 通常 是 有 差异 的 利用 
配置 文件 的 形式 〈audio_policy. conf) 来 描述 产品 中 所 包含 的 具体 音 
为 我 们 进行 定制 开发 提供 了 便捷 的 实现 。 这 个 文件 的 存放 路 径 

FA AL : 


#define AUDIO _POLICY_VENDOR_CONFIG_FILE "/vendor/etc/audio_policy 
#define AUDIO_POLICY_CONFIG_FILE "/system/etc/audio_policy.conf" 


gn Raudio_policy. conf 不 存在 的 话 ， 则 系统 将 使 用 默认 的 配置 ， 
具体 就 在 defaultAudioPolicy Config 中 。 通 过 配置 文件 可 以 读 取 到 如 
下 信息 : 


o 有 哪些 audio interface, WARA “primary” “a2dp” “usb” ; 

e 4 audio intetface 的 属性 ， 如 支持 的 sampling rates, formats x 4H 
些 device 等 。 这 些 属性 是 在 loadOutput@AudioPolicyManagerBase 中 读 
取 的 ， 并 存储 到 HwModule-> mOutputPtrofiles 中 。 每 一 个 audio 
interface 下 可 能 有 老 干 个 output 和 input， 而 每 个 output/input 下 又 具体 
描述 了 它们 所 支持 的 若干 属性 ， 其 关系 如 图 13-19 所 示 。 





Audio interface: | primary/a2dp/usb 


m 


sampling Tate 
channel masks 


formats 


devices 
flags 





A 13-19 audio_policy.conf F AA KAA 


读者 可 以 自己 打开 一 个 audio_policy. conf 来 具体 了 解 这 个 文件 的 
编写 格式 ， 我 们 这 里 就 不 深入 讲解 了 。 

读 取 了 相关 配置 后 ， 接 下 来 就 要 打开 这 些 设备 。 我 们 知道 
AudioPolicyService 只 是 策略 的 制定 者 ， 而 非 执 行者 。 那 么 ， 由 谁 来 完 
成 这 些 具体 的 打开 工作 了 呢 ? 没 错 ， 一 定 是 AudioF 1inger 。 可 以 看 到 上 述 
芳 数 段 中 有 一 个 mpClientlnterface 变 量 ， 它 是 否 和 AudioFlinger 有 联 
FA? 先 来 分 析 这 个 变量 的 来 源 。 


很 明显 ，mpClientlnterface 在 AudioPolicyManagerBase 构 造 亢 数 
的 第 一 行进 行 了 初始 化 。 有 绸 回溯 追踪 ， 不 难 发 现 它 的 根源 在 
AudioPol icyService 的 构造 函数 中 ， 对 应 的 代码 语句 如 下 : 


rc = mpAudioPolicyDev->create_audio_policy(mpAudioPolicyDev, &aps 


fEXX MAST, MBWcreate_audio_policyMMAN= 
create_legacy_ap， 并 将 传 入 的 aps_ops 组 装 到 一 个 
AudioPol icyCompatClient 对 象 中 ， 即 mpClientlnterface 所 指向 的 那个 
对 象 。 


换 句 话说 ，mpClientlnterface->1loadHwModule 实 际 上 调用 的 就 是 
aps_ops->loadHwModule. BJ: 


static audio_module_handle_t aps_load_hw_module(void *service,con 
sp<IAudioFlinger> af = AudioSystem::get_audio_flinger(); 


return af->LoadHwModule(name) ; 


AudioFlinger 终 于 出 现 了 一 一 同样 的 情况 也 适用 于 
mpClientlnterface->open0utput。 具 体 代 码 如 下 : 


static audio_io_handle_t aps_open_output (...) 
sp<IAudioFlinger> af = AudioSystem::get_audio_flinger(); 


return af->openOutput((audio_module_handle_t)0, pDevices, pSa 
pChannelMask, pLatencyMs, flags); 


#4 [2] Zl]AudioPol icyManagerBase 的 构造 函数 中 ，for 循 环 的 目标 有 
两 个 。 


° 利用 1oadHwModule 来 加 载 从 audio_policy. conf 中 解析 出 的 
Audio lnterface， 即 mHwModules 数 组 中 的 元 素 。 


° 利用 open0utput 来 打开 各 Audio lnterface 中 包含 的 所 有 
Output. 


关于 AudioFlinger 中 上 述 这 两 个 函数 的 实现 ， 我 们 在 前 一 个 小 节 已 
经 分 析 过 ， 这 里 终于 把 它们 “ 串 ” 起 来 了 。 通 过 
AudioPol icyManagerBase，AudioPolicyService 解 析出 了 设备 中 的 音频 
配置 文件 ， 并 利用 AudioF linger 提 供 的 接口 完成 了 整个 音频 系统 的 部 
署 ， 从 而 为 后 续 上 层 应 用 使 用 音频 设备 提供 了 底层 支撑 。 


下 一 节 我 们 束 可 以 看 到 上 层 应 用 具体 如 何 使 用 这 一 框 染 来 回放 音 





13.5 音频 流 的 回放 AudioTrack 


13.5.1 AudioTrack 应 用 实例 


虽然 很 多 人 对 MediaPlayer 并 不 陌生 ， 但 了 解 AudioTrack 的 估计 就 
比较 少 了 。 这 是 因为 MediaPlayer 提 供 了 更 完整 的 封装 和 状态 控制 ， 使 
得 我 们 用 很 少 的 代码 就 可 以 实现 一 个 简单 的 音乐 播放 器 。 相 比 
MediaPlayer，AudioTrack 则 更 为 精练 、 高 效 〈 实 际 上 
MediaPlayerService 实 现 音频 回放 就 是 使 用 了 AudioTrack) ào 


AudioTrack 被 用 于 PCM 音 频 流 的 回放 ， 在 数据 传送 上 有 两 种 方式 。 


e 调用 write (byteL], int, int) write (short[], int, int) 把 音 
频数 据 “push” 到 AudioTrack 中 。 


° SZH, HAME “pull” RAM HIRT, Bl “Bh 
据 接 收 方 ”主动 索取 的 过 程 ， 如 图 13-20 所 示 。 


| 
callback] 
| 


Receiver 





全 图 13-20 “push” 和 “pull” 两 种 数据 传送 模式 


| 除 此 之 外 ，AudioTrack 还 同时 支持 static 和 streaming 两 种 数据 模 


I 


@ static 
静态 就 是 指数 据 一 次 性 交付 给 接收 方 。 其 好 处 是 简单 高 效 ， 只 需 进 
行 一 次 操作 就 完成 了 所 有 数据 的 传递 ;缺点 当然 也 很 明显 一 一 对 于 数据 
量 较 大 的 音频 回放 ， 它 是 无 法 胜任 的 。 因 而 这 种 模式 通常 只 适用 于 铃 
声 、 系 统 提醒 等 对 内 存 要 求 小 的 播放 操作 。 


e streaming 


流 模 式 和 基于 网 络 的 音频 流 回 放 类 似 ， 即 音频 数据 严格 按照 要 求 不 
断 地 传递 给 接收 方 ， 直 到 结束 。 理 论 上 它 适 用 于 任何 音频 播放 的 场景 ， 


不 过 我 们 通常 会 在 以 下 情况 中 优先 考虑 采用 。 
。 音频 文件 较 大 时 。 
° 音频 属性 要 求 高 ， 如 采样 率 高 、 深 度 大 的 数据 。 
° 音频 数据 是 实时 产生 的 ， 这 种 情况 就 只 能 用 流 模 式 了 。 


下 面 我 们 选取 源码 工程 中 的 MediaAudioTrackTest. java 范 例 来 讲解 
AudioTrack 的 典型 应 用 ， 具 体 如 下 所 示 : 


public void testSetStereoVolumeMax() throws Exception { 

final String TEST_NAME = "testSetStereoVolumeMax"; 

final int TEST_SR = 22050; 

final int TEST_CONF = AudioFormat .CHANNEL_OUT_STEREO; 

final int TEST_FORMAT = AudioFormat .ENCODING_PCM_16BIT; 

final int TEST_MODE = AudioTrack.MODE_STREAM; 

final int TEST_STREAM_TYPE = AudioManager .STREAM_MUSIC; 

/*Step 1. 计 算 最 小 缓冲 区 大 小 */ 

int minBuffSize = AudioTrack.getMinBufferSize(TEST_SR, TE 

/*Step 2. 生 成 AudioTrack 对 象 */ 

AudioTrack track = new AudioTrack(TEST_STREAM_TYPE, TEST_ 
TEST_FORMAT, minBuffSiz 

byte data[] = new byte[minBuffSize/2]; 

//-------- test w+ eee eee 

track.write(data, 0, data.length);//SA mach 

track.write(data, 0, data.length); 

track.play();// 开 始 播放 音频 

float maxVol = AudioTrack.getMaxVolume( ) ;// 获 取 最 大 音量 值 

assertTrue(TEST_NAME, track.setStereoVolume(maxVol, maxVo 

//-------- tear down = -------------- 

track.release(); 





} 


上 述 这 个 TestCase 用 于 测试 立体 声 左 右 声 道 的 最 大 音量 ， 范 例 中 涉 
及 的 AudioTrack 的 常规 操作 都 用 高 显 标示 出 来 了 《顺便 提 一 下 ， 关 于 
Android 自 动 化 测试 的 更 多 描述 ， 可 以 参考 本 书 最 后 一 个 篇 章 ) o 


包括 如 下 几 个 步骤 : 
Step1@testSetStereoVolumeMax. K#tgetMinBufferSize FAS 


思 是 获取 最 小 的 buffer 大 小 ， 这 个 buffer 将 用 于 后 面 AudioTrack 的 构造 
顺 数 。 它 是 AudioTrack 可 以 正常 使 用 的 一 个 最 低 保障 一 一 如 果 音 频 文件 


本 身 要 求 较 高 ， 官 方 建议 最 好 采用 比 MinBufferSize 更 大 的 数值 。 这 个 
函数 的 具体 实现 如 下 (分 段 阅 读 ) : 


static public int getMinBufferSize(int sampleRateInHz, int channe 

int channelCount = 0; 

switch(channelConfig) { 

case AudioFormat .CHANNEL_OUT_MONO: 

case AudioFormat .CHANNEL_CONFIGURATION_MONO: 
channelCount = 1; 
break; 

case AudioFormat .CHANNEL_OUT_STEREO: 

case AudioFormat .CHANNEL_CONFIGURATION_STEREO: 
channelCount = 2; 
break; 

default: 


} 
首先 得 出 音频 的 声 道 数 属性 。 由 channe1Count 这 个 变量 的 处 理 过 程 
可 知 目前 版 本 的 系统 最 多 只 支持 双 声 道 : 
if ((audioFormat != AudioFormat.ENCODING PCM 16BIT) 


&& (audioFormat != AudioFormat.ENCODING_PCM_8BIT)) { 
return AudioTrack.ERROR_BAD_VALUE; 


} 
紧 接着 检查 音频 采样 深度 ， 只 支持 8bit 和 16bit 两 种 : 
if ((sampleRateInHz < SAMPLE_RATE_HZ_MIN) | |(sampleRateInH 
loge("getMinBufferSize(): " + sampleRateInHz +"Hz is n 


return AudioTrack.ERROR_BAD_VALUE; 
} 


最 后 还 需要 检查 采样 频率 。 其 支持 的 范围 并 不 算 究 ， 但 对 大 部 分 应 
用 场合 都 是 适用 的 ， 即 
4k (SAMPLE_RATE_HZ_MIN)—48Khz (SAMPLE_RATE_HZ_MAX) : 


int size = native_get_min_buff_size(sampleRateInHz, chann 








}//getMinBufferSize 结 束 


也 就 是 说 ， 最 小 的 buffer 大 小 取决 于 采样 率 、 声 道 数 和 采样 深度 这 
3 个 属性 。 那 么 ， 具 体 是 如 何 计 算 的 呢 ? 我 们 接着 看 看 native 层 的 代码 


实现 : 


frameworks/base/core/jni/android_media_AudioTrack.cpp 
static jint android_media_AudioTrack_get_min_buff_size(JNIEnv *en 
jint sampleRateInHertz, jint nbCha 





int frameCount = 0; 
if (AudioTrack: :getMinFrameCount (&frameCount, AUDIO _STREAM_DE 
sampleRateInHertz) != NO_ERROR) { 
return -1; 


J 


return frameCount * nbChannels * (audioFormat == javaAudioTra 





这 里 又 调用 了 getMinFrameCount 负数 用 于 确定 至 少 需要 多 
少 Frame 才 能 保证 音频 的 正常 播放 。 Wt, eater eee 
家 可 以 类 比 一 下 视频 中 “ 帧 ”的 概念 Ea Sa TATE) Ra 的 一 幅 图 
像 。 这 里 的 Frame 也 相似 ， 它 指 的 是 某 个 特定 时 间 点 时 的 音频 数据 量 ， 
所 以 android media AudioTrack_get min_buff_size 中 最 后 使 用 的 计算 
公式 就 是 : 





最 小 缓冲 区 大 小 = 至 少 需要 多 少 帧 * 每 帧 数据 量 


= frameCount * nbChannels * (audioFormat == 
javaAudioTrackFields.PCM16 ? 2 : 1); 


公式 中 frameCount 就 是 所 需要 的 帧 数 ， 每 一 帧 的 数据 量 又 等 于 : 


Channe| 数 # 每 个 Channe1 数 据 量 =nbChannels * (audioFormat == 
javaAudioTrackFields.PCM16 ? 2 : 1) 


然后 函数 层 层 返 回 直到 getMinBufferSize， 我 们 就 得 到 了 能 保障 
AudioTrack 正 常 工 作 的 最 小 缓冲 区 大 小 。 


Step2@testSetStereoVolumeMax。 创 建 AudioTrack 实 例 。 


有 了 minBufferSize 后 ， 我 们 就 可 以 创建 一 个 AudioTrack 对 象 了 。 
它 的 构造 函数 原 型 是 : 


public AudioTrack (int streamType, int sampleRateInHz, int channe 


除了 倒数 第 二 个 参数 是 计算 出 来 的 ， 其 他 入 参 在 这 个 TestCase 中 都 


是 直接 指定 的 。 比 如 streamType 是 STREAM_MUS1C，samp leRatelnHz 是 
22050 等 。 如 果 我 们 使 用 AudioTrack 来 编写 一 个 合 乐 播放 器 ， 那 么 这 些 
参数 都 是 需要 通过 分 析 音 频 文 件 得 出 来 的 。 幸 运 的 是 Android 系 统 提供 
了 更 加 易 用 的 MediaPlayer， 使 得 开发 者 不 需要 理会 这 些 琐 磅 细节 。 


创建 AudioTrack 的 一 个 重要 任务 就 是 和 AudioF1inger 建 立 联 系 ， 它 
是 由 native 层 的 代码 来 实现 的 : 


public AudioTrack(int streamType, int sampleRateInHz, int cha 
int bufferSizeInBytes, int mode, int sessionId) 
throws IllegalArgumentException { 


int initResult = native_setup(new WeakReference<AudioTrac 
mStreamType, mSampleRate, mChannels, mAudioFormat, 
mNativeBufferSizeInBytes, mDataLoadMode, session); 


} 


这 里 调用 了 native setup 来 创建 一 个 本 地 的 AudioTrack 对 象 。 如 下 
所 示 : 


/*frameworks/base/core/jni/android media AudioTrack.cpp*/ 

static intandroid_media_AudioTrack_native_setup(JNIEnv *env, jobj 
jint streamType, jint sampleRateInHertz, jint javaChannelMa 
jint audioFormat, jint buffSizeInBytes, jint memoryMode, ji 


sp<AudioTrack> lpTrack = new AudioTrack(); 


AudioTrackJniStorage* lpJniStorage = new AudioTrackJniStorage 


生成 一 个 Storage 对 象 ， 直 觉 告诉 我 们 这 可 能 是 存储 音频 数据 的 地 
方 ， 后 面 骨 详细 分 析 : 


if (memoryMode == javaAudioTrackFields.MODE_STREAM) { 
lpTrack->set (... 
audioCallback，// 回 调 函 数 
&(1lpJniStorage->mCcallbackData),// 回 调 数据 





0,// shared mem 
true,// thread can call Java 
sessionId);// audio session ID 
} else if (memoryMode == javaAudioTrackFields.MODE_STATIC) { 


lpTrack->set (... 
audioCallback, &(lpJniStorage->mCallbackData), © 
1lpJniStorage->mMemBase,// shared mem 
true,// thread can call Java 
sessionid);// audio session ID 





..//native_setupZi R 


为 数 native_setup 首 先生 成 了 一 个 AudioTrack (native) TR, FR 
进行 各 种 属性 的 计算 ， 最 后 调用 set ch)? 数 为 AudioTrack 设 置 这 些 属性 
一 一 其 中 需要 特别 注意 的 是 两 种 内 存 模式 〈MODE_STAT1C 和 
MODE_STREAM) 下 处 理 手法 的 差异 。 对 于 静态 方式 ，set 函 数 的 倒数 第 三 


个 参数 是 lpJniStorage->mMemBase; 而 STREAM 类 型 时 这 个 参数 则 为 
o | (0) 。 


到 目前 为 止 我 们 还 没有 看 到 AudioTrack 与 AudioFlinger 有 交互 的 地 
方 ， 看 来 谜底 应 该 就 在 这 个 set 函 数 中 了 “〔 分 段 阅读 ): 


status_t AudioTrack::set(..callback_t cbf, void* user, int notific 
const sp<IMemory>& sharedBuffer, bool threadCanCallJava, int sess 


AutoMutex lock(mLock); 


if (streamType == AUDIO _STREAM_DEFAULT) { 
streamType = AUDIO_STREAM_MUSIC; 
} 


当 AudioTrack 没 有 特别 指明 streamType 时 ， 程 序 会 为 它 设 置 一 个 默 
认 的 值 ， 即 AUD10_STREAM_MUS1C: 





if (format == AUDIO_FORMAT_DEFAULT) {// 默 认 的 采样 深度 值 
format = AUDIO_FORMAT_PCM_16_BIT; 





} 
if (channelMask == 0) {// 默 认 声 道 数 
channelMask = AUDIO CHANNEL OUT_STEREO; 


采样 深度 和 声 道 数 的 默认 值 分 别 为 16bit 和 了 立体声: 


if (format == AUDIO_FORMAT_PCM_8_BIT && sharedBuffer != 0) { 
ALOGE("8-bit data in shared memory is not supported"); 


return BAD_VALUE; 
} 


当 sharedBuffer1=0 时 表明 是 STAT1C 模 陈 。 也 就 是 说 ， 静态 数据 模 
式 下 只 支持 16b it 采样 深度 ， 否 则 就 会 报错 并 直接 返回 ， 这 点 要 特别 注 


ms 


alk 


audio_i1o0_handle_t output = AudioSystem::getOutput(streamType, sam 
channelMask, fla 


通过 上 述 的 有 效 性 检查 后 ，AudioTrack 接 着 就 可 以 使 用 底层 的 音频 
服务 了 。 那 么 ， 是 直接 调用 AudioF 1 inger 服 务 提 供 的 接口 吗 ? 理论 上 这 
样 做 也 是 可 以 的 ， 但 Android 系 统考 虑 得 更 细致 ， 它 在 AudioTrack 与 底 
层 服 务 间 又 提供 了 AudioSystem 和 AudioService。 前 者 同时 提供 了 Java 
和 Native 两 层 的 接口 实现 ; 而 AudioService 则 只 有 Native 层 的 实现 。 这 
样 就 降低 了 使 用 者 (AudioTrack) 与 底层 服务 (AudioPol icyService、 
AudioFlinger 等 ) 间 的 耦合 。 换 句 话 说， 不 同 版 本 的 Android 音 频 系 统 
通常 改动 很 大 ， 但 只 要 AudioSystem 和 AudioService 同 上 的 接口 不 变 
那么 AudioTrack 就 不 需要 做 任何 修改 。 


上 面 的 get0utput 函 数 是 由 AudioSystem 提 供 的 ， 不 过 可 以 猜测 到 其 
内 部 只 是 做 了 些 简单 的 中 转 工作 ， 最 终 还 是 得 由 
AudioPolicyService/AudioFlinger 来 实现 具体 功能 。 这 个 get0utput 会 
在 当前 系统 中 寻找 最 适合 AudioTrack 的 Audio lnterface 以 及 0utput 输 
出 〈 即 AudioFlinger 中 通过 open0utput 打 开 的 通道 ) ， 然 后 AudioTrack 
会 向 这 个 0utput 申 请 一 个 Track : 


mVolume [LEFT] = 1.0f; 
mVolume[RIGHT] = 1.0f; /* 左 右 声 道 的 初始 音量 值 都 设置 成 最 大 。AudioTra 
在 这 里 赋值 ， 源 代码 略 */ 





if (cbf != NULL) { 
mAudioTrackThread = new AudioTrackThread(*this, threadCan 
mAudioTrackThread->run("AudioTrack", ANDROID_PRIORITY_AUD 
J 


status_t status = createTrack_l(..sharedBuffer, output); 


}//AudioTrack: :set 函数 结束 


因为 cbf 不 为 空 ， 所 以 这 里 会 启动 一 个 AudioTrack 线 程 。 


AudioTrackThread 需 要 实现 两 个 核心 功能 。 
e AudioTrack 与 AudioFlinger 间 的 数据 传输 


我 们 知道 AudioF1inger 启 动 了 一 个 线程 专门 用 于 接收 客户 端的 音频 
数据 ; 同 理 ， 客 户 端 也 需要 一 个 工作 线程 来 “不 断 ” 地 传送 音频 数据 。 


。 用 于 报告 数据 传输 状态 


音频 传输 过 程 中 可 能 会 有 多 种 事件 发 生 ， 如 underrun。 此 时 需 ca 
断 回 传 状 态 给 使 用 者 进行 相应 处 理 。AudioTrack 中 保存 了 〈 即 全 局 变 
mCbf) 一 个 cal lback_t 类 型 的 回调 函数 ， 用 于 事件 发 生 时 进行 回 传 。 


cal lback_t 为 上 层 应 用 处 理事 件 提供 了 一 个 入 口 。 包 括 : 


EVENT_MORE_DATA = 0, /* 请 求 写 入 更 多 数据 */ 

EVENT_UNDERRUN = 1, /* 音 频传 输 发 生 了 underrun 问 题 */ 

EVENT_LOOP_END = 2, ”/* 到 达 loop end， 此 时 如 果 loop count 不 为 空 的 话 
将 从 loop start 重 新 开始 回放 */ 

EVENT_MARKER = 3, /*Playback head 在 指定 的 位 置 ， 参 考 SetMarkerPosii 
EVENT_NEW_POS = 4, /*Playback head 在 一 个 新 的 位 置 ， 参 考 setPositionUpda 
EVENT_BUFFER_END = 5 /*Playback head 在 buffer 末 尾 */ 


AudioTrack 在 AudioFlinger 内 部 是 以 Track 类 来 管理 的 。 不 过 因为 
它们 之 间 是 跨 进 程 的 关系 ， 自 然 需要 一 个 “桥梁 ”来 维护 ， 这 个 沟通 的 
媒介 是 laudioTrack 〈 有 点 类 似 于 显示 系统 中 的 1window) . AZ 
createTrack _ 1 除了 为 AudioTrack 在 AudioFlinger 中 申请 一 个 Track 外 ， 
还 会 建立 两 者 间 的 1AudioTrack 桥 梁 : 


status_t AudioTrack: :createTrack_1( 
audio_stream_type_t streamType, uint32_t sampleRate, audio_ 
channelMask, 
int frameCount, audio_output_flags_t flags, const sp<IMemo 
audio_io_handle_t output) 


const sp<IAudioFlinger>& audioFlinger = AudioSystem: :get_audi 


获得 AudioFlinger 服 务 ， 还 记得 上 一 小 节 的 介绍 吗 ? AudioF | inger 
会 在 ServiceManager 中 注册 ， 并 以 a aud a eer” 为 服务 
名 : 


TAudioF linger: :track_flags_t trackFlags = IAudioFlinger: : TRAC 


sp<IAudioTrack> track = audioFlinger->createTrack(getpid(),st 
format, channelMask, frameCount, trackF 
output, tid, &mSessionId, &status); 
// 未 完 待 续 .. 


利用 AudioFlinger 创 建 一 个 IAudioTrack， 这 是 它 与 AudioTrack 之 
间 的 跨 进 程 通道 。 除 此 之 外 ，AudioFlinger 还 做 了 什么 ? 我 们 深入 
AudioFlinger 进 行 分 析 : 


sp<IAudioTrack> AudioFlinger::createTrack(..const sp<IMemory>& sha 
handle_t output, 

pid_t tid, int *sessionId, status_t *status) 
1 


sp<PlaybackThread: :Track>track; 
sp<TrackHandle> trackHandle; 


PlaybackThread *thread =checkPlaybackThread_1l(output ) ， 
PlaybackThread *effectThread = NULL; 


track = thread->createTrack_l(client, streamType, sampleRate, 
channelMask, frameCount, sharedBuffer, 1SessionId, f 


if (lStatus == NO_ERROR) { 

trackHandle = new TrackHandle(track)j; 
} else { 

client.clear(); 

track.clear(); 


t 


return trackHandle; 


我 们 只 留 下 createTrack 中 最 重要 的 几 个 步骤 ， 即 : 
e AudioFlinget::checkPlaybackIhtread_] 


在 AudioFlinger: :open0utput 时 ， 产 生 了 全 局 唯一 的 
audio_io_ handle t 值 ， 这 个 值 是 与 PlaybackThread 相 对 应 的 ， 它 作为 
mpPlaybackThreads 键 值 对 的 key 值 存在 。 


当 AudioTrack 调 用 createTrack 时 ， 需 要 传 入 这 个 全 局 标记 值 ， 
checkPlaybackThread 1 借 此 找到 匹配 的 PlaybackThread。 


e PlaybackThread::createTrack_l 


找到 匹配 的 PlaybackThread 后 ， 还 需要 在 其 内 部 创建 一 个 
Pl aybackThread: :Track 对 象 (所 有 Track 都 由 
PlaybackThread: :mTracks 全 局 变量 管理 ) ， 这 些 工 作 由 
PlaybackThread: :createTrack 1 完成 。 我 们 以 图 13-21 来 表示 它们 之 间 
的 关系 。 


mPlaybackThreads 
audio 10 handle t, 
sp<Playback Thread> 


AudioTrack 


Playback Thread: Track | | PlaybackThread::Track 


mTracks 





A 13-21 PlaybackThread 中 对 Track 的 管理 


e new TrackHandle 


TrackHandle 实 际 上 就 是 IAudioTrack， 后 续 AudioTrack 将 利用 这 个 
Binder 服 务 来 调用 getCb1lk 等 接口 。 


我 们 接着 前 面 AudioTrack: :createTrack 1 中 “未 完 待 续 ” 的 部 分 
往 下 看 : 


sp<IMemory> cblk = track->getCblk(); 


mAudioTrack = track; 
mCblkMemory = cblk; 
mCblk = static_cast<audio_track_cblk_t*>(cblk->pointer()); 


if (sharedBuffer == 0) { 

mCblk->buffers = (char*)mCblk + sizeof(audio_track_cblk_t 
} else { 

mCblk->buffers = sharedBuffer->pointer(); 

mCb1k->stepUser (mCb1lk->frameCount ) ; 
} 


return NO_ERROR; 


事实 上 当 PlaybackThread 创 建 一 个 PlaybackThread: :Track 对 象 
时 ， 所 需 的 缓冲 区 空间 就 已 经 分 配 了 。 这 块 空间 是 可 以 跨 进 程 共享 的 ， 
所 以 AudioTrack 可 以 通过 track->getCblk () 来 获取 。 看 起 来 很 简单 的 一 
oe 其 中 却 涉及 很 多 细节 ， 我 们 会 在 后 面 的 数据 流 小 节 做 统一 分 


到 目前 为 止 ，AudioTrack 已 经 可 以 通过 laudioTrack 〈 即 上 面 代码 
段 中 的 track 变 量 ) 来 调用 AudioFlinger 提 供 的 服务 了 。 我 们 以 图 13-22 
来 总 结 这 一 小 节 。 


创建 了 AudioTrack 后 ， 应 用 实例 就 可 以 通过 不 断 写 入 
(AudioTrack: :write) 音频 数据 来 回放 声音 。 这 部 分 代码 与 音频 数据 
流 有 关 ， 我 们 也 放 在 后 面 小 节 中 分 析 。 


Audio 













Track(native) 
| | | openQutput 
| | | | 
! | | create audio io handle t 
| | | | 
Steel | | PlaybackThrcad 
Setup | | ! (audio io handle 1) 
| 
| | 
| | | 
| | | 
| | | 
get(utput | | 





audio 10 handle t 








| 
create | | 
Track 1 | | 
| | 

| 


| 
| track=PlaybackThread 
“Create Track | 

| 
TAudioTrack new [AudioTrack(track) 


| | | 
| | 
mCblkMemory=lAudioTrack::getChlk 
| 
mCblk=static-cast< audio track cblk t > 
(mCblkMemory-=>pointer(}); 
| | 





全 图 13-22 AudioTrack 4] 4 AFA 

13.5.2 AudioPolicyService 的 路 由 实现 

我 们 在 AudioPolicyService 小 节 曾 将 其 比 作 一 个 “路 由 器 ”， 不 过 
还 没有 深入 解析 它 是 如 何 完成 路 由 路 径 的 选择 的 。 这 个 功能 的 实现 与 使 
用 者 一 一 AudioTrack 有 很 大 关联 ， 所 以 我 们 特地 放 在 本 小 节 进 行 剖 析 ， 
希望 读者 可 以 综合 起 来 理解 。 

“路 由 器 ” (AudioPolicyService) 由 如 下 几 个 核心 部 分 组 成 。 

o 与 发 送 方 (AudioTrack) 的 接口 


“路 由 器 ”首先 要 接收 到 一 个 1P 数 据 包 才能 去 做 路 由 处 理 ， 否 则 就 
会 变 成 “无 源 之 水 ”。 
© 与 接收 方 ( AudioFlinger) 的 接口 
道理 和 上 面 类 似 ，AudioPolicyService 内 部 拥有 当前 系统 中 所 有 音 
频 设 备 的 信息 。 这 就 好 比 一 个 “路 由 器 ”也 需要 预先 知道 它 有 多 少 个 路 
由 节点 ， 才 可 能 把 音频 数据 发 送 到 下 一 个 正确 的 节点 。 
© 路 由 路 径 的 算法 策略 


“路 径 选 择 策略 ”是 AudioPolicyService 的 重点 。 和 传统 的 “路 由 
器 ”不 同 ， 它 的 路 径 选 择 算法 并 不 是 固定 的 ， 而 是 通过 灵活 的 定制 方式 
由 各 厂商 自行 实现 。 


大 家 应 该 还 记得 在 前 面 AudioTrack 范 例 小 节 的 分 析 中 ， 我 们 调用 了 
AudioSystem: :getOutput. BJ: 





status_t AudioTrack::set(...) 


audio_io_handle_t output = AudioSystem: :getOutput(streamType, 
channel Mas 


AudioSystem 只 是 一 个 中 介 ， 其 中 的 实现 还 是 由 


Audi oPol icyService 完 成 的 : 


audio_io_handle_t AudioSystem: :getOutput (...) 


{ 
const sp<IAudioPolicyService>& aps = AudioSystem: :get_audio_p 
if (aps == 0) return 0; 
return aps->getOutput(stream, samplingRate, format, channels, 
} 


显然 是 直接 调用 了 AudioPolicyService 的 服务 接口 : 
audio_io_handle_t AudiopolicyService::getOutput(...) 


Mutex: :Autolock _1(mLock); 
return mpAudioPolicy->get_output(mpAudioPolicy, stream, sampl 
channelMask, flags); 


变量 mpAudioPol icy 便 是 由 策略 制定 者 “生产 ”出 来 的 Policy。 在 
原生 态 的 实现 中 它 代表 的 是 
legacy_audio policy: :policy@Audio policy_hal. cpp， 因 而 上 面 的 
get_output 实 际 上 调用 的 是 如 下 函数 : 


static audio_io_handle_t ap_get_output(struct audio_policy *pol,... 





struct legacy_audio_policy *lap = to_lap(pol); 
return lap->apm->getOutput((AudioSystem: :stream_type)stream, 
format, channelMask, (AudioSystem: :ou 


也 就 是 说 ， 前 面 的 get0utput 的 接口 实现 最 终 是 落 在 
getOutput@AudioPol icyManagerBase (Audio Pol icyManagerDefault2Z& 
承 自 AudioPol icyManagerBase， 而 后 者 又 继承 自 
AudioPolicylnterface) 中 。 


我 们 先 来 看 看 AudioPolicyManagerBase 的 get0utput 实 现 : 


/*hardware/libhardware_legacy/audio/AudioPolicyManagerBase.cpp*/ 

audio_io_handle_t AudioPolicyManagerBase: :getOutput(AudioSystem: : 
uint32_t samplingRate, uint32_t form 
uint32_t channelMask, AudioSystem::o 


audio_io_handle_t output = 0; 
uint32_t latency = 0; 


/*Step 1. 获取 stream 音 频 类 型 对 应 的 Strategy: */ 
routing_strategy strategy = getStrategy( (AudioSystem::stream_ 
audio_devices_t device = getDeviceForStrategy(strategy, false 


/*Step 2. 应 用 策略 ， 判 断 哪些 Output 符 合用 户 传 入 的 stream 类 型 : */ 
SortedVector<audio_io_handle_t> outputs = getOutputsForDevice 
/*Step 3. 选择 一 个 最 适合 的 Output: */ 

output = selectOutput(outputs, flags); 

return output; 


我 们 将 上 述 代码 段 分 为 3 个 步骤 。 
Step1@AudioPolicyManagerBase: :get0utput。 每 种 Stream 类 型 都 
有 对 应 的 路 由 策略 (Routing Strategy) ， 如 AudioSystem: :TTS 和 
AudioSystem: :MUS1C 两 种 “音频 流 ” 都 对 应 的 是 STRATEGY_MEDIA; 而 
AudioSystem: :NOTIFICATION 流 则 对 应 的 是 
STRATEGY SONIFICATION RESPEC TFUL. 


StreamType 和 RoutingStrategy 的 对 应 关系 如 表 13-5 所 示 。 


表 13-5 Stream 类 型 与 Strategy 对 照 表 
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Default (SKU tain FD 





ENFORCED_AUDIBLE|STRATEGY_ENFORCED_AUDIBLE 


由 此 可 见 ， 不 同 的 Stream 类 型 也 有 可 能 被 划 归 到 同一 个 Strategy。 
比如 TTS、MUS1C 及 SYSTEM 类 型 的 音频 ， 它 们 在 路 由 策略 上 都 遵循 
STRATEGY_MED1A。 另 外 ， 默 认 情 况 下 系统 会 采用 STRATEGY_MED1A 类 型 的 
策略 。 当 然 ， 我 们 也 可 以 通过 重 载 getStrategy 来 按 自己 的 要 求 划分 
Strategy。 


当 找 到 某 Stream 类 型 对 应 的 Strategy 后 ， 接 下 来 的 
getDeviceForStrategy 将 进一步 为 这 一 Strategy 匹 配 最 佳 的 音频 设备 
(以 STRATEGY_MEDIA 为 例 ) : 


audio_devices_t AudioPolicyManagerBase: :getDeviceForStrategy(rout 
uint32_t device = AUDIO_DEVICE_NONE; 
switch (strategy) {... 
case STRATEGY_MEDIA: { 
uint32_t device2 = AUDIO _DEVICE_NONE; 


if ((device2 == AUDIO _DEVICE_NONE) &&mHasA2dp && 
(mForceUse[AudioSystem: :FOR_MEDIA] != AudioSystem: : 


(getA2dpOutput() != 0) && !mA2dpSuspended) { 
device2 = mAvailableOutputDevices & AUDIO _DEVICE_OUT_BLU 
if (device2 == AUDIO_DEVICE_NONE) { 

device2 = mAvailableOutputDevices & 
AUDIO_DEVICE_OUT_BLUETOOTH_A2DP_HE. 


if (device2 == AUDIO_DEVICE_NONE) { 
device2 = mAvailableOutputDevices & 
AUDIO_DEVICE_OUT_BLUETOOTH_A2DP_SP 


J 


if (device2 
device2 


== AUDIO_DEVICE_NONE) { 
= mAvailableOutputDevices & AUDIO_DEVICE_OUT_WI 
if (device2 == AUDIO_DEVICE_NONE) { 

device2 = mAvailableOutputDevices & AUDIO _DEVICE_OUT_WI 


} 
if (device2 == AUDIO DEVICE NONE) { 
device2 = mAvailableOutputDevices & AUDIO_DEVICE_OUT_US 


} 
if (device2 == AUDIO_DEVICE_NONE) { 
device2 = mAvailableOutputDevices & AUDIO_DEVICE_OUT_US 


} 

…// 其 他 优先 级 匹配 做 法 类 似 ， 代 码 略 

device |= device2; 

if (device) break;// 经 过 上 面 步骤 后 ， 找 到 合适 的 device， 可 以 直接 跳出 

device = mDefaulLltoutputDevice;// 和 否则 使 用 默认 的 device 

if (device == AUDIO_DEVICE_NONE) {// 仍 然 没 有 匹配 的 device， 这 种 1 
ALOGE("getDeviceForStrategy() no device found for STRAT 











} 
} break; 


上 述 代码 段 看 上 去 很 长 ， 但 逻辑 其 实 很 简单 ， 即 按照 一 定 的 优先 级 
来 匹配 系统 中 已 经 存在 的 所 有 音频 设备 。 这 个 优先 级 的 设 定 因 Strategy 
不 同 而 有 所 差异 。 对 于 STRATEGY_MEDIA 这 种 类 型 ， 其 优先 级 如 下 所 示 
(要 注意 ， 只 有 在 上 一 步 匹配 失败 后 一 一 即 找 不 到 合适 的 设备 ， 变 量 
devi ce2 为 AUD10_DEVICE_NONE 的 情况 下 ， 程 序 才 会 继续 执行 下 一 优先 级 
的 判断 ) : 


° 如 果 平 台 有 蓝牙 A2dp， 并 且 蓝 牙 A2dp 通 道 可 以 正常 打开 ， 没 
挂 起 ， 当 前 也 没有 强制 不 使 用 A2dp， 那 么 通过 匹配 
mAvai lable0utputDevices 来 寻找 合适 的 A2dp 设 备 ， 如 
A2dp_headphone, A2dp Speaker。 


e 处 于 第 二 优先 等 级 的 是 wi red headphone. 


° 继续 寻找 是 否 有 wired headset. 
e 寻找 是 否 有 usb accessory. 
° 寻找 是 否 有 usb device. 


按照 上 述 的 优先 级 匹配 策略 ， 正 常情 况 下 getDeviceForStrategy 都 
能 获得 符合 要 求 的 devi ce。 我 们 再 回 到 前 面 的 get0utput， 看 看 Step2 的 
执行 。 


Step2@AudioPol icyManagerBase: :get0utput。 为 Device 选 择 合 适 
的 Output 通 道 : 


SortedVector<audio_io_ handle_t> AudioPolicyManagerBase: :getOutput 
devices_t device, DefaultKeyedVector<audio_io_handle_t, AudioOutpu 
{ 
SortedVector<audio_io_handle_t> outputs; 
for (size_t i = 0; i < openOutputs.size(); i++) 4.. 
if ((device & openOutputs.valueAt(i)->supportedDevices() ) 
ALOGVV("getOutputsForDevice() found output %d", opend 
outputs.add(openOutputs.keyAt(i)); 
} 


return outputs; 


这 个 函数 用 于 获得 所 有 支持 devi ce 设备 的 output， 并 添加 到 
outputs 中 。0utput 是 前 几 个 小 节 中 分 析 的 AudioFlinger: :openOutput 
的 执行 结果 ，AudioPol icyServi ce 会 把 它们 存储 到 mo0utputs 键 值 对 中 。 
因为 每 个 output 通 常 都 支持 若干 种 音频 设备 ， 且 不 同 的 output 支 持 的 音 
频 设 备 类 型 不 限 ， 所 以 系统 中 很 可 能 存在 多 个 支持 同一 devi ce 的 
output. 


Step 3@AudioPol icyManagerBase::getOutput. FJARA, FS 
要 求 的 0utput 可 能 不 止 一 个 ， 所 以 要 选择 一 个 最 合适 的 〈 分 段 阅 读 ) : 


audio_io_handle_t AudioPolicyManagerBase::selectOutput(const Sort 














/*Step 1， 处 理 一 些 特殊 情况 :*/ 
if (outputs.size() == 0) { 
return 0; 








if (outputs.size() == 1) { 
return outputs[0]; 
} 


先 处 理 一 些 特殊 情况 ， 如 没有 任何 output 存 在 的 情况 下 只 能 返回 空 
值 ， 同 样 的 ， 如 果 只 有 一 个 output 的 情况 也 没 得 选择 ， 直 接 返 回 该 
output: 


/*Step 2. 开始 择优 判断 */ 
int maxCommonFlags = 0; 
audio_io_handle_t outputFlags 


= 0; 
audio_io_handle_t outputPrimary = 


0; 











for (size_t i = 0; i < outputs.size(); i++) {// 逐 个 处 理 所 有 Outp 
AudioOutputDescriptor *outputDesc = mOutputs.valueFor (out 
// 每 个 Output 都 有 对 应 的 描述 符 
if (!outputDesc->isDuplicated()) { 
int commonFlags = (int)AudioSystem: :popCount (outputDes 
if (commonFlags > maxCommonFlags) {// 此 Output 的 fLags 与 
outputFlags = outputs[i]; 
maxCommonFlags = commonFlags; 
ALOGV("sSelectOutput() commonFlags for output %d, % 




















if (outputDesc->mProfile->mFlags & AUDIO _OUTPUT_FLAG_ 
outputPrimary = outputs[i]; 
} 


} 


上 述 代 码 段 中 的 for 循 环 是 整个 函数 的 核心 ， 我 们 来 分 析 下 它 
的 “决策 准绳 ”。 读 者 只 要 仔细 看 下 for 循 环 中 的 判断 语句 ， 就 可 以 发 
现 它 实际 上 是 在 计算 一 个 最 大 值 maxCommonFlags。 所 以 问题 就 转化 为 : 
maxCommonF lags 是 什么 ? 


int commonFlags = (int)AudioSystem: :popCount(outputDesc->mProfile 


上 面 这 名 代码 用 通俗 的 话 来 讲 ， 就 是 计算 outputDesc->mProfile- 
>mFlags 与 入 人 参 flags 的 “相似 度 ” 有 多 大 。Flags 有 如 下 几 种 可 供 选 


i: 


AUDIO_OUTPUT_FLAG_NONE = 0x0, 
AUDIO_OUTPUT_FLAG_DIRECT = 0x1，//0utput 直 接 把 track 导 向 一 个 output si 
AUDIO_OUTPUT_FLAG_PRIMARY = 0x2,//Primary Output， 系 统 中 只 存在 唯一 的 | 
AUDIO_OUTPUT_FLAG_FAST = 0x4, //3c# fast tracks 的 output 
AUDIO_OUTPUT_FLAG_DEEP_BUFFER = 0Xx8，// 使 用 deep audio buffer 的 outpl 


音频 系统 中 名 为 output_flags 的 数据 类 型 非常 多 ， 不 过 仔细 回 漳 ， 
还 是 不 难 发 现 这 个 flags 是 在 AudioTrack 的 set 函 数 中 指定 的 。 另 外 ， 如 
果 在 查找 过 程 中 发 现 了 一 个 primary output， 程 序 会 用 outputPr imary 
变量 来 表示 ， 这 在 后 面 会 用 到 : 


/*Step 3. 根据 优先 级 做 出 最 后 的 选择 */ 
if (outputFlags != 0) { 
return outputFlags; 





if (outputPrimary != 0) { 
return outputPrimary; 
} 


return outputs[0]; 
+//AudioPolicyManagerBase: :selectOutput 44 


Ey AY RESIST MR ZR AY “FREE” o RERE, 
Bp: 


° Flags 与 要 求 相似 度 最 高 的 0utput; 

e Primary Output; 

° 如 果 上 面 两 种 都 找 不 到 ， 则 默认 返回 第 一 个 Output 。 
这 样 AudioPol icyServi ce 就 完成 了 整个 路 由 路 径 的 选择 ， 


AudioTrack 则 是 通过 AudioSystem: : get0utput 则 接 调用 到 
AudioPol icyService 提 供 的 功能 。 


13.6 音频 数据 流 


通过 前 面 几 个 小 节 的 学 习 ， 读 者 已 经 系统 掌握 了 AudioTrack， 
AudioFlinger 和 AudioPolicy Service 的 内 部 实现 。 只 不 过 还 有 一 点 欠 
缺 ， 即 我 们 始终 没有 详细 分 析 在 这 几 个 跨 进 程 的 对 象 间 ， 音 频数 据 是 如 
何 传递 的 因为 如 果 一 开始 就 讲解 这 其 中 的 细节 ， 很 可 能 会 让 读者 感 
沉 很 吃力 ， 从 而 事倍功半 。 所 以 我 们 选择 在 读者 理解 了 各 个 模块 的 运作 
方式 后 ， 再 来 对 整个 数据 流 的 传递 过 程 做 统一 分 析 。 


首先 来 思考 下 在 音频 数据 的 传递 过 程 中 ， 会 有 了 哪些 地 方 可 能 涉及 内 
存 申请 一 一 这 对 于 肉 入 式 系 统 来 说 非常 关键 ， 因 而 是 我 们 设计 的 重 
Ùo “可 疑 ” 的 地 方 至 少 有 : MediaPlayerService、AudioTrack、 
AudioFlinger、AudioPolicyService、AudioMixer 以 及 HAL 层 的 相关 
类 。 其 中 MediaPlayerService 不 在 这 个 小 节 的 讨论 范围 内 ， 所 以 直接 略 
过 ; 而 AudioPolicyService 直 接 参 与 数据 传递 的 可 能 性 不 大 ， 也 基本 可 
以 排除 ; 剩 下 的 就 是 如 图 13-23 所 示 的 几 个 对 象 。 





MediaPlayerService 


Audio Track AudioTrack AudioTrack 


AudioF linger 






HAL | 


A 13-23 Audio Playback 数 据 流 简 图 


按照 音频 的 正常 回放 过 程 ， 该 数据 流 简 图 主要 包括 如 下 几 个 核心 


在 这 个 简 图 中 ， 假 设 我 们 需要 同时 播放 3 个 音频 文件 〈 它 们 可 以 是 
mp3，wav 或 者 系统 支持 的 其 他 任何 音频 格式 ) 

上 层 应 用 程序 通过 SDK 提 供 的 MediaPlayer 来 播放 这 几 个 音频 文件 ， 
默认 情况 下 它们 的 “音频 流 ” 类 型 都 是 STREAM_MUSIC。 因 为 文 
件 是 保存 在 存储 设备 中 的 (比如 flash、sd 卡 、U 检 等 ) ， 所 以 
MediaPlayer 面 临 的 第 一 个 问题 是 如 何 把 音频 文件 读 取 到 内 存 中 一 一 
这 涉及 了 文件 系统 的 读 写 原理 ， 因 为 不 是 本 章 关 注 的 重点 ， 所 以 不 
FR « 

当 音 频 文 件 读 取出 来 后 ， 是 不 是 直接 可 以 播放 了 ? 显然 不 是 ， 因 为 
大 多 数 音 频 文 件 在 保存 时 都 是 先 经 过 压缩 处 理 的 ， 所 以 此 时 就 需要 
有 对 应 的 解码 操作 (可 以 采用 “软件 解码 ”， 也 可 以 采用 “硬件 解 
A”) 

音频 数据 解码 后 的 处 理 才 是 我 们 想 要 了 解 的 。MediaPlayet 在 
MediaPlayerService 的 帮助 下 将 完成 包括 解码 在 内 的 复杂 操作 ; 而 
MediaPlayerService 实 际 上 又 是 AudioTrack 的 使 用 者 ， 即 它 的 回放 功能 
是 由 AudioTrack 间 接 完成 的 。 

一 个 AudioTrack 只 代表 一 个 播放 实例 ， 而 这 个 场景 中 却 要 求 同 时 播 
放 3 个 音频 文件 。 这 在 智能 操作 系统 里 很 常见 ， 如 播放 音乐 时 接 到 
短信 提醒 ;或 者 同时 打开 3 个 MediaPlayer (系统 支持 同时 运行 多 个 
MediaPlayert# i a) 等 ， 都 需要 系统 能 做 出 正确 处 理 。 既 然 我 们 可 
以 同时 运行 多 个 AudioTrack 实 例 ， 同 时 系统 中 也 会 有 多 个 音频 回放 
设备 ， 那 么 AudioTrack 和 这 些 设 备 有 什么 对 应 关系 呢 ? 这 就 是 
AudioPolicySetrvice 所 起 到 的 作用 。 它 根据 每 个 AudioTrack 所 属 的 “ 流 
类 型 ”来 为 它 选 择 与 当前 系统 最 匹配 的 输出 设备 ， 然 后 查找 支持 此 
输出 设备 的 AudioFlinger 中 的 Output( 即 openOutput 所 打开 的 通 

道 ) 。 这 有 点 类 似 于 路 由 器 的 功能 : 在 设 定 了 源 IP (AudioTrack) 
和 目标 IP (音频 回放 设备 ) 后 ， 寻 找 最 佳 的 路 由 路 径 ， 因 而 
AudioPolicySetrvice 的 这 一 特性 被 称 为 “Routing Strateey”。 这 些 知识 
点 在 AudioPolicyService 小 节 已 经 详细 介绍 过 ， 读 者 若 不 清楚 可 以 回 
头 复习 下 。 

AudioFlinger 则 是 路 由 器 的 “底层 通道 ”， 它 坚决 执行 
AudioPolicyService 的 决策 ， 正 确 地 将 各 路 音频 数据 进行 混 音 ， 然 后 
传递 到 HAL 层 ， 进 而 输出 到 最 终 的 音频 设备 中 。 这 个 过 程 有 点 类 亿 














































































































于 显示 系统 中 的 SurfaceFlinget。 

。 在 AudioFlinget 中 起 到 关键 作用 (音频 回放 ) 的 有 两 个 :一 个 是 
PlaybackThread， 为 一 个 是 AudioMixetr， 后 者 是 混 音 的 核心 。 读 者 可 
以 先 来 思考 一 下 : 它们 两 者 是 否 共享 同一 块 音 频数 据 缓冲 区 呢 ? 


通过 上 面 的 描述 ， 我 们 可 以 归纳 出 音频 流 的 几 个 关键 “路 由 节 
点 ”， 即 AudioTrack，AudioFlinger 中 的 PlaybackThread，AudioMixer 
和 HAL 层 的 实现 〈 这 些 节点 在 图 中 都 用 数字 序号 分 别 标注 ) 。 


13. 6. 1 AudioTrack 中 的 音频 流 


AudioTrack 中 对 音频 数据 流 的 处 理 相 对 简单 ， 我 们 仍然 以 前 面 小 节 
的 “AudioTrack 应 用 范例 ”进行 分 析 。AudioTrack 为 音频 数据 分 配 缓冲 
区 空间 对 应 的 代码 如 下 : 


AudioTrack track = new AudioTrack(TEST_STREAM_TYPE, TEST_SR, TEST 
TEST_FORMAT, 2 * minBuf 

byte data[] = new byte[minBuffSize]; 

track.write(data, OFFSET_DEFAULT, data.length); 

track.write(data, OFFSET_DEFAULT, data.length); 

track.play(); 


这 个 范例 中 的 音频 数据 〈 即 data 数 组 ) 是 静态 的 ， 而 不 是 从 某 个 音 
频 文 件 中 解析 出 来 的 。 而 随后 的 write 函数 则 负责 将 data 数 据 写 入 
AudioTrack 中 ， 这 说 明 AudioTrack 内 部 也 一 定 申 请 了 内 存 空 间 来 存储 音 
频数 据 。 具 体 流 程 如 下 : 


(1) AudioTrack (java) 构造 时 ， 传 入 bufferSizelnBytes: 





public AudioTrack(int streamType, int sampleRateInHz, int channel 
int bufferSizeInBytes, int mode, int sessionId) 


在 上 面 的 范例 中 ，bufferSizelnBytes 对 应 的 是 2 * 
minBuffSize. 


(2) AudioTrack (java) 的 构造 负数 调用 native_setup， 将 上 述 
bufferSizelnBytes 值 传 入 JNI 层 ， 即 
android_media AudioTrack_ native _setup@android media_AudioTrack. 


接着 AudioTrack (cpp) 对 和 象 会 被 创建 ， 且 它 的 构造 函数 不 市 任何 参数 : 


sp<AudioTrack> lpTrack = new AudioTrack(); 


在 静态 模式 (MODE_STATIC) F, Rii É set ARUSAAMA 
AudioTrack (cpp): 


lpTrack->set(..lpJniStorage->mMemBase,...); 


变量 |pJniStorage 是 AudioTrackJniStorage 类 型 的 对 象 ， 它 会 事先 
分 配 一 定 的 内 存 空 间 。 具 体 代 码 如 下 : 


lpJniStorage->allocSharedMem(buffSizeInBytes) 


流 模式 下 (MODE_STREAM) 的 音频 数据 是 分 多 次 传递 的 ， 这 种 情况 
下 AudioTrack 不 需要 主动 使 用 AudioTrackJniStorage 来 申请 内 存 空 间 ， 
而 是 后 期 由 AudioF linger 根 据 需求 分 配 一 块 缓冲 区 。 缓 冲 区 头 部 为 
audio track_cblk t， 以 mCblk 表 示 ， 这 个 变量 在 AudioTrack:: 
createTrack_| 中 初始 化 。 源 代码 如 下 : 


sp<IAudioTrack> track = audioFlinger->createTrack(...frameCount,...); 
sp<IMemory> iMem = track->getCblk();// 向 AudioFlinger 申 请 数据 缓冲 空间 


mAudioTrack = track;// 与 AudioFlinger 的 通信 中 介 

mCblkMemory iMem; 

audio_track_cblk_t* cblk = static_cast<audio_track_cblk_t*>(iMem- 
mCblk = cblk; 





Ef rameCountS We 4 buf fSizelnBytes, channel Hak 
bytesPerSample 计 算出 来 的 ， 前 几 个 小 节 已 经 讲解 过 。 通 过 
createTrack， 我 们 建立 起 本 地 AudioTrack 与 远程 AudioFlinger 间 的 联 
系 〈laudioTrack) ， 然 后 利用 1AudioTrack 来 向 AudioF I inger AKRA 
内 存 空间 (getCblk) 。 可 想 而 知 ， 这 块 空间 必然 是 要 能 跨 进程 共享 的 

(因为 它 是 后 续 “ 生 产 者 和 消费 者 ”共同 操作 的 区 域 》。 我 们 来 看 看 它 
的 Server 端 实现 : 


/*frameworks/av/services/audioflinger/Tracks.cpp*/ 

sp<IMemory> AudioFlinger::TrackHandle::getCblk() const { 
return mTrack->getCblk(); 

J 


IAudioTrack 在 AudioFlinger 中 的 实现 是 TrackHandle。 而 mTrack 是 
一 个 PlaybackThread: :Track， 它 是 在 AudioFlinger::createTrack 时 生 


成 的 。 具 体 代 码 如 下 : 
PlaybackThread *thread = checkPlaybackThread_1l(output); 


// 下 面 这 个 track 就 是 上 面 的 mTrack 
track = thread->createTrack_l(client, streamType, sampleRate, for 
channelMask, frameCount, sharedBuffer, lSessionId, flags, tid, &l 


所 以 mTrack 是 隶属 于 某 个 特定 PlaybackThread 实 例 的 〈 每 个 
AudioTrack 在 AudioFlinger 中 都 有 一 个 对 应 的 PlaybackThread， 这 与 它 
的 “ 流 类 型 ”以 及 当前 设备 的 AudioPolicyService 策 略 有 关 ) 。 我 们 来 
看 看 PlaybackThread: :Track 中 如 何 生 成 一 块 内 存 区 域 ， 如 图 13-24 所 
示 。 










-Sp<IMemory> mCblkMemory 
+getCblk() 
人 


PlaybackThread::Track 





全 图 13-24 Track 中 的 数据 块 


Track 继 承 自 TrackBase， 后 者 的 构造 涵 数 中 将 申请 所 需 的 内 存单 
元 。 代 码 如 下 : 


AudioFlinger::ThreadBase: :TrackBase::TrackBasel(..const sp<Client>& 


oe 
size_t size = sizeof(audio_track_cblk_t); 
size_t bufferSize = frameCount* mFrameSize; 
if (sharedBuffer == 0) { 
size += bufferSize; 


} 
if (client != NULL) { 
mCblkMemory = client->heap()->allocate(size); 


首先 计算 缓冲 区 的 大 小 ，frameCount 是 哪里 得 到 的 呢 ? 它 是 
AudioTrack 在 native_setup 时 计算 出 来 ， 并 传递 给 AudioFlinger 的 。 公 
式 如 下 : 


int bytesPerSample = audioFormat == javaAudioTrackFields.PCM16 ? 
int frameCount = buffSizeInBytes / (nbChannels * bytesPerSample) ; 
也 就 是 : 


bufferSize=frameCount *channelCount*sizeof(int1i6_t) 
=(buffSizeInBytes / (nbChannels * bytesPerSample))* channelCount* 
=buffSizeInBytes 


变量 buffSi zelnBytes 是 在 创建 AudioTrack (java) 对 象 时 提供 的 。 
如 果 是 STATIC 模式 ， 要 求 这 个 值 是 回放 的 音频 数据 大 小 的 最 大 值 ; 如果 
是 STREAM 模 式 ， 可 以 小 于 声音 数据 的 实际 大 小 ， 不 过 通常 需要 比 
getMinBufferSize 大 ， 否 则 会 初始 化 失败 。 在 前 面 AudioTrack 的 范例 
mH, buffSizelnBytes#getMinBufferSize*2. 


需要 申请 的 内 存 大 小 为 size， 它 是 audio track chlk _t 头 部 大 小 再 
加 上 bufferSize (MODE STREAMAY) 得 到 的 ， 为 什么 需要 一 个 
audio track_cblk tHe? 


举 个 例子 ，TCP/ZIP 中 的 通信 双方 在 发 送 实际 的 数据 内 容 前 需要 加 上 


一 个 数据 头 ， 用 以 描述 数据 块 的 各 种 属性 。 也 就 是 : 
<data> = <head>+<body> 


与 此 类 似 ，audio track cbhlk_t#<head>, fbufferSi zell Zz 
<body> 的 大 小 。 在 TrackBase 中 ，mCcblkMemory 指 向 的 是 整 块 数据 区 ， 
mCb |k 则 指向 的 是 数据 区 的 audio_track_cblk_t 头 。 当 然 从 指针 的 角度 
来 看 ， 二 者 的 值 是 一 致 的 一 一 这 点 希望 读者 在 分 析 代 码 时 特别 注意 。 数 
据 区 的 空间 申请 主要 采用 的 是 : 


mCblkMemory = client->heap()->allocate(size); 


上 面 这 名 代码 表明 变量 mcb1kMemory 指 向 的 内 存 地 址 由 cl ient 来 指 
定 ， 那 么 这 个 client 又 是 怎么 来 的 呢 ? 它 是 在 
AudioFlinger::createTrack 中 生成 的 ， 并 由 AudioFlinger: :mClients 
来 维护 。 换 句 话 说， 虽然 每 个 PlaybackThread 有 使 用 内 存 空 间 的 权利 ， 
但 是 真正 的 内 存 申 请 与 回收 则 仍 是 由 AudioF linger 来 全 盘 掌控 的 : 


sp<IAudioTrack> AudioFlinger: :createTrack(...) 


fos 


sp<Client> client; 


client = registerPid_1l(pid); 


国 数 registerPid_ 1 除了 为 当前 的 pid 〈 这 个 pid 值 是 AudioTrack 调 
用 AudioFlinger::createTrack 时 传 入 的 ， 代 表 了 AudioTrack 所 在 进程 
的 1D) 生成 一 个 AudioF linger: :client 实例 外 ， 还 将 pid tt， 
wp<Client> 键 值 对 添加 到 mclients 中 。 这 也 从 一 个 侧面 说 明 ， 每 一 个 
AudioTrack 在 AudioFlinger 中 有 且 仅 有 一 个 Client 实 体 。 那 么 ，Client 
又 是 如 何 管理 内 存 的 呢 ? 
先 来 看 看 它 的 构造 函数 : 
AudioFlinger::Client::Client(const sp<AudioFlinger>& audioFlinger 
RefBase(),mAudioFlinger(audioFlinger), 
mMemoryDealer(new MemoryDealer(1024*1024, "AudioFlinger:: 
mPid(pid), mTimedTrackCount (0) 


// 1 MB of address space is good for 32 tracks, 8 buffers eac 


从 上 述 源 码 段 的 注释 可 以 略 知 一 二 : Client 默 认 情 况 下 申请 了 
1024#1024=1MB 大 小 的 内 存 空 间 一 一 这 对 于 32 路 Track， 每 路 8 个 
buffer， 每 个 buffer 占 4KB 的 情况 已 经 足够 (32*8*4KB=1MB) 。 


由 于 每 路 Track 所 需 的 空间 大 小 不 同 ， 所 以 它们 建立 时 需要 由 
mCb1kMemory 向 Client 进 行 “ 实 报 实 销 ”， 如 : 


mCblkMemory = client->heap()->allocate(size); 


实际 上 client 也 不 是 最 终 的 内 存 管 理 者 ， 其 内 部 还 集成 了 
MemoryDealer 。MemoryDealer 内 部 分 为 两 部 分 ， 即 : 


e H (heap) 内 存 块 MemoryHeapBase; 
o 分 配 和 回收 策略 mAllocator。 


我 们 在 后 面 分 析 数 据 的 跨 进程 传递 时 再 做 详细 讲解 。 


到 目前 为 止 ，AudioTrack 和 AudioFlinger 中 与 音频 数据 相关 的 内 存 
空间 已 经 比较 明了 ， 我 们 来 做 个 小 结 〈 在 MODE_STREAM 的 情况 下 ) 。 


° AudioTrack (java) 在 构造 时 ， 通 过 本 地 方法 native_setup 来 传 
递 上 层 应 用 计算 出 所 需 的 最 小 音频 数据 空间 。 


e native_setup 负 责 生 成 AudioTrack (cpp) 对 象 ， 此 时 还 不 涉及 
内 存 申 请 。 随 后 它 调用 AudioTrack: : set 接口 ， 并 将 上 层 应 用 计算 
出 的 数据 空间 大 小 转化 为 frameCount。 


在 set 实 现 中 ， 首 先 要 找到 匹配 的 AudioFlinger 中 的 
PlaybackThread， 接 着 调用 AudioFlinger:: createTrack 在 
PlaybackThread 中 新 增 一 个 Track， 同 时 建立 AudioTrack 与 
AudioFlinger 则 的 通信 接口 IAudioTrack。 此 时 在 AudioF|inger 内 
部 的 Track 生 成 过 程 中 ， 会 由 TrackBase 来 申请 相应 的 内 存 空间 一 一 
不 过 AudioTrack 显 然 还 不 知道 这 一 数据 空间 的 存在 。 


接 下 来 AudioTrack 可 以 通过 1AudioTrack: :getCblk 来 获得 这 个 
数据 空间 。 


。 之 后 双方 就 能 够 利用 这 个 数据 缓冲 区 空间 来 传递 音频 数据 了 : 


在 AudioTrack 中 ， 它 是 由 AudioTrack: :mCblkMemory 来 指示 的 ; 在 
AudioFlinger 中 ， 它 是 由 TrackBase: :mCb1kMemory 来 指示 的 。 


下 一 小 节 我 们 详细 讲解 两 个 跨 进程 的 对 象 (AudioTrack 和 
AudioFlinger) 间 是 如 何 共享 音频 数据 空间 的 。 


13.6.2 ”AudioTrack 和 AudioFlinger 间 的 数据 交互 
AudioTrack 与 AudioFlinger 是 如 何 完成 跨 进程 的 数据 传递 的 呢 ? 
回答 这 个 问题 ， 可 以 从 AudioTrack. write 入 手 。 


为 了 简化 分 析 过 程 ， 我 们 直接 来 看 native 层 的 AudioTrack. write, 
而 Java 层 的 实现 相对 简单 ， 不 再 一 一 讲解 : 


/*frameworks/av/media/libmedia/AudioTrack.cpp*/ 
ssize_t AudioTrack::write(const void* buffer, size_t userSize) 


if (mSharedBuffer != © || mIsTimed) { 
return INVALID_OPERATION; i 
}//STATIC 模 式 下 ， 数 据 是 一 次 就 写 完 的 ,不 需要 调用 write 


//Step 1 工 ,准备 与 数据 空间 有 关 的 参数 

mLock.lock(); 

sp<IAudioTrack> audioTrack =mAudioTrack; //mAudioTrackz ħi iAud 
sp<IMemory> iMem = mCblkMemory;//mCb1kMemor yc di ff] IAudioTrack: 
mLock.unlock(); 











//Step 2, 写 入 数据 
ssize_t written = 
const int8_t *src 
Buffer audioBuffer; 
size_t frameSz = frameSize(); 
do { 
audioBuffer.frameCount = userSize/frameSz; 
status_t err = obtainBuffer(&audioBuffer, -1); 


0; 
= (const int8_t *)buffer; 


size_t towrite; 
if (mFormat == AUDIO_FORMAT_PCM_8_ BIT &&!(mFlags & AUDIO_ 


} else { 
towrite = audioBuffer.size; 
memcpy(audioBuffer.i8, src, toWrite); // 内 存 复 第 





C= 


src += towrite; // 指 针 跳 过 已 经 写 入 的 数据 

userSize -= toWrite; // 剩 余数 据 量 

written += towrite; // 已 经 写 入 的 数据 量 

releaseBuffer(&audioBuffer ) ; // 释 放 audioBuffer 
} while (userSize >= frameSz); // 循 环 写 入 数据 
return written; 


函数 write 分 为 两 个 步骤 。 


Step16AudioTrack: :write。 人 得 到 AudioTrack 与 AudioFlinger 间 的 
1PC 通 道 1AudioTrack， 以 及 数据 缓冲 区 头 指 针 mCb1kMemory， 后 者 是 通 
过 前 者 的 getCblk 接 口 获 取 的 。 而 如 果 读 者 仔细 观察 ， 会 发 现 这 个 函数 
中 并 没有 直接 用 到 这 两 个 变量 ， 那 么 为 什么 要 获取 它们 呢 ? 原因 在 于 利 
用 强 指 针 的 特性 来 保证 它们 不 会 被 释放 。 


Step2@AudioTrack: :write。 读 者 可 以 思考 一 下 : 程序 在 处 理 数 据 
复制 时 的 正常 流程 是 怎样 的 呢 ? 如 果 以 src、dst、cur 分 别 代 表 源 数 
据 、 目 的 数据 区 和 当前 要 处 理 的 数据 起 点 ， 那 么 无 非 就 是 借助 于 cur， 
通过 多 次 循环 将 src 中 的 数据 复制 到 dst 缓 冲 区 中 。 在 write 这 个 例子 中 
的 处 理 方 法 也 类 似 ， 只 不 过 目的 区 用 audioBuffer 进 行 了 封装 。 

接 下 来 我 们 详细 分 析 AudioTrack 和 AudioFlinger 是 如 何 通 过 
mCb1lkMemory 这 块 内 存 区 来 实现 “生产 者 -消费 者 ”数据 交互 的 。 需 要 考 
虑 的 问题 包括 : 


° AudioTrack 是 生产 者 ，AudioF linger 是 消费 者 ， 它 们 如 何 跨 进 
程 地 共享 一 个 缓冲 区 ; 


° mCblkMemory 是 不 是 环形 数据 区 ， 如 果 是 又 是 如 何 实现 的 ; 
“生产 者 -消费 者 ”模型 在 这 个 场景 中 的 具体 应 用 。 


(1) 先 用 一 个 简 图 来 描绘 下 mCb1kMemory 的 内 部 结构 ， 如 图 13-25 
所 示 。 


mCblkMemory 


audio track cblk t 





mCblk 





A 413-25 IMemory 内 部 结构 图 


内 存 块 头 部 audio_track_cblk_t 中 有 几 个 重要 变量 的 释义 ， 如 表 
13-6 所 示 。 


+: 6 audio track chlk t 重 要 内 部 变量 释义 


a 


消费 者 指针 





要 特别 注意 ，user 是 生产 者 而 server 是 消费 者 ， 这 和 我 们 最 初 的 理 
解 可 能 有 点 差异 o 


(2) 生产 者 如 何 判断 是 否 有 可 用 的 缓冲 区 来 填充 数据 呢 ? 这 就 是 
framesAvailable@ audio track cblk t 所 要 完成 的 工作 : 


/*frameworks/av/media/libmedia/AudioTrackShared.cpp*/ 





uint32_t audio_track_cblk_t::framesAvailable(size_t frameCount, b 


{ 





Mutex::Autolock _1(lock); 
return framesAvailable_1(frameCount, isOut); 


uint32_t audio_track_cblk_t::framesAvailable_1(size_t frameCount, 


{ 





uint32_t u 
uint32_ t s 


user; 
server; 


if (isOut) { 
uint32_t limit = (s < loopStart) ? s : loopStart; 
return limit + frameCount - u; 

} else { 
return frameCount + u - sS; 

} 


上 面 代码 段 中 的 变量 is0ut 用 于 表示 当前 是 回放 音频 还 是 录制 音 


也 就 是 说 ， 如 果 在 is0ut 为 true (Playback) 的 情况 下 ， 
framesAvailable 1 的 标准 就 是 | imit+frameCount-u。 通 常 1imit 就 是 s 
自身 ， 因 而 是 st+frameCount-u。 用 通俗 的 话 来 解释 就 是 : 


剩余 可 用 空间 (framesAvailable) =“ 总 共有 多 少 空 
间 ” (frameCount) -“ 用 掉 了 多 少 ” (u) + “回收 了 多 少 ” (s) 。 


消费 者 这 边 判断 当前 是 否 有 可 读数 据 ， 则 由 framesReady 来 完成 。 
其 实现 和 framesAvai lable 类 似 ， 读 者 可 以 自行 分 析 。 


(3) 在 前 面 的 AudioTrack: :write 中 ， 我 们 通过 obtainBuffer 获 取 
了 目标 区 的 写 入 地 址 ， 下 面 来 看 看 它 是 如 何 实现 的 : 


status_t AudioTrack: :obtainBuffer(Buffer* audioBuffer, int32_t wa 


{.. 
uint32_t framesReq = audioBuffer->frameCount;//Step 1. 用 户 申请 [ 


uint32_t framesAvail = mProxy ->framesAvailable(); //Step 2.¥ 
.…// 当 可 用 空间 大 小 为 9 时 的 一 些 处 理 
if (framesReq > framesAvail) { 

framesReq = framesAvail; //Step 3. 请 求 的 大 小 超过 可 用 大 小 














uint32_t u = cblk->user; 


uint32_t bufferEnd = cblk->userBase + mFrameCount; 
if (framesReq > bufferEnd - u) { 

framesReq = bufferEnd - u; //Step 4., 确 定 用 户 可 以 申请 到 的 空间 大 
} 


audioBuffer->raw = mProxy ->buffer(u); //Step 5. 确 定 可 供用 户 使 用 
active = mActive; 
return active ? status_t(NO_ERROR) : status_t(STOPPED); 

















Step1@AudioTrack: :obtainBuffer。 变 量 framesRedq 的 初始 值 是 
audioBuffer->frameCount， 即 用 户 请 求 的 空间 大 小 。 用 户 申请 的 这 个 
大 小 并 不 一 定 能 得 到 满足 ， 后 面 会 根据 实际 情况 对 其 进行 适当 修正 。 


Step2@AudioTrack: :obtainBuffer。 辆 数 framesAvai lable 用 于 计 
算 当 前 可 供 生 产 者 使 用 的 空间 大 小 ， 前 面 已 经 讲解 过 ， 此 处 不 再 瑜 述 。 


Step3@AudioTrack: :obtainBuffer。 如 果 当 前 剩余 的 可 用 空间 已 经 
小 于 用 户 的 请 求 大 小 ， 那 么 只 能 满足 用 户 的 一 部 分 需求 。 

Step4@AudioTrack: :obtainBuffer。 判 断 剩 余 空 间 是 否 涉 及 环形 的 
情况 ， 我 们 会 结合 下 一 步 来 进行 完整 分 析 。 

Step5@AudioTrack: :obtainBuffer。 得 出 可 用 空间 的 大 小 并 不 算 完 
成 所 有 工作 ， 我 们 还 必须 计算 目标 区 的 起 始 地 址 ， 所 以 调用 buffer () K 
数 。 这 个 函数 实现 相当 简单 ， 只 有 短 短 一 句 话 ， 但 起 到 了 很 关键 的 作用 

(Proxy 直 接 又 调用 了 audio track_cblk t 中 的 实现 ) : 


void* audio_track_cblk_t::buffer(void *buffers, size_t frameSize, 


t 
I 


return (int8_t *)buffers + (offset - userBase) * frameSize; 


其 中 buffers 指 向 的 是 数据 区 的 起 点 ，offset 是 user (44) 指 
针 。 因 为 这 些 变量 都 以 frame 为 单位 ， 所 以 还 要 换算 成 字 节 单 位 ， 即 乘 
以 frameSize。 


我 们 知道 ，user 是 生产 者 的 当前 指针 ， 那 么 userBase 又 是 什么 呢 ? 


如 果 不 考 虑 环形 缓冲 区 ， 事 情 确 实 会 简单 很 多 。 但 不 幸 的 是 ， 我 们 
必须 实现 环形 的 数据 读 写 方 法 。 通 过 搜索 源码 ， 可 以 发 现 userBase 在 


audio track_cblk_t::stepUser 中 会 被 不 断 赋 值 ， 所 以 我 们 一 并 分 析 这 
个 函数 。 


当 得 到 目标 区 的 可 用 大 小 以 及 起 始 地 址 后 ， 生 产 者 就 开始 执行 任 
务 ， 并 把 数据 写 入 缓冲 区 中 。 在 这 之 后 ， 它 还 有 一 件 事 要 做 ， 即 通过 
stepUser 来 调整 缓冲 区 的 状态 〈 在 releaseBuffer 中 调用 ) 。 或 者 更 确 
切 地 说 ， 更 新 user 〈 生 产 者 ) 在 缓冲 区 中 的 状态 : 


/*frameworks/av/media/libmedia/AudioTrackShared.cpp*/ 
uint32_t audio_track_cblk_t::stepUser(size_t stepCount, size_t fr 


ion 





uint32_t u = user; 

u += stepCount;// 跳 过 已 经 处 理 的 数据 

if (isOut) 4... 

} else if (u > server) {// 在 Record 的 情况 下 ，user 不 应 该 超过 server 
ALOGW( "stepUser occurred after track reset"); 
U = server; 








J 


if (u >= frameCount) { 
if (u - frameCount >= userBase ) { 
userBase += frameCount; 


} else if (u >= userBase + frameCount) { 
userBase += frameCount; 


} 
user = u; 
return u; 


ek FF SFE (user) 向 前 推进 了 stepCount， 即 刚刚 写 入 缓冲 区 的 
数据 大 小 ， 此 时 user 有 可 能 已 经 到 达 整 个 缓冲 区 的 末尾 。 但 如 果 server 
也 已 经 读 取 了 一 部 分 数据 ， 那 么 理论 上 来 讲 数据 区 的 开头 一 部 分 又 是 可 
供 生产 者 使 用 的 区 域 ， 这 就 是 环形 缓冲 区 的 一 个 特点 。 那 么 ， 如 何 判 断 
出 这 种 情况 呢 ? 


结合 前 面 buffer () 函数 中 的 offset-userBase， 读 者 可 以 想象 一 下 
一 一 如 果 userBase 的 值 已 经 是 整个 数据 区 大 小 ， 那 么 当 offset 达 到 末尾 
时 ，offset-userBase 实 际 上 也 就 是 缓冲 区 的 开头 。 所 以 上 述 消 数 首 先 
根据 if (u >= frameCount) ， 即 user 是 否 已 经 超过 frameCount， 来 判断 
userBase 是 否 需 要 更 新 。 很 显然 ， 如 果 user 又 绕 了 环 一 圈 〈 即 u - 


frameCount>= userBase) ， 那 么 userBase 就 得 再 加 上 一 圈 的 大 小 。 
样 后 面 再 执行 offset-userBase 时 ， 则 user 又 像 从 头 开始 写 数 据 了 。 
此 循环 反复 ， 直 到 “生产 者 -消费 者 ”之 间 的 交互 结束 。 


有 了 这 个 基础 ， 我 们 再 来 理解 上 一 步 中 的 bufferEnd 变 量 就 容易 多 
了 ， 如 图 13-26 所 示 。 


buffers server user bufferEnd 


| 


| butferEnd-u 
userBase 


全 图 13-26 bufferEnd 的 含义 


假设 此 时 userBase 指 向 的 是 buffers 位 置 (userBase 每 次 都 以 
frameCount 为 单位 进行 增加 ) ， 虽 然 理 论 上 可 用 的 空间 是 frameCount- 
user+server, 但 是 从 UsetBase3|server 这 一 各 却 是 无 法 使 用 的 《因为 
我 们 只 是 模拟 了 一 个 环形 数据 区 ， 但 在 进行 nemcpy 内 存 复 制 时 它 还 是 只 
朝 一 个 方向 前 进 ) ， 所 以 实际 可 用 内 存 空 间 就 是 bufferEnd-u 了 。 


这 个 环形 区 使 用 得 比较 巧妙 ， 读 者 可 以 再 仔细 体会 下 。 


(4) 现在 我 们 应 该 已 经 明白 AudioTrack 和 AudioFlinger 是 如 何 利 
用 环形 数据 区 进行 读 写 操作 了 ， 接 下 来 具体 分 析 下 它们 是 如 何 同步 共享 
这 块 数据 区 的 。 


在 前 面 的 AudioTrack: :write 中 ， 我 们 发 现 它 分 别 使 用 了 
obtainBuffer 和 releaseBuffer 来 访问 缓冲 区 ， 那 是 不 是 在 这 里 面 使 用 
了 同步 机 制 呢 ? 


AudioTrack: :obtainBuffer 这 个 函数 前 面 已 经 分 析 过 ， 这 里 我 们 从 
资源 互 斥 的 角度 来 重新 审视 一 遍 : 


status_t AudioTrack: :obtainBuffer(Buffer* audioBuffer, int32_t wa 


人 
AutoMutex lock(mLock); 
audio_track_cblk_t* cblk = mCblk; 
uint32_t framesAvail = mProxy->framesAvailable(); 


if (framesAvail == 0) { 


… // 下 面 有 详细 分 析 
J 


return active ? status_t(NO_ERROR) : status_t(STOPPED); 





这 个 函数 的 开头 使 用 了 一 个 AutoMutex 对 象 〈 实 际 上 就 是 一 个 
Autolock) ， 来 保证 函数 内 操作 的 唯一 性 。 


还 记得 我 们 在 本 书 进 程 同步 互 斥 章节 所 举 的 “生产 者 -消费 者 ”的 
经 典 例子 吗 ? 


对 于 生产 者 来 说 ， 执 行 步骤 是 : 
。 循环 开始 ; 


° Produce_item; 

e P(S_emptyCount) ; 

e P(S_ mutex) ; 

e Put_item_to buffer; 
e V(S_mutex) ; 


. V(S fillCount); 
° 继续 循环 。 
对 于 消费 者 来 说 ， 执 行 步骤 是 ， 


° 循环 开始 ; 


e P(S_fillCount) ; 


e P(S_ mutex) ; 

° Read_item from buffer; 
e V(S_mutex) ; 

° V(S_emptyCount) ; 

e Consume; 


° 继续 循环 。 


而 对 于 AudioTrack 这 个 生产 者 来 说 ， 它 可 以 直接 套用 上 面 的 实现 
吗 ? 显然 不 行 。 因 为 经 典 生 产 者 -消费 者 的 例子 中 假设 缓冲 区 的 大 小 是 
分 为 几 等 份 的 ， 每 次 生产 者 或 者 消费 者 都 只 是 生产 或 消耗 其 中 的 一 份 。 
而 AudioTrack 与 AudioF 1inger 对 共享 缓冲 区 的 写 入 和 读 取 则 是 未 知 的 ， 
或 者 更 确切 地 说 不 是 每 次 都 相等 的 。 这 也 就 是 framesAvai lable () 和 
framesReady () 存在 的 意义 : 


uint32_t audio_track_cblk_t::framesAvailable(size_t frameCount, b 


Mutex::Autolock _1(lock); 
return framesAvailable_1(frameCount, isOut); 


这 个 函数 中 使 用 了 audio track_cblk _t: :1ock 这 个 mutex， 它 保证 
了 AudioTrack 是 当前 唯一 进入 缓冲 区 的 对 象 。 这 样 framesAvai lable | 
才能 正确 计算 出 当前 是 否 有 可 用 空间 〈 即 缓冲 区 是 否 满 的 问题 ) 。 如 果 
当前 已 经 没有 可 用 空间 ， 即 framesAvai lable 返 回 为 0， 应 该 怎么 办 呢 ? 
按照 PV 原 语 的 实现 ， 当 然 融 是 要 唤醒 消费 者 去 读 取 数 据 。 下 面 看 看 
obtainBuffer 中 当 framesAvai| == 0 时 的 处 理 : 


// 下 面 这 段 代码 摘 取 自 obtainBuffer: 
if (framesAvail == 0) { 
cblk->lock.lock(); // 没 有 使 用 AutoLock， 那 么 末尾 要 记得 unlock() 





goto start_loop_here; 
while (framesAvail == 0) { 


if (CC_UNLIKELY(result != NO_ERROR)) { 
cblk->waitTimeMs += waitTimeMs; 
if (cblk->waitTimeMs >= cblk->bufferTimeoutMs) { 
if (cblk->user < cblk->loopEnd) { 


cb1k->lock.unlock(); 
result = mAudioTrack->start(); 
cblk->lock.lock(); 


cblk->waitTimeMs = 0; 


if (--waitCount == 0) { 
cblk->Llock.unlock(); 
return TIMED_OUT; 


J 


start_loop_here: 

framesAvail = mProxy->framesAvailable_1(); // 再 次 验证 是 
}//while 循 环 结束 
cblk->lock.unlock(); // 与 开头 的 lock( ) 相 配套 








} 


如 果 framesAvai | 为 0， 则 一 直 在 whi le 循环 体 中 ， 时 
framesAvailable_| 返 回 的 值 不 为 0， 或 者 尝试 次 数 超 限 时 返 


循环 过 程 中 有 时 需要 通知 AudioF |inger。 对 应 代码 如 下 : 


cblk->lock.unlock(); 
result = mAudioTrack->start(); 
cblk->lock.lock(); 


在 调用 start 前 ， 必 须 先 释放 1ock， 否则 AudioF | inger 无 法 正常 执 
行 。 接 着 再 次 获取 这 个 lock， 然 后 判断 是 否 有 可 用 空间 如 果 仍 然 没 
有 就 继续 执行 循环 。 


在 AudioTrack 正 常 写 入 数据 后 ， 它 调用 releaseBuffer 来 更 新 user 
指针 (stepUser) 。 因 为 user 不 属于 共享 资源 ， 也 就 不 需要 特别 的 锁 保 
护 。 





AudioTrack 就 是 这 样 通过 Mutex 来 与 AudioFlinger 互 斥 共享 缓冲 


区 ， 并 实现 音频 数据 流 的 正确 传递 的 。AudioF linger 中 的 实现 略 有 差 
异 ， 但 基本 原理 一 样 ， 请 读者 自行 分 析 。 


(5) 我 们 再 来 看 最 后 一 个 问题 ， 即 AudioTrack 和 AudioFlinger 是 
如 何 跨 进程 共享 缓冲 区 的 。 换 句 话说 ， 它们 如 何 保证 双方 操作 的 是 同一 
块 数据 区 ? 


要 回答 这 个 问题 ， 可 以 从 缓冲 区 的 内 存 申请 过 程 入 手 。 我 们 知道 ， 
这 两 个 进程 间 的 缓冲 区 是 由 AudioF1inger 在 创建 一 个 Track 时 申请 ~ 
而 所 有 Track 的 内 存 分 配 叉 由 mC1ient 来 管理 。Client 内 部 包含 了 一 
MemoryDealer 对 象 来 处 理 内 存 申请 《〈 见 图 13-27) , is E 
是 由 它 来 完成 的 : 
/*frameworks/native/libs/binder/MemoryDealer .cpp*/ 
MemoryDealer: :MemoryDealer(size_t size, const char* name) 


: mHeap(new MemoryHeapBase(size, ©, name)), 
mAllocator(new SimpleBestFitAllocator(size) ) 


WA 


它 有 两 个 重要 的 成 员 变 量 ， 其 中 mHeap 负 责 申 请 内 存 ，mAl locator 
则 负责 管理 内 存 : 


MemoryHeapBase: :MemoryHeapBase(size_t size, uint32_t flags, char 
: mFD(-1), mSize(0), mBase(MAP_FAILED), mFlags(flags), 
mDevice(0), mNeedUnmap(false), moffset(0) 





{ 
const size_t pagesize = getpagesize(); 
size = ((size + pagesize-1) & ~(pagesize-1)); 
int fd = ashmem_create_region(name == NULL ? "MemoryHeapBase" 
ALOGE_IF(fd<0, "error creating ashmem region: %s", strerror(e 
if (fd >= 0) { 
if (mapfd(fd, size) == NO_ERROR) { 
if (flags & READ_ONLY) { 
ashmem_set_prot_region(fd, PROT_READ); 
} 
} 
} 
} 


从 MemoryHeapBase 的 构造 函数 中 可 以 清楚 地 看 到 ， 其 内 部 的 核心 就 
是 Ashmem 匿 名 共 t 享 机 制 ， 这 也 就 解释 了 它 为 什么 色 a 
享 。 关 于 Ashmen， 我 们 在 本 书 进程 章节 已 经 详细 分 析 过 ， 这 里 不 再 蒙 


MemoryDealer 
-sp<IMemoryHeap >mHeap 


—SimpleBestFitAllocator*mAllocator 


+allocate() 
+deallocate() 





A 13-27 MemoryDealer 内 部 成 员 

这 样 通过 Ashmen 机 制 ，AudioF 1inger 生 成 的 内 存 缓冲 区 就 能 轻松 实 
现 与 AudioTrack 的 跨 进 程 共享 ， 并 通过 Mutex 和 Condition 来 保证 它们 的 
互 斥 访问 。 
13.6.3 ”AudioMixer 中 的 音频 流 

AudioMixer 是 由 PlaybackThread (MixerThread) 生 成 的 ， 因 而 与 
AudioFlinger 属 于 同一 个 进程 。 那 么 它 是 与 TrackBase 共 用 音频 数据 缓 
HA, AES “PEPE” E? 


我 们 知道 ，AudioMixer 内 部 有 一 个 mState 成 员 变 量 ， 最 多 达 32 路 的 
Track 数据 就 存储 在 其 中 的 state_ t::tracks[MAX_ NUM TRACKS] 成 员 数 组 
中 。 每 个 PlaybackThread: :TrackBase 在 AudioMi xer 中 对 应 tracks 数 组 
中 的 一 个 元 素 ， 即 : 


struct track_t { 
uinti6_t frameCount; 


AudioBufferProvider* bufferProvider; 
mutable AudioBufferProvider::Buffer buffer; // 8 bytes 


const void* in; // 绥 冲 区 中 的 当前 位 置 





int32_t* mainBuffer; 
int32_t* auxBuffer; 


is 
我 们 只 保留 与 缓冲 区 相关 的 部 分 。 


其 中 ，bufferProvider 是 由 AudioFlinger 调 用 AudioMixer:: 
setBufferProvider 来 赋值 的 。 相 关 源 码 如 下 : 


AudioFlinger::PlaybackThread: :mixer_state AudioFlinger: :MixerThre 
Vector< sp<Track>> *tracksToRemove) 


{... 
sp<Track> t = mActiveTracks[i].promote(); 
Track* const track = 七 .get() 7 … 
mAudioMixer ->setBufferProvider(name, track); 
} 


PlaybackThread: :Track 本 身 就 是 一 个 AudioBufferProvider (因为 
TrackBase 继 承 自 Extended AudioBufferProvider) 。 换 句 话说 ， 
mState. tracks [name]. bufferProvider 指 向 的 就 是 AudioFlinger 中 的 整 
个 Track 记 录 。 


AudioMixer 有 多 个 与 process 相 对 应 的 实现 体 ， 如 
processgener icNoResampl ing, processgenericResampling, 
process OneTrack16BitsStereoNoResamp1ing 等 。 我 们 选取 其 中 的 一 
个 来 验证 一 下 AudioMixer 所 用 的 数据 缓冲 区 和 AudioFlinger， 


AudioTrack 是 否 属 于 同一 


void AudioMixer::process__genericNoResampling(state_t* state, int 


uint32_t enabledTracks = state->enabledTracks; 
uint32_t e0 = enabledTracks; 
while (e0) { 
const int i = 31 - __builtin_clz(e0); 
e0 &= ~(1<<i); 
track_t& t = state->tracks[i]; 
t.buffer.frameCount = state->frameCount; 
t.bufferProvider ->getNextBuffer(&t.buffer, pts); 
t.frameCount = t.buffer.frameCount; 
t.in = t.buffer.raw; 
if (t.in == NULL) 
enabledTracks &= ~(1<<1); 


第 一 个 whi le 循环 里 ， 首 先 给 tracks[ 口 数组 中 所 有 处 于 enabled 状 态 


的 元 素 赋 值 。 由 于 bufferProvider 已 经 在 之 前 的 setBufferProvider 中 
被 设置 为 一 个 PlaybackThread: :Track， 所 以 这 个 getNextBuffer 的 实现 
如 下 : 


status_t AudioFlinger::PlaybackThread: : Track: :getNextBuffer (Audio 
Buffer* buffer, int64_t pts) 


{ 


audio_track_cblk_t* cblk = this->cblk(); 
uint32_t framesReady; 
uint32_t framesReq = buffer->frameCount; // 获 取 空 间 大 小 


framesReady = mServerProxy ->framesReady(); /* 数 据 是 否 己 经 准备 就 


是 指 “ 消 费 者 ”*/ 
if (CC_LIKELY(framesReady)) { // 准 备 就 绪 
uint32_t s = cblk->server; //“ 消 费 者 ”使 用 server 指 针 
uint32_t bufferEnd = cblk->serverBase + mFrameCount; 
bufferEnd = (cblk->loopEnd < bufferEnd) ? cblk- >1oopEnd 
if (framesReq > framesReady) {// 当 前 的 可 读数 据 比 请 求 量 少 
framesReq = framesReady; 








} 

if (framesReq > bufferEnd - s) {// 会 超过 缓冲 区 尾部 
framesReq = bufferEnd - s; 

} 


buffer->raw = getBuffer(s, framesReq); 


buffer->frameCount = framesReq; 
return NO_ERROR; 


整个 处 理 流程 和 我 们 前 面 小 节 分 析 AudioTrack 如 何 写 缓冲 区 数据 类 
似 ， 读 者 可 以 自行 理解 。 需 要 关注 的 重点 是 ， 函 数 参数 中 的 buffer 是 由 
Audiollixer 请 求 的 缓冲 区 地 址 ， 从 其 中 的 实现 来 看 它 的 确 是 由 cb1k 计 算 
出 来 的 。 也 就 是 说 ，AudioWixer 中 用 于 混 音 操作 〈process_XX) 的 缓冲 
区 对 象 和 AudioTrack，AudioFlinger 中 的 数据 区 确实 是 同一 个 。 


13.7 音量 控制 


本 小 节 以 音量 按键 的 处 理 过 程 为 净 机 ， 来 简要 分 析 Android 系 统 中 
音量 控制 的 实现 。 相 信 这 也 是 很 多 人 关心 的 问题 一 一 特别 是 对 于 设备 生 
产 商 〈 比 如 手机 ) 来 说 ， 音 量 的 调节 处 理 还 是 比较 重要 的 。 


当 用 户 按 下 音量 调节 键 时 〈 比 如 音量 +) ， 对 应 的 keyEvent 是 : 


public class KeyEvent extends InputEvent implements Parcelable { 


public static final int KEYCODE_VOLUME_UP = 24; 
系统 中 的 多 个 地 方 都 可 能 会 处 理 这 一 事件 ， 比 如 下 面 这 两 种 情况 
1. AudioManger 


略 去 中 间 的 流转 过 程 ， 我 们 直接 看 看 AudioManager. java 对 这 一 事 
件 的 处 理 : 


public void handleKeyDown(KeyEvent event, int stream) { 
int keyCode = event.getKeyCode(); 
switch (keyCode) { 
case KeyEvent .KEYCODE_VOLUME_UP: 
case KeyEvent .KEYCODE_VOLUME_DOWN: 


if (mUseMasterVolume) { 


} else { 
adjustSuggestedStreamVolume(keyCode == KeyEven 
? ADJUST_RAISE: ADJUST_LOWER, stre 


} 


break; 


这 个 函数 很 简单 ， 它 根据 “音量 +” 或 者 “音量 一 ”进一步 调用 下 
面 的 函数 ， 


public void adjustSuggestedStreamVolume(int direction, int sugges 
int flags) { 
TAudioService service = getService(); 


service.adjustSuggestedStreamVolume(direction, suggestedS 


} 


其 中 getServi ce 将 得 到 名 为 Context. AUDIO SERVICE= “audio” AY 
Binder 服 务 ， 具 体 对 应 的 是 SystemServer. java 中 添加 的 
AudioService。 因 而 上 面 ad justSuggestedStreamVol umeHYServer ig Se 
现 如 下 : 


/*frameworks/media/java/android/media/AudioService. java*/ 
public void adjustSuggestedStreamVolume(int direction, int su 
int streamType; 
if (mVolumeControlStream != -1) { 


} else { 
streamType = getActiveStreamType(suggestedStreamType ) 
} 


if (streamType == STREAM_REMOTE_MUSIC) { 


} else { 
adjustStreamVolume(streamType, direction, flags); 
} 


} 


我 们 知道 ，Android 中 将 声音 分 为 STREAM_MUS1C， 
STREAM_V01CE_CALL 等 多 种 流 类 型 。 那 么 当 用 户 按 下 音量 调节 按键 (SF 
量 +/) 后 ， 具 体 针对 的 是 哪 一 种 呢 ? 这 就 是 getAct iveStreamType 所 要 
做 的 工作 。 从 字面 意思 就 可 以 猜测 到 ， 这 个 函数 用 于 获取 当前 活跃 的 
Stream 类 型 一 一 它 首 先 判 断 当 前 是 不 是 在 通话 中 。 如 果 回 答 是 肯定 的 ， 
再 进一步 判断 是 通过 Speaker 还 是 蓝牙 进行 的 ;又 或 者 当前 如 果 不 在 通 
话 状态 ， 则 判断 是 否 在 播放 音乐 等 。 借 助 于 getAct iveStreamType， 用 
户 可 以 很 方便 地 设置 不 同 场合 下 的 音量 大 小 。 


消 数 adjustStreamVolume 的 源码 实现 我 们 稍 后 讲解 。 
2. interceptKeyBeforeQueueing(WPhoneWindowManager.java 


对 于 部 分 重要 的 物理 按键 〈 比 如 HOME 和 音量 调节 键 ) ， 系 统 会 先 判 
断 它们 是 否 需 要 做 预 处 理 ， 即 interceptKeyBeforeQueueing。 这 个 函数 
首先 会 根据 当前 的 具体 情况 〈 是 不 是 在 通话 状态 、 是 不 是 在 播放 音乐 
等 ) 来 决定 需要 调整 的 STREAM 类 型 ， 而 且 最 后 它 会 调用 





接 下 来 的 处 理 流程 就 和 上 面 


AudioService. adjust StreamVolume 


AudioManager 中 的 情况 一 致 了 : 


/*frameworks/media/java/android/media/AudioService. java*/ 
public void adjustStreamVolume(int streamType, int direction, in 


/*Step 1， 为 各 StreamType 和 寻找 Al1ias 归 类 */ 

int streamTypeAlias = mStreamVolumeAlias[streamType]; 

VolumeStreamState streamState = mStreamStates[streamTypeA 
/*Step 2. XStream Alias 和 寻找 匹配 的 device*/ 

final int device = getDeviceForStream(streamTypeAlias ) ; 

/*Step 3. 获取 对 应 device 的 jndex*/ 

final int aliasIndex = streamState.getIndex(device); 

boolean adjustVolume = true; 

int step; 


step = rescaleIndex(10, streamType, streamTypeAlias);/*Step 

/*Step 5. 音 量 调节 对 于 音量 模式 的 影响 */ 

if (((flags & AudioManager.FLAG_ALLOW_RINGER_MODES) != 0) 
(streamTypeAlias == getMasterStreamType())) { 








} 


/*Step 6. 将 音量 调节 事件 发 送 给 下 一 个 处 理 者 */ 
int oldIndex = mStreamStates[streamType].getIndex(device) ; 
if (adjustVolume && (direction != AudioManager .ADJUST_SAME 
if ((direction == AudioManager.ADJUST_RAISE) && 
!checkSafeMediaVolume(streamTypeAlias, aliasIn 
mVolumePanel.postDisplaySafeVolumeWarning(flags); 
} else if (streamState.adjustIndex(direction * step, 
sendMsg(mAudioHandler, MSG_SET_DEVICE_VOLUME, 
SENDMSG_QUEUE, device, 0, streamState, 0) 



































} 
} 
int index = mStreamStates[streamType].getIndex(device) ; 
sendVolumeUpdate(streamType, oldIndex, index, flags); 


} 
这 个 函数 看 起 来 很 长 ， 但 概括 起 来 只 有 两 个 重点 。 即 : 


e 计算 oldIndex (之 前 的 音量 值 ) ~ index (要 调整 的 音量 值 ) 和 
flags o 
e 调用 sendVolumeUpdate 和 sendMsg 把 上 一 步 的 计算 结果 发 送出 去 。 


我 们 来 分 步 看 看 它 是 如 何 计 算出 o1dlndex 和 index 的 。 


Step1@adjustStreamVvolume。 获 取 当 前 streamType 对 应 的 al iaso 
虽然 STREAM 被 划分 为 多 种 不 同类 型 ， 但 它们 在 某 些 方面 的 行为 却 是 一 样 
的 。 换 句 话 说， 可 以 对 它们 进行 二 次 分 类 ， 这 就 是 mStreamVolumeAl ias 
数组 的 存在 意义 。 

默认 情况 下 ， 各 类 型 STREAM 的 分 组 如 下 《在 支持 VOICE 时 ) : 


private final int[] STREAM_VOLUME_ALIAS = new int[] { 


AudioSystem.STREAM_VOICE_CALL, // STREAM_VOICE_CALL 
AudioSystem.STREAM_RING, // STREAM_SYSTEM 
AudioSystem.STREAM_RING, // STREAM_RING 
AudioSystem.STREAM_MUSIC, // STREAM_MUSIC 
AudioSystem.STREAM_ALARM, // STREAM_ALARM 
AudioSystem.STREAM_RING, // STREAM_NOTIFICATIO 
AudioSystem.STREAM_BLUETOOTH_SCO, // STREAM_BLUETOOTH_S 
AudioSystem.STREAM_RING, // STREAM_SYSTEM_ENFO 
AudioSystem.STREAM_RING, // STREAM_DTMF 
AudioSystem.STREAM_MUSIC // STREAM_TTS 


}; 


右 半 部 分 的 注释 表示 STREAM 类 型 ， 左 边 的 值 是 它们 在 alias 数 组 中 
的 组 编号 。 比 如 STREAM_SYSTEM，STREAM_DTMF， 
STREAM_SYSTEM_ENFORCED 就 和 STREAM_RING 属 于 同一 个 组 。 


同一 小 组 的 stream state 是 一 样 的 ， 由 mStreamStates[] 数 组 记 
录 。 


Step2@ adjustStreamVolume。 根 据 stream alias 来 查询 匹配 的 输 
出 设备 ， 我 们 在 前 几 个 小 节 已 经 有 详细 介绍 ， 这 里 不 再 蒙 述 。 


Step3@ adjustStreamVvolume。 通 过 VolumeStreamState 获 得 音量 值 
(index) ， 来 看 看 这 个 函数 : 


public synchronized int getIndex(int device) { 
Integer index = mIndex.get(device); 
if (index == null) { 
index = mIndex.get(AudioSystem.DEVICE_OUT_DEFAULT 
} 


return index.intValue(); 


} 


VolumeStreamState 内 部 维护 了 一 个 mlndex 数 组 来 记录 device 对 应 


的 index 值 。 


Step4@ adjustStreamVolume。 大 家 应 该 已 经 注意 到 了 ， 当 我 们 在 
调整 音量 时 系统 会 有 一 个 音量 条 出 现 ， 同 时 还 伴随 着 短促 的 提示 音 一 一 
这 样 用 户 才能 知道 系统 是 否 已 经 正确 执行 我 们 的 音量 调节 命令 。 这 一 步 
就 是 在 为 U1 显示 条 做 前 期 准备 。 


Step5@ adjustStreamVolume。 背 量 的 调节 还 可 能 与 手机 的 铃声 模 
式 (Ringer Mode) 有 关 。 


原生 态 系统 中 有 如 下 几 种 模式 : 


public static final int RINGER_MODE_SILENT = 0; // 静 音 模式 
public static final int RINGER_MODE_VIBRATE = 1;// 震 动 模式 
public static final int RINGER_MODE_NORMAL = 2;// 正 常 模式 
private static final int RINGER_MODE_MAX = RINGER_MODE_NORMAL 


比如 当前 是 振动 模式 ， 那 么 当 用 户 调整 音量 后 ， 这 一 模式 很 可 能 被 
改变 《当然 ， 这 取决 于 厂商 制定 的 具体 策略 ) 。 


Step6@ adjustStreamVyolume。 函 数 的 末尾 分 别 使 用 了 两 种 方式 来 
把 音量 调节 命令 进一步 传递 给 后 续 的 处 理 者 一 一 其 中 sendVolumeUpdate 
用 于 产生 音量 调节 提示 音 并 显示 系统 音量 条 ;而 sendWsg 则 会 把 命令 投 
递 到 消息 队列 中 ， 再 由 AudioHandler 做 进一步 处 理 。AudioHandler 除 了 
将 音量 值 保 存 到 系统 设置 文件 中 外 ， 还 会 调用 AudioPol icyService 的 相 
关 接 口 来 真正 调整 音频 设备 的 音量 : 
/*frameworks/av/services/audiof linger/AudioPolicyService.cpp*/ 


status_t AudioPolicyService: :setStreamVolumeIndex(audio_stream_ty 
index, audio_devices_t device) 





{ 
if (mpAudioPolicy->set_stream_volume_index_for_device) { 
return mpAudioPolicy->set_stream_volume_index_for_device(m 
index, device); 
} else { 
return mpAudioPolicy->set_stream_volume_index(mpAudioPolic 
} 
} 


从 前 两 个 小 节 的 分 析 中 我 们 知道 ，mpAudioPol icy 的 默认 实现 是 
legacy_audio_policy 中 的 audio_policy (Audio policy_hal. cpp), m 


set stream volume_index for _ device 实 际 上 又 调用 了 
setStreamVolumelndex@AudioPol icyManagerBase: 


/*hardware/libhardware_legacy/audio/AudioPolicyManagerBase.cpp*/ 
status_t AudioPolicyManagerBase: :setStreamVolumeIndex(AudioSystem 
int index, audio_de 


{ = 
status_t status = NO_ERROR; 
for (size_t i = 0; i < mOutputs.size(); i++) { 
audio_devices_t curDevice =getDeviceForVolume(mOutputs.val 
if ((device == AUDIO_DEVICE_OUT_DEFAULT) || (device == cur 
status_t volStatus = checkAndSetVolume(stream, index, m 
if (volStatus != NO_ERROR) { 
status = volStatus; 
} 
} 
} 
return status; 
} 


因为 系统 中 很 可 能 有 多 个 0utput， 每 个 0utput 又 支持 若干 个 
device， 所 以 上 述 代 码 段 通过 循环 来 查找 所 有 [匹配 的 设备 ， 并 通过 
checkAndSetVolume 进 行 音 量 设 置 : 


status_t AudioPolicyManagerBase: :checkAndSetVolume (...) 


{ 


mpClientInterface->setStreamVolume((AudioSystem: :stream_type 


变量 mpClientlnterface 其 实 表 示 的 就 是 AudioFlinger， 因 而 绕 了 
一 圈 最 终 还 是 由 下 面 的 函数 来 完成 音量 的 设置 ， 这 也 完全 在 我 们 的 意料 
之 中 〈 因 为 AudioF linger 是 执行 者 ) : 


status_t AudioFlinger::setStreamVolume(audio_stream_type_t stream 
audio_io_handle_t output) 
{... 
AutoMutex lock(mLock); 
PlaybackThread *thread = NULL; 
if (output) { 
thread = checkPlaybackThread_1(output); 


} 
mStreamTypes[stream].volume = value; 
if (thread == NULL) { 


} else { 
thread->setStreamVolume(stream, value); 
} 


return NO_ERROR; 


首先 根据 output 找 到 它 对 应 的 PlaybackThread， 而 后 交 由 这 个 线程 
具体 处 理 流 的 音量 ， 同 时 把 新 的 值 记 录 到 mStreamTypes 中 (JER: 
AudioFlinger 和 PlaybackThread 各 有 一 个 mStreamTypes 数 组 ， 不 要 搞 混 
Te 


PlaybackThread 究 竟 会 如 何 处 理 这 一 音量 变化 ， 是 在 
setStreamVyolume 吗 ? 


void AudioFlinger: :PlaybackThread: :setStreamVolume(audio_stream_t 


{ 
Mutex::Autolock _1(mLock); 
mStreamTypes[stream].volume = value; 


可 以 看 到 ，PlaybackThread 只 是 对 音量 值 做 了 简单 的 记录 ， 并 没 
做 实际 的 动作 。 那 么 ， 音 量 的 变化 在 什么 时 候 才 会 生效 呢 ? 


还 记得 我 们 前 面 曾 分 析 过 的 PlaybackThread: :threadLoop 这 个 函数 
吗 ? 它 在 对 音频 数据 进行 处 理 前 需要 先 调用 prepareTracks_| 来 做 准备 
工作 。 下 面 摘录 与 音量 相关 的 那 部 分 源码 : 


AudioFlinger::PlaybackThread: :mixer_state AudioFlinger: :MixerThre 
Vector< sp<Track>> *tracksToRemove) 
ee 


float typeVolume = mStreamTypes[track->streamType()].volum 
float v = masterVolume * typeVolume; 

uint32_t vlr = proxy ->getVolumeLR(); 

vl vlr & OxFFFF; 

vr vlr >> 16; 


mAudioMixer->setParameter(name, param, AudioMixer: :VOLUMEO, 
mAudioMixer ->setParameter(name, param, AudioMixer: :VOLUME1, 


可 以 看 到 ， 之 前 setStreamVyolume 设 置 的 音量 值 在 这 里 会 被 提取 出 
来 ， 并 和 主音 量 等 其 他 因素 进行 综合 运算 一 一 这 样 得 到 的 才 是 最 终 的 音 
量 值 。 紧 接着 这 个 值 还 会 通过 setParameter 传 给 AudioMixer， 以 保证 后 
者 能 根据 当前 音量 做 出 正确 的 混 音 处 理 。 


13.8 音频 系统 的 上 层 建筑 
13.8.1 从 功能 入 手 

到 目前 为 止 ， 我 们 已 经 详细 分 析 了 音频 系统 的 底层 实现 ， 主 要 包括 
AudioTrack、AudioFlinger、AudioPolicyService 以 及 HAL 四 个 部 分 。 
基于 这 些 基础 册 来 理解 音频 系统 的 上 层 建筑 ， 应 该 会 轻松 很 多 。 接 下 来 
我 们 仍然 遵循 从 整体 到 局 部 的 内 容 编 排 顺 序 。 


se SR Ee 
IMLAY) 。 


° 录制 (Record) 

° 相片 拍摄 /无 声 视 频 录 制 

典型 应 用 如 “照相 机 ”。 

音频 录制 

典型 应 用 如 “录音 机 ”。 

有 声 视频 录制 

典型 应 用 如 “摄像 机 ” 〈 同 时 录制 声音 和 视频 ) 。 
° 回放 (Playback) 


° 无 声 视频 回放 


这 种 情况 比较 少见 ， 即 视频 文件 中 不 带 音频 信息 。 


。 音频 回放 
比如 音乐 播放 器 。 


。 有 声 视频 回放 


播放 同时 带 有 音 视 频 的 媒体 文件 。 

看 上 去 组 合 情 况 比较 多 ， 但 对 于 应 用 开发 人 员 来 说 真正 需要 关心 的 
只 有 两 类 ， 即 MediaPlayer 和 MediaRecorder 。Android 赋 予 了 它们 同时 
处 理 音 频 和 视频 的 能 力 ， 使 得 我 们 在 编写 多 媒体 应 用 时 可 以 把 更 多 精力 
放 在 U1 设 计 、 功 能 实现 与 用 户 体 验 上 ， 而 不 必 涉 及 具体 的 音 视 频 解码 、 
显示 、 音 频 设 备 管理 等 细节 。 


我 们 用 图 13-28 来 概括 Android 系 统 中 面向 上 层 开发 人 员 提供 的 整体 
功能 设计 。 


接 下 来 我 们 将 分 别 介绍 MediaPlayer 和 MediaRecorder。 


L 一 
MediaRecorder 


全 图 13-28 多 媒体 功能 概括 






MediaPlayer 
13.8.2 MediaPlayer 


MediaPlayer 是 大 部 分 应 用 工程 师 使 用 Android 多 媒体 系统 的 直接 入 
口 。 不 论 是 音乐 播放 器 、 视 频 播 放 器 ， 还 是 网 络 收音 机 《网 络 收 音 机 本 
质 上 可 以 理解 为 一 个 “网 络 音频 ”的 音乐 播放 器 ) ， 或 多 或 少 都 需要 借 


助 于 MediaPlayer 来 实现 音 视 频 的 回放 ， 如 图 13-29 所 示 。 


Music Player |} Video Player aa vs 


ny , 


Media Player 


oon 
A 413-29 MeidaPlayet 与 应 用 程序 的 关系 图 
1. MediaPlayer 的 状态 迁移 图 


MediaPlayer 只 是 一 个 状态 机 ， 它 依赖 于 MediaPlayerService 来 完 
成 具体 功能 一 一 自身 则 不 断 向 应 用 程序 回馈 当前 的 播放 状况 。 


图 13-30 完 整地 描述 了 一 个 MediaPlayer 实 例 的 各 种 状态 、 触 发 事件 
以 及 迁移 流程 。 
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全 图 13-30 MediaPlayertk A ìt 4 A 








图 中 的 方 框 代 表 状 态 ， 实 线 箭 头 代表 状 态 的 触发 条 件 〈 比 如 执行 
setDataSource 这 个 函数 将 人 izedit#%) ， 虐 
线 箭头 代表 状态 迁移 时 的 回调 〈 比 如 通过 dprepareAsync 函 数 来 准备 数 
据 ， 当 数据 就 绪 后 将 进入 Prepared 状 态 ， 且 通过 回调 函数 
OnPreparedListener. onPrepared 来 通知 应 用 程序 ) 。 


另外 ， 在 任何 情况 下 有 错误 发 生 时 ，MediaPlayer 的 状态 都 会 迁移 
到 “Error”， 同 时 回调 0nErrorListener. onError () 通知 使 用 者 ; 而且 
在 任何 时 候 调用 release () ， 程 序 均 进入 End 状 态 。 


在 状态 机 的 约束 下 ， 所 有 跨 状态 的 操作 都 是 非法 的 。 比 如 我 们 不 能 
期 望 程序 从 1dle 跨 越 Initialized 直 接 进入 Prepared 后 者 又 是 
start () 前 必 经 的 阶段 。 换 名 话说， 在 没有 setDataSource () 和 
prepare () /prepareAsync () 前 ，MediaPlayer 是 绝对 不 允许 程序 直接 调 
用 start () 的 。 关 于 MediaPlayer 的 更 多 状态 控制 细节 ， 请 读者 自行 参阅 
官方 文档 说 明 。 


2. MediaPlayer 的 内 部 实现 


既然 MediaPlayer 只 是 一 个 状态 机 ， 那 么 它 是 如 何 完 成 上 层 应 用 播 
放 请 求 的 呢 ? 要 解答 这 个 问 题 并 不 难 ， 只 要 看 下 它 的 Java 层 和 Nat ive 层 
实现 即 可 。 


Java 层 显然 只 是 一 个 简单 的 “中 介 ”， 代 码 片 段 如 下 : 


/*frameworks/base/media/java/android/media/MediaPlayer.java*/ 
public class MediaPlayer 


a 





private native void _setDataSource(String path, String[] keys 
throws IOException, IllegalArgumentException, SecurityExc 
IllegalState Exception; 

public native void prepare() throws IOException, IllegalState 

public native boolean setParameter(int key, Parcel value); 


中 间 JN1 层 实现 也 相对 简单 ， 我 们 就 不 一 一 分 析 了 ， 直 接 来 看 本 地 
层 的 MediaPlayer (cpp) 对 象 。 以 setDataSource 为 例 ， 源 码 如 下 : 


/*frameworks/av/media/libmedia/Mediaplayer.cpp*/ 
status_t MediaPlayer: :setDataSource(const sp<IStreamSource>&sourc 


i 
status_t err = UNKNOWN_ERROR; 


const sp<IMediaPlayerService>& service(getMediaPlayerService( 
if (service != 0) { 
sp<IMediaPlayer> player(service->create(getpid(), this, m 
// 在 MPS 中 注册 
if ((NO_ERROR != doSetRetransmitEndpoint(player)) || 
(NO_ERROR != player->setDataSource(source))) { 
player.clear(); 
} 


err = attachNewPlayer (player); 


J 


return err; 


首先 当然 还 得 获取 MediaPlayerService 的 代理 
IMediaPlayerService， 即 getMediaPlayerService。 这 个 函数 无 非 就 是 
通过 ServiceManager 来 查找 名 为 “media. player” 的 Binder 服 务 ， 然 后 
转化 为 Proxy 对 象 。 


接着 调用 如 下 语句 : 
sp<IMediaPlayer> player(service->create(getpid(), this, mAudioSes 


这 样 MediaPlayerService 就 为 这 个 MediaPlayer 播 放 实 例 生成 了 一 
个 “内 部 管理 者 ”， 并 由 1MediaPlayer 来 建立 一 条 纽带 。 这 是 不 是 有 点 
类 似 于 AudioTrack 与 AudioFlinger 间 的 IAudioTrack? 


如 果 player 变 量 没有 发 生 错误 ， 就 可 以 把 播放 源 设置 进去 ， 即 
player->setDataSource (source) 。 最 后 利用 attachNewPlayer 把 这 个 
Player 与 MediaPlayer (cpp) 关联 起 来 。 如 果 一 切 顺 利 ， 状 态 机 就 会 从 
1dle 跳 转 到 Initialized。 如 下 所 示 : 





status_t MediaPlayer::attachNewPlayer(const sp<IMediaPlayer>& pla 
{ 
status_t err = UNKNOWN_ERROR; 
sp<IMediaPlayer> p; 
{ // scope for the lock 
Mutex: :Autolock _1(mLock); 
if ( !( (mCurrentState &MEDIA_PLAYER_IDLE) || (mCurrentStat 


return INVALID_OPERATION;// 当 前 是 否 处 于 有 效 的 状态 





} 


mPlayer = player; // 记 录 下 IMediaPlayer， 后 续 会 经 常 使 用 到 
if (player != 0) { 





mCurrentState = MEDIA_PLAYER_INITIALIZED; / /状态 跳 转 成 功 
err = NO_ERROR; 
} else { 
ALOGE("Unable to to create media player"); 
} 
} 


return err; 


ee AY — FFARR OKA HLIEITA FIER, AAHABZEM BAKA 
下 用 户 都 可 以 调用 setDataSource 的 ， 如 果 跨 状态 操作 就 会 出 错 。 各 状 
态 的 enum 值 定义 如 下 : 


enum media_player_states { 


MEDIA_PLAYER_STATE_ERROR = 0, 

MEDIA_PLAYER_IDLE = 1 << 0, 
MEDIA_PLAYER_INITIALIZED = 1 << 1, 
MEDIA_PLAYER_PREPARING =1<< 2, 
MEDIA_PLAYER_PREPARED =1 << 3, 
MEDIA_PLAYER_STARTED = 1 << 4, 
MEDIA_PLAYER_PAUSED =1<< 5, 
MEDIA_PLAYER_STOPPED = 1 << 6, 
MEDIA_PLAYER_PLAYBACK_COMPLETE = 1 << 7 


F}; 

可 见 其 与 我 们 前 面 描述 的 状态 迁移 图 是 完全 一 致 的 。 

关于 MediaPlayer 如 何 通 过 |MediaPlayer 与 MediaPlayerService 开 
cor 从 而 完成 一 系列 复杂 的 播放 控制 ， 我 们 统一 放 在 后 续 小 节 进 行 
讲解 。 
13.8.3 MediaRecorder 


MediaRecorder 既 可 以 录制 音频 ， 也 可 以 录制 视频 。 它 和 
MediaPlayer 一 样 ， 需 要 受到 严格 的 状态 机 约束 ， 如 图 13-31 所 示 。 


图 13-31 和 前 面 的 MediaPlayer 状 态 迁 移 图 大 同 小 异 ， 只 是 各 个 状态 
和 触发 条 件 有 所 差别 ， 因 而 我 们 就 不 子 详 细 摘 述 了 。 


从 硬件 的 角度 来 看 ，MediaRecorder 将 比 MediaPlayer 涉 及 更 多 的 硬 
件 设 备 ， 至 少 包括 : 


。 视频 


通过 视频 录制 设备 〈 比 如 Camera) 采集 数据 ， 并 将 采集 到 的 图 像 显 
示 在 终端 屏幕 上 实现 同步 预览 ， 最 后 按照 用 户 的 要 求 保 存 到 指定 的 存储 
设备 (Flash, SDE) 中 。 


通过 音频 录制 设备 〈 比 如 MIC) 采集 数据 ， 并 按照 用 户 的 要 求 保存 
到 指定 存储 设备 中 〈 如 果 是 同时 录制 “ 音 视频 ”的 情况 ， 则 要 将 采集 到 
的 音 视 频数 据 进行 统一 存储 ) 。 
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全 图 13-31 MediaRecorderjk A 3t 44 A 
。 编码 器 


在 将 音 视 频数 据 存储 为 文件 之 前 ， 我 们 还 需 调用 编码 器 对 其 进行 先 
期 处 理 。 所 以 一 个 典型 的 有 声 视频 的 录制 过 程 ， 需 要 使 用 到 的 硬件 设备 
包含 但 不 限于 : Camera、Microphone、 Sor Storage、Codec， 如 图 


13-32 所 示 。 
Camera 


| 
| 
Media Recorder | | Application | | 
| 
| 


全 图 13-32 从 硬件 角度 理解 MediaRecorder 


可 以 设想 一 下 ， 如 果 要 求 应 用 开发 人 员 直 接 利用 这 些 硬件 设备 来 完 
成 整个 录制 过 程 ， 将 会 是 多 么 庞大 的 一 项 工程 如 果真 是 这 样 ， 
Android 系 统 恐 怕 也 不 会 得 到 如 此 迅猛 的 发 展 了 一 一 Android 对 硬件 的 控 
制 和 抽象 寺 装 非常 有 效 。 比 如 针对 上 面 的 硬件 设备 ，Android 提 供 了 妇 
下 控制 实现 。 





。 视频 


开发 者 可 以 通过 Camera 类 来 轻松 管理 数据 的 采集 流程 ， 并 且 将 这 些 
数据 与 SurfaceView 建 立 关 联 以 实现 终端 屏幕 预览 。 另 外 ， 还 可 以 调用 
MediaRecorder 的 各 种 函数 接口 进行 录制 参数 的 配置 及 保存 。 


->i 


同 理 ， 开 发 者 只 需 通 过 MediaRecorder 来 配置 音频 录制 所 需 的 人 参 
数 ， 如 指定 音频 的 编码 格式 、 需 要 保存 的 路 径 等 即 可 。 系 统 会 自动 根据 
=A he nae ees 并 将 最 终结 果 按 照 用 户 的 要 求 保 
子 下 来 。 


o Fg ee 


不 论 是 硬件 还 是 软件 编码 器 ， 都 不 需要 应 用 开发 人 员 去 关心 细 市 。 
他 们 唯一 要 做 的 就 是 通过 MediaRecorder 来 设置 参数 。 


由 此 可 见 ，APK 应 用 程序 与 MediaRecorder 是 “客户 ”与 “服务 提供 
商 ” 的 关系 。 或 者 更 确切 地 讲 ，MediaRecorder 是 “采购 人 人员” 一 一 应 
用 程序 只 负责 描述 需求 “通过 MediaRecorder 提 供 的 各 种 设置 消 数 ) ， 
而 MediaRecorder 则 负责 根据 这 份 需求 清单 在 现 有 系统 中 “采购 ”相关 
设备 ， 然 后 把 这 些 设备 协调 起 来 去 完成 用 户 的 要 求 ， 并 且 最 大 程度 地 让 
应 用 程序 可 以 脱离 其 中 的 烦琐 细节 。 

MediaRecorder 和 MediaPlayer 一 样 ， 涉 及 的 模块 很 多 ， 可 以 说 从 应 
用 层 一 直到 Linux 驱 动 层 都 需要 有 相应 的 支持 。 因 而 我 们 先 提 供 一 张 完 
整 的 框架 图 来 帮助 大 家 更 好 地 理解 ， 如 图 13-33 所 示 。 


图 13-33 中 : 


e Media Application 


录制 音 视频 的 APK 应 用 程序 ， 它 是 整个 框架 的 发 起 者 ， 亦 是 “录制 
需求 ”的 制定 者 。 


e MediaRecorder 


它 是 应 用 程序 的 直接 沟通 者 ， 也 是 框 染 的 组 织 方 。 它 在 收 到 上 层 应 
用 的 需求 后 ， 协 调 其 他 所 有 模块 来 完成 任务 ， 并 向 应 用 程序 汇报 实时 情 
To 


e MediaPlayerService (MPS) 


简单 地 说 ，Android 中 的 MPS 是 底层 多 媒体 库 的 “代表 ” 这 对 于 
保持 系统 的 可 兼容 性 有 重要 意义 。 比 如 从 Android 2. 2 开始 ， 系 统 多 媒 
体 库 实 现 已 经 从 0penCore 逐 渐 过 渡 到 了 StageFright， 而 MPS 的 存在 使 得 
上 层 框 架 可 以 基本 保持 不 变 。 





e StageFright 


在 Android 新 版 的 实现 中 ，StageFright 已 经 取代 以 往 的 0penCore 成 
为 系统 中 唯一 的 多 媒体 库 实 现 。 我 们 在 后 续 小 节 还 会 对 它 进 行进 一 步 分 
析 。 
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e VideoSource 


一 般 情 况 下 我 们 录制 视频 的 来 源 是 Camera， 并 且 Android 系 统 已 经 
提供 了 成 熟 且 丰富 的 android. hardward. Camera 包 来 满足 开发 者 对 于 
Camera 的 各 种 常规 需求 


e AudioSource 


和 视频 源 类 似 ， 录 制 音 频 同样 也 需要 硬件 采集 设备 。 
MediaRecorder 支 持 多 种 类 型 的 音频 源 ， 不 过 最 常用 的 还 是 Mi c。 


e Preview 


在 视频 录制 的 过 程 中 进行 同步 预览 也 是 必需 的 ， 这 样 才能 让 用 户 实 
时 了 解 采 集 到 的 数据 。Android 系 统 提 供 的 SurfaceView 类 可 以 方便 地 实 
现 这 一 功能 ， 同 时 结合 0penGL 还 可 以 对 采集 到 的 数据 进行 画面 亮度 、 对 
比 度 等 特效 调整 。 值 得 一 提 的 是 ， 当 程序 通过 MediaRecorder 录 制 时 ， 
系统 会 强制 要 求 用 户 提 供 一 个 有 效 的 承载 SurfaceView， 因 而 一 旦 应 用 
程序 处 于 后 台 就 无 法 完成 正常 的 录制 了 。 


接 下 来 的 内 容 安排 如 下 。 


° 通过 一 个 有 声 视 频 的 录制 范例 ， 让 读者 可 以 首先 从 应 用 层 角 度 
来 了 解 MediaRecorder 的 使 用 方法 。 


° MediaPlayerService 中 与 MediaRecorder 相 关 的 内 部 实现 。 
主要 涉及 如 下 几 个 目录 的 源码 。 


e frameworks\av\media\libmediaplayerservice ; 
e frameworks\av; 


e frameworks\base\media. 


13.8.4 一 个 典型 的 多 媒体 录制 程序 


我 们 先 从 应 用 开发 层面 来 看 看 多 媒体 录制 需要 做 哪些 工作 。 下 面 的 
源码 段 展 示 了 一 个 典型 的 “录像 机 ”的 工作 流程 : 


Camera mCamera= null; 
try { 
mCamera= Camera.open(); /获取 一 个 Camera 实 例 。 如 果 机 器 上 有 多 
个 Camera， 可 以 在 open 时 指定 希望 打开 的 那个 Cam 








catch (Exception e){ 
/* 如 果 当 前 Camera 正 在 使 用 ， 将 抛 出 异常 */ 
} 


mMediaRecorder = new MediaRecorder(); /* 实 例 化 MediaRecorder， *HMe 

mCamera.unlock(); // 这 一 步 是 必须 的 

mMediaRecorder.setCamera(mCamera); /*MediaRecorder 和 Camera 建 立 连 接 ， 

集 设备 。 这 一 设置 将 逐步 往 下 传 ， 直 腊 

mMediaRecorder .setAudioSource(MediaRecorder .AudioSource.CAMCORDER 

mMediaRecorder .setVideoSource(MediaRecorder .VideoSource.CAMERA) ; 
/* 设 置 音 视频 的 数据 来 源 ， 这 样 MediaRecorder 才 知道 应 该 从 哪个 
Android 目 前 支持 的 音频 和 视频 来 源 请 查阅 后 面 的 表格 */ 

















mMediaRecorder.setProfile(CamcorderProfile.get(CamcorderProfile.Q 
/* 设 置 音 频 和 视频 的 编码 器 、 输 出 格式 、 比 特 率 等 一 系列 参数 。Android 2.2 以 前 

mMediaRecorder.setOutputFile(getOutputMediaFile(MEDIA TYPE_VIDEO) 
/* 设 置 输出 文件 名 、 路 径 */ 

mMediaRecorder.setPreviewDisplay(mPreview.getHolder().getSurface( 


try { 

mMediaRecorder.prepare(); /* 在 Start 以 前 必须 先进 行 prepare*/ 
} catch (IllegalStateException e) { 

releaseMediaRecorder(); 

return false; 
} catch (IOException e) { 

releaseMediaRecorder(); 

return false; 














} 
mMediaRecorder.start(); /开始 录制 ， 屏 幕 上 同时 会 显示 视频 图 像 的 预览 */ 


目前 系统 支持 的 视频 来 源 只 有 两 种 ， 即 
MediaRecorder. VideoSource. CAMERA 和 Media 
Recorder. VideoSource. DEFAULT. 


支持 的 音频 来 源 类 型 较 多 ， 如 表 13-7 所 示 。 


表 13-7 ”多 媒体 录制 可 选 的 音频 来 源 


和 Camera 相 匹配 的 Microphone， 
否则 就 是 设备 的 Main Microphone 


语音 通信 服务 所 配置 的 


VOICE_COMMUNICATION Mieropliome， 划 Volp 


语音 通话 中 下 行 部 分 音频 


VOICE DOWNLINK (Downlink ) 





语音 通话 中 上 行 部 分 音频 
R 


为 语音 识别 服务 所 配置 的 
VOICE_RECOGNITION Microphone， 人 否则 就 按 DEFAULT 
的 情况 处 理 





从 这 个 范例 可 以 看 到 ， 经 过 MediaRecorder 的 高 度 封 装 ， 应 用 程序 


只 需 做 简单 的 设置 就 可 以 很 轻松 地 完成 音 视 频 的 录制 工作 。 
MediaRecorder 一 方面 提供 了 丰富 的 接口 的 常规 录制 需求 ; 

另 一 方面 很 好 地 实现 了 模块 的 独立 性 ， 将 诸如 预览 、Camera 数 据 采集 等 
工作 完整 地 封装 在 多 个 系统 Service 和 Binder 服 务 接口 中 ， 为 开发 人 员 
快速 定制 录制 功能 提供 了 有 力 的 保障 。 


13. 8.5 MediaRecorder 源 码 解 析 


MediaRecorder 源 码 主 要 由 3 部 分 组 成 。 


e MediaRecorder.java 

SDK 中 提供 的 面向 APK 应 用 程序 的 类 实现 。 
e android_media_MediaRecorder.cpp 

上 述 类 接口 的 JNI 实 现 。 
e MediaRecorder.cpp 


MediaRecorder 的 本 地 类 ， 它 负责 与 MediaPlayerService 进 行 通信 
并 确保 具体 功能 的 实现 。 


下 面 我 们 以 MediaRecorder 中 的 一 个 接口 〈 即 setPreviewDisplay) 
为 线索 ， 分 析 其 内 部 的 源码 实现 : 


/*frameworks/base/media/java/android/media/MediaRecorder.java*/ 
public class MediaRecorder { 


private Surface mSurface; 

public void setPreviewDisplay(Surface sv) { 
mSurface = sV;// 保 存 用 户 设置 的 Surface 对 象 

} 


ee ee ee ee RU ari 
KHAR ENEIT 了 简单 的 赋值 。 线索 似乎 断 了 ， 其 HSA 然 ， 我 们 再 
来 看 以 下 代码 : 


/*frameworks/base/media/java/android/media/MediaRecorder.java*/ 


public class MediaRecorder 


{ 
static { 
System.loadLibrary("media_jni"); //#MediaRecorderf INIA 
native_init(); // 这 个 初始 化 函数 是 一 个 本 地 实现 
} 
} 


那么 ，native_init 函 数 做 了 哪些 工作 呢 ? 


/*frameworks/base/media/jni/android_media_MediaRecorder.cpp*/ 
static fields_t fields; //}{MediaRecorder. java F HIRS Wy R EERTE 
static voidandroid_media_MediaRecorder_native_init(JNIEnv *env) 


{ 











jclass clazz; 
clazz = env->FindClass("android/media/MediaRecorder"); // 找 到 KN 


fields.context = env->GetFieldID(clazz, "mNativeContext", "I" 
找到 MediaRecorder(Java) 对 象 中 的 mNativeContext 成 员 变 量 */ 





fields. surface = env->GetFieldID(clazz, "mSurface", "Landroid 
/* 然 后 通过 同样 的 方法 找到 mSurface 成 员 变 量 ， 也 就 是 我 们 在 setPreviewl 
变量 ， 然 后 保存 到 fields 中 */ 














jclass surface = env->FindClass("android/view/Surface"); 


fields.surface_native = env->GetFieldID(surface, ANDROID_VIEW 
/*surface_native 对 应 的 是 mSurface 中 的 mNativeSurface 域 。 前 者 是 Java 
后 者 是 Surface 的 本 地 实现 */ 


通过 JN1 的 特性 可 知 ，fields 中 的 各 变量 与 Java 类 中 的 域 产生 了 关 
HK. ABA, fields. surface 和 fields. surface_native 在 什么 时 候 产 生 
(FHE? 


/*frameworks/base/media/jni/android_media_MediaRecorder.cpp*/ 
static voidandroid_media_MediaRecorder_prepare(JNIEnv *env, jobje 
/* 还 记得 我 们 前 面 特别 提醒 过 ， 应 用 程序 在 start() 前 必须 要 先 调 用 prepare() 吗 ?*/ 
{... 
































sp<MediaRecorder> mr = getMediaRecorder(env, thiz); /* 这 里 得 到 | 
中 创建 的 MediaRecorder (cpp) 对 象 */ 
jobject surface = env->GetObjectField(thiz, fields.surface);/ 
if (surface != NULL) { 

const sp<Surface> native_surface = get_surface(env, surfa 





if (process_media_recorder_call(env, 
mr ->setPreviewSur face(native_surface->getIGrap 
"jJava/lang/RuntimeException", "setPreviewSurfac 
return; 
} 
} 
process_media_recorder_call(env, mr->prepare(), "java/io/IOEx 
failed."); 
/*process_media_recorder_call 是 对 执行 结果 ( 即 它 的 第 二 个 参数 ) 的 统一 处 
比如 失败 时 抛 出 异常 */ 








ey prepare ( 做 了 两 件 事 。 


e 向 MediaRecorder(.cpp) 设 置 PreviewSurface 


也 就 是 说 ， 前 面 我 们 通过 setPreviewDisplay 设 置 的 Surface， 要 直 
到 prepare 时 才 会 真正 被 传递 给 MediaPlayerService。 


e 调用 MediaRecorder(.cpp) 中 的 prepare0 


先 来 看 看 MediaRecorder(. cop) 中 一 个 关键 的 全 局 变量 ， 如 下 所 


小: 


/*frameworks/av/include/media/Mediarecorder.h*/ 
sp<IMediaRecorder> mMediaRecorder; 


这 里 的 mMediaRecorder 是 应 用 程序 与 MediaPlayerService 之 间 的 桥 
梁 。 换 句 话说 ， eee eee ee 
空间 ， 真正 跨 进程 的 地 方 就 发 生 在 对 这 个 变量 的 操作 中 。 它 
MediaRecorder (. cpp) 的 构造 亢 数 里 创建 的 : 


/*frameworks/av/media/libmedia/Mediarecorder.cpp*/ 
MediaRecorder: :MediaRecorder() : mSurfaceMediaSource(NULL) 
{... 
const sp<IMediaPlayerService>& service(getMediaPlayerService( 
4 lh] ServiceManager @ ifJMediaPlayerServicelkk4*/ 
if (service != NULL) { 
mMediaRecorder = service->createMediaRecorder(getpid());/ 
生成 一 个 IMediaRecorder*/ 


} 
if (mMediaRecorder != NULL) { 


mCurrentState = MEDIA_RECORDER_IDLE; // 状 态 机 开始 运转 


} 
doCleanup(); 


MediaPlayerService 是 如 何 生成 这 个 1IMediaRecorder 对 象 的 呢 ? 


/*frameworks/av/media/libmediaplayerservice/MediaPlayerService.cp 
sp<IMediaRecorder> MediaPlayerService: :createMediaRecorder () 


i, 


sp<MediaRecorderClient> recorder = new MediaRecorderClient(th 
实际 上 是 一 个 MediaRecorderClient*/ 


mMediaRecorderClients.add(w); 
return recorder; 


ImediaRecorder 在 MediaPlayerService 中 对 应 的 实现 类 是 
MediaRecorderClient， 它 将 承载 后 续 应 用 进程 中 MediaRecorder 辣 ] 
MediaPlayerService 发 起 的 各 种 业务 请 求 。 


回 过 头 来 看 看 Medi aRecorder (. cpp) 内 部 又 是 如 何 处 理 Surface 的 
呢 ? 


/*frameworks/av/media/libmedia/Mediarecorder.cpp*/ 
status_t MediaRecorder::setPreviewSurface(const sp<Surface>& surf 


fi. 


status_t ret = mMediaRecorder ->setPreviewSurface(surface); /* 
PlayerService*/ 


return ret; 


可 见 这 和 本 小 节 开 头 给 出 的 MediaRecorder 框 架 图 完全 一 致 ， 即 
MediaPlayerService 才 是 多 媒体 录制 的 核心 ， 而 MediaRecorder 只 是 一 
个 “协调 者 ”。 


我 们 来 小 结 一 下 setPreviewSurface 的 处 理 过 程 。 


o 应 用 程序 通过 MediaRecorder.java 中 的 setPreviewSurface0 设 置 一 个 
Surface。 通 常 Apk 应 用 程序 是 通过 在 UI 布局 中 添加 一 个 SurfaceView 
组 件 来 间接 获取 Surface 对 象 。 


e MediaRecorder fy Ad, EH, Bl android_media_MediaRecorder.cpp 4 
以 利用 JNI 特 性 访问 到 上 一 步骤 中 设置 的 Surface 变 量 ， 并 保存 在 自 
己 的 内 部 全 局 变量 中 。 

e 当 应 用 程序 调用 prepare(@MediaRecordet 时 ，JNI 层 的 实现 将 间接 调 
用 setPreviewSurface(@ MediaRecorder.cpp. 

e MediaRecorder.cpp € 4 4 #1 MediaPlayerService it 47 H5 t E38 fa BY R 

理 ， 即 : 








sp<IMediaRecorder> mMediaRecorder ; 


通过 这 一 变量 ， 我 们 才 将 Surface 最 终 传递 给 
MediaPlayerService. 


13.8.6 MediaPlayerService 简 析 


和 很 多 系统 服务 一 样 ，MediaPlayerServi ce 也 是 在 设备 一 开机 时 就 
启动 的 。 具 体 而 言 ， 它 属于 mediaserver 程 序 的 一 部 分 ， 而 后 者 在 系统 
一 个 应 用 进程 〈init) 解析 的 init. rc 脚本 中 添加 了 启动 项 : 


/*init.rc*/ 
service media /system/bin/mediaserver 
class main 
user media 
group audio camera inet net_bt net_bt_admin net_bw_acct drmrp 
ioprio rt 4 


/system/bin 目 录 下 放置 的 是 系统 级 的 可 运行 程序 ， 如 
mediaserver。 我 们 在 介绍 AudioFlinger 和 AudioPolicyService 时 已 经 
分 析 过 这 个 程序 ， 它 的 源码 文件 在 工程 的 frameworks\av\media\ 
mediaserver 目 录 中 。 更 多 细节 读者 可 以 参考 前 面 小 节 的 介绍 ， 这 里 不 
RAR. 


紧 接 着 前 面 两 个 小 节 对 MediaPlayer 和 MediaRecorder 的 讲解 ， 我 们 
来 看 看 它们 是 如 何 与 MediaPlayerService 进 行 交互 的 。 


1. MediaRecorder 


前 一 小 节 中 ，createMediaRecorder (函数 的 任务 是 创建 一 个 
MediaRecorderClient 对 象 ， 并 返回 给 调用 者 ， 从 而 建立 起 它 和 


MediaPlayerService 的 远程 通信 。MediaPlayerService 担 负 着 录制 、 回 
放 、 编 解码 等 一 系列 工作 ， 因 而 MediaRecorderClient 只 是 其 中 一 个 负 

责 多 媒体 录制 的 实体 。 另 外 ， 创 建 出 来 的 MediaRecorder 通 过 如 下 语句 

保存 进 MediaPlayerService 的 全 局 管理 中 


mMediaRecorderClients.add(w); 


这 也 从 侧面 验证 了 MediaPlayerService 是 允许 同时 有 多 个 
Recorder (MediaPlayer 也 是 同样 的 道理 ) 存在 的 ， 只 不 过 这 样 的 情况 
并 不 多 见 。 


因为 是 跨 进 程 通 信 ， 可 以 猜想 到 Medi aRecorderCl ient 一 定 需 要 继 
承 Binder 的 特性 ， 如 下 所 示 : 


Class MediaRecorderClient : public BnMediaRecorder {... 


Class BnMediaRecorder: public BnInterface<IMediaRecorder>{... 


} 


Bnlnterface 是 一 个 模板 类 ， 定 义 如 下 : 


template<typename INTERFACE> 
class BnInterface : public INTERFACE, public BBinder{ 
dich 


和 Java 不 同 ，C++ 语 言 支 持 多 重 继 承 ， 因 而 最 终 MediaRecorder 的 继 
承 关系 如 图 13-34 所 示 。 


Interface 


IMediaRecorder 


> 
Pe 
~ 

~ 


IBinder 


BBinder 


BnMediaRecorder 


MediaRecorderClient 
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其 中 ， 左 边 部 分 的 11nterface 体 现 了 MediaRecorder 提 供 的 功能 ， 
而 右边 部 分 的 1Binder 昌 实现 了 它 的 路 法 程 能 力 。 如 果 对 这 些 基础 知识 
ETERA, BANURERES E hinder 节 。 接 下 来 的 讨论 
中 我 们 只 关心 1MediaRecorder 这 一 部 分 的 实现 。 


我 们 还 是 以 setPreviewSurface 这 个 接口 为 线索 ， 帮 助 大 家 将 整个 
流程 串 起 来 : 


/*frameworks/av/media/libmediaplayerservice/MediaRecorderClient.c 
status_t MediaRecorderClient: :setPreviewSurface(const sp<Surface> 


Mutex::Autolock lock(mLock); 


return mRecorder ->setPreviewSurface(surface) ; 


出 现 了 一 个 mRecorder 变 量 ， 来 看 看 它 的 定义 : 


MediaRecorderBase *mRecorder; 


MediaRecorderBase 的 作用 可 以 理解 为 Java 中 的 Interface， 它 提供 
了 一 种 抽象 的 接口 “协议 ” \ 管 最 终 的 实现 如 何 变化 ， 其 向 外 提供 
的 功能 都 不 变 : 
/*frameworks/av/media/libmediaplayerservice/MediaRecorderClient.c 


MediaRecorderClient: :MediaRecorderClient(const sp<MediaPlayerServ 


{ 





ALOGV("Client constructor"); 

mPid = pid; 

mRecorder = new StagefrightRecorder; //StageFright 终 于 出 现 了 
mMediaPlayerService = service; 


从 上 面 的 代码 段 可 以 看 到 ，MediaRecorderClient 直 接 使 用 了 
StageFright， 而 没有 根据 条 件 做 任何 判断 选择 。 这 也 进一步 证 明 
StageFright 已 经 完全 取代 了 0penCore。 


由 于 只 是 “中 介 ” 的 角色 ，MediaRecorder 本 身 并 没有 太 多 复杂 的 
操作 。 值 得 一 提 的 是 ， 各 芯片 厂商 如 三 星 、 高 通 ) 在 研发 一 款 产 品 


时 ， 通 常会 提供 与 平台 硬件 配置 相 匹 配 的 Player/Recorder 实 现 。 这 些 
扩展 的 Player/Recorder 以 原生 态 的 StageFright 为 “蓝本 ”， 并 在 此 基 
础 上 迅速 构建 出 更 切合 产品 需求 的 播放 器 /录制 器 。 


2. MediaPlayer 


在 MediaPlayer::setDataSource 中 有 如 下 语句 : 


sp<IMediaPlayer> player(service->create(getpid(), this, mAudioSes 


下 面 看 看 其 具体 的 源码 实现 : 


sp<IMediaPlayer> MediaPlayerService::create(const sp<IMediaPlayer 
{ 
pid_t pid = IPCThreadState::self()->getCallingPid(); 
int32_t connId = android_atomic_inc(&mNextConnId) ; 
sp<Client> c = new Client(this, pid, connId, client, audioSes 
State: :self()->getCallingUid())j; 
wp<Client> w = C; 


{ 
Mutex::Autolock lock(mLock); 
mClients.add(w); 

} 

return C; 


这 个 Client 的 命名 容易 让 人 产生 歧义 ， 实 际 上 它 和 
MediaRecorderClient 类 似 ， 二 者 分 别 用 于 回放 和 录制 操作 。 和 
MediaRecorderClient 稍 有 不 同 的 地 方 是 ， Client 是 
MediaPlayerService 的 舱 套 类 一 一 这 可 能 是 因为 回放 相对 于 录制 功能 没 
有 那么 复杂 。 


紧 接 着 在 setDataSource 时 ， Client 会 根据 请 求 的 Source 类 型 的 不 
同 来 选择 合适 的 播放 器 (除非 系统 属性 “media. stagefright. use- 
nuplayer” 强制 要 求 使 用 NU_PLAYER， 否则 默认 播放 器 类 型 是 
STAGEFRIGHT_PLAYER) 一 一 具体 是 由 getPlayerType 函 数 实现 的 ， 读 者 
可 以 自行 分 析 。 目 前 系统 支持 的 播放 器 包括 : SONIVOX_PLAYER, 
STAGEFRIGHT PLAYER, NU PLAYER, TEST PLAYER#OPV_PLAYER. 另外 ， 
和 前 述 的 MediaRecorder 一 样 ， 心 片 厂商 有 可 能 在 此 基础 上 扩展 出 自己 
的 播放 器 类 型 。 


在 决定 了 使 用 哪个 底层 播放 器 后 ，Client 会 进一步 通过 
createP layer (来 创建 一 个 对 应 的 Player 实 体 。 这 和 录制 时 的 情况 有 很 
大 不 同 ， 因 为 录制 时 我 们 直接 就 指定 了 StageFright。 


对 于 大 部 分 开发 人 员 而 言 ，StageFright 底 层 库 的 源码 实现 并 不 是 
必须 要 掌握 的 。 但 它们 可 以 辅助 大 家 更 好 地 理解 多 媒体 框架 ， 建 议 有 兴 
趣 的 读者 自行 深入 分 析 。 


13.9 Android 支持 的 媒体 格式 


本 市 将 从 音频 、 视 频 和 网 络 流 媒 体 3 个 方面 来 分 析 Android 系 统 对 媒 
体格 式 的 支持 情况 。 


13.9.1 音频 格式 

Android 系 统 所 支持 的 音频 编 解 码 器 〈Codec) 及 常见 的 文件 格式 
(Container) 如 表 13-8 所 示 。 请 读者 务必 先 理 清 编码 格式 和 文件 格式 
的 区 别 ， 以 免 引 起 混淆。 


表 13-8 Android 支 持 的 音频 编 解 码 器 


nune "afe a] wt 


。3GPP (.3gp) * MPEG- 
4〈(.mp4，.m4a)。ADTS 上 支持 E 
raw AAC (.aac， 解 码 需 | 声 /5.0 
要 Android 3.1 以 上 ， 编 码 | 样 速 3 
需要 Android 4.0 以 上 版 ”I48kH; 
本 ， 暂 不 文 持 ADIF ) 





ELD (enhancedllYes (4.1llYes (4.1 以 |e MPEG-TS (.ts， 需 要 | 声 采 本 
low delay UES- E Android 3.0 以 上 版 本 ) ~48k 
AAC) 
oe 3 
es Yes 3GPP(.3gp) ; 
Yes e 3GPP(.3gp) . 
(.flac) 


Yes (Android 
: FLAC 。 


No Yes MP3 (.mp3) 

。 类 型 0 和 类 型 

1 (.mid, .xmf, .mxmf) 
MIDI No Yes 


5 








O 








< 
oo 


e Ogg (.ogg)* Matroska 
(mkv, Android 4.0 以 上 ) 


WAVE (.wav) 





13.9.2 视频 格式 


除了 表 13-? 所 列 出 的 视频 格式 外 ， 开 发 人 员 还 可 以 通过 导入 第 三 方 
库 来 支持 更 多 的 视频 编 解码 器 功能 。 


表 13-9 Android 支 持 的 视频 编 解 码 器 






AWE Yo 码 上 | 解 mi| 文件 格式 | 说 






。3GPP (.3gp) 
e MPEG-4 (.mp4) 







。3GPP (.3gp) 
e MPEG-4 (.mp4) 
e MPEG-TS (ts, 







低 阶 规 
格 





Yes (Android 





i; B l 
MPEG- 


Yes (4.30) 


13.9.3 图 片 格式 
Android 系 统 目 前 只 支持 常见 的 几 种 图 片 格式 ， 如 表 13-10 所 示 。 


表 13-10 Android 支 持 的 图 片 编 解 码 器 









MEI ye mig m|| 说 明 


JPEG 、 
re Yes Yes e Jpeg 格 式 的 图 片 


GIF » f a Gif 动 态 图 片 
PNG llYes Yes PNG PNG 图 片 
(.png) 





BMP. |INo Yes BME BMPS H 


Google 推 出 的 一 种 


有 损 压 缩 图 片 格 
式 ， 基 于 VP8 





13.9.4 网 络 流 媒体 

Android 系 统 是 面向 移动 终端 的 ， 因 而 对 网 络 协议 格外 重视 。 
ee > layer 便 完整 地 封装 了 对 多 种 网 络 流 媒体 协议 的 支持 ， 包 括 但 不 

e RTSP (RTP, SDP) 

RTSP (Real Time Streaming Protocol) 即 实时 流传 输 协 议 ， 是 一 
种 基于 TCP/UDP 的 应 用 层 协议 。 为 了 让 读者 对 RTSP 有 个 直观 的 认识 ， 下 
面 我 们 以 场景 对 话 〈 电 影院 ) 的 形式 来 模拟 协议 流程 。 如 下 : 

客户 端 : 我 想 看 《蜘蛛 侠 4》， 有 什么 选择 吗 ? 

服务 端 很 多 ， 比 如 2D 的 、3D 的 、1Max 的 ……: 

客户 端 : 我 需要 关于 1Max 的 详细 描述 。 

服务 端 : 好 的 ， 它 是 这 样 的 …… 

客户 端 : 挺 好 的 ， 我 就 要 这 个 。 你 帮 有 我 出 张 票 。 

服务 端 : 请 问 要 什么 时 间 段 的 、 什 么 位 置 的， 要 不 要 VIP 包间 ? 

客户 端 : 要 最 后 两 排 的 。 

服务 端 : 可 以 ， 请 稍 等 …… 这 是 你 的 票 ， 请 收 好 。 


客户 端 ， 明白 ， 我 要 进去 观看 了 。 

ARS im: 好 的 ， 影 片 马上 开始 播放 。 

(影片 放映 中 ) 

Pim: 什么 烂 片 ， 我 不 想 看 了 。 

ARS im: 好 的 ， 终 止 放 映 。 

e HTTP/HTTPS progressive streaming 

e HTTP/HTTPS live streaming draft protocol : 

° 只 支持 MPEG-2 TS 媒体 文件 

e Protocol version 3 (Android 4.0 以 上 版 本 ) 

° Protocol version 2 (Android 3.x) 

° Android 3. 0 以 前 的 版 本 不 支持 

° Android3. 1 以 前 的 版 本 不 支持 HTTPS 
13.10 1D3 信 息 简 述 

根据 项 目 经 验 ， 开 发 人 员 在 Android 多 媒体 研发 中 经 常会 碰 到 一 个 
知识 点 ， 即 1D3。1D3 是 Android 管 理 多 媒体 文件 的 重点 之 一 《后 续 小 节 
有 介绍 ) ， 因 而 我 们 在 本 小 节 做 统一 讲解 。 

在 欣赏 一 首 歌 时 ， 大 家 应 该 会 留意 到 播放 器 上 会 显示 诸如 “ 标 
题 ”、“ 演 唱 者 ”、“ 专 辑 ” 等 信息 它们 可 以 让 听众 更 好 地 了 解 这 
首 歌曲 。 此 类 信息 的 来 源 有 两 个 ; 其 一 是 播放 器 从 网 络 上 直接 下 载 获取 
的 〈 当 然 ， 前 提 是 你 的 设备 能 连接 上 网 ) ; 其 二 就 来 源 于 该 音频 文件 自 
身 储存 的 信息 一 一 1D3。 


1D3 通 常用 于 MP3 文 件 中 ， 到 目前 为 止 有 两 个 版 本 ， 即 1D3v1 和 
1D3v2。 其 中 v2 版 本 又 分 为 若干 个 子 版 本 。 虽 然 1D3 的 使 用 非常 广泛 ， 但 





还 没有 国际 统一 的 1D3 规 范 发 布 。 换 句 话说 ， 协 议 本 身 基本 上 属于 
开发 者 约定 俗 成 的 标准 ， 


1D3 的 官方 网 址 是 : http://id3. org/。 


1D3 最 初 是 由 Eric Kemp 于 1996 年 首创 的 。 当 时 MP3 音 频 已 经 比较 流 
行 ， 却 还 没有 通用 的 记录 歌曲 信息 的 方法 。 于 是 Kemp 开 创 性 地 在 MP3 的 
文件 末尾 加 入 了 一 些 数据 ， 即 后 来 的 1D3v1。 那 么 ， 为 什么 是 加 在 文件 
尾部 呢 ? 这 是 为 了 兼容 当时 的 主流 播放 器 。 可 以 想象 ， 早 期 的 播放 器 还 
不 知道 1D3 的 存在 ， 当 然 无 法 解析 出 其 中 的 数据 含义 。 因 而 将 1D3 加 在 头 
部 位 置 很 可 能 导致 这 个 音频 文件 被 播放 器 误 判 为 “无 效 ” 或 者 “ 损 
坏 ”。 当 然后 期 1D03 流 行 起 来 后 ， 播 放 器 考虑 到 1D3 的 存在 ， 也 就 不 会 有 
类 似 问 题 了 


1D3v1 记 录 的 信息 相对 简单 ， 它 占用 的 空间 是 固定 的 128 字 节 ， 
以 “TAG” 字 符 开 头 。 剩 余 字 节 则 用 于 描述 如 表 13-11 所 示 的 一 系列 信 


表 13-11 1D3v1 中 信息 一 览 





inal fo |" 关 评 论 信息 | 
iil = 





其 中 流派 就 有 一 百 多 种 细 分 包括 Winhnp 扩 展 的 部 分 ) ， 我 们 就 不 
一 一 列 出 了 。 


1D3v1 的 一 个 延伸 版 本 是 由 Michael Mutschler 在 1997 年 提出 的 。 他 
人 号 二 


认为 “Comment” 部 分 并 没有 什么 实际 的 用 途 ， 因 此 将 其 分 出 两 个 字 节 
用 于 记录 轨道 数 (Track Number) ， 称 为 1D3v1. 1。 不 过 ， 这 个 版 本 用 
得 并 不 多 。 


后 来 的 几 个 版 本 改进 主要 是 基于 1D3v1 容 量 太 小 的 问题 。 因 而 人 们 
想到 分 别 将 各 个 主要 “ 域 ”进行 扩容 ， 如 表 13-12 所 示 《〈 共 227 字 节 ) 。 


表 13=12 扩展 的 1D3v1 


| e 


扩展 标志 ， 即 “TAG+” 


标题 信息 。 注 意 “AG+” 并 不 者 盖 “TAG” 中 的 信 








一 共有 30+60 个 字 市 用 于 描述 标题 名 ， 下 同 





WJ. O=unset, 1=slow, 2= medium, 3=fast, 
speed |1 4=hardcore 
Gene fi 流派 信息 


i 格式 mmm:ss 








歌曲 的 结束 时 间 ， 格 式 mmm:ss 


到 1998 年 ，1D3v2 出 现 了 。 它 和 1D3v1 在 所 描述 的 信息 以 及 采用 的 数 
据 记 录 格 式 等 多 个 方面 都 发 生 了 很 大 变化 。 具 体 如 下 所 示 : 


。 数据 存储 位 置 差 异 


和 V1 版 本 的 一 个 重要 区 别 ， 就 是 1D3v2 不 再 存放 于 文件 尾部 ， 而 是 
头 部 。 这 主要 是 为 了 便于 网 络 流 媒体 的 播放 。 因 为 我 们 不 可 能 等 到 媒体 
Sn ones 这 显然 是 没有 意义 的 。 它 以 “1D3” 为 
开头 TRA o 


。 数据 长 度 大 小 可 变 


前 面 说 过 ，1D3v1 中 各 域 的 大 小 是 国定 的 。 比 如 标题 部 分 就 只 有 那 
么 大 的 空间 ， 如 果 超 过 就 不 能 完全 容纳 了 ; 而 有 的 信息 却 又 不 需要 用 那 
么 多 的 字 证 来 存储 ， 从 而 造成 了 浪费 一 一 这 些 因素 都 导致 103 新 版 本 采 
用 了 可 变 长 度 的 存储 方式 。 


。 文本 编码 格式 
随 着 1D3 使 用 范围 的 不 断 扩 大 ， 可 以 说 它 已 经 遍布 全 球 ， 因 而 有 必 


要 考虑 国际 化 因素 。 这 就 自然 而 然 地 牵扯 到 文本 编码 格式 的 问题 。 读 者 
可 以 参阅 本 书 应 用 篇 中 对 编码 格式 以 及 Android 系 统 中 常见 的 一 些 文 本 





格式 问题 的 详细 介绍 
1. ID3v2 Header 


1D3v2 的 头 部 格式 如 表 13-13 所 示 。 


表 13-13 1D3v2 Header 





Ci ee e 





文件 的 头 3 个 字 市 为 固定 值 ， 表 明 是 











两 个 字 节 表示 版 本 号 。 第 一 个 字 贡 是 
主 版 本 号 ena 
号 。 所 有 修正 版 本 都 要 求 是 问 下 兼容 
的 ， 但 是 主 版 本 则 没有 这 个 要 求 。 两 











个 字 节 都 不 能 是 FF 











一 个 字 节 的 标志 位 ， 用 于 表示 是 个 
压缩 、 是 否 非 同步 等 。 不 同 版 本 的 
ID3 的 Flag 是 有 差异 的 ， 可 以 参阅 最 新 
%abc00000《〈 二 | 路 本 的 ID3v2 协 议 了 解 详 情 。 以 
ID3v2.3 为 例 ， 第 一 个 bit 表 示 
Unsynchronisation， 第 二 个 bit 表 示 
Extended Header， 第 三 个 bit 表 示 





Experimental Indicator 


四 个 字 节 的 Size 值 ， 用 于 表示 整个 Tag 
的 大 小 ae 但 不 包括 头 部 
EEO. 所 ease t a 
1 * 0% ig; 0, À MM. 总 共 是 
ID3 size lI4 * %0xxxxxxx 4x7=28bit， 即 可 以 表达 256M。 BEN 





例子 ，257 个 字 市 长 的 Tag 表 示 为 : 
$00 00 02 01 


2. Extended Header 


有 没有 “扩展 信息 ”是 可 选 的 ， 播 放 器 在 解析 1D3 时 可 以 从 上 面 表 
格 中 的 Flag 里 判断 是 否 带 有 这 一 信息 。Extended Header 并 不 是 很 重 
要 ， 目 前 大 部 分 文件 都 没有 附 帝 扩展 头 ， 因 而 我 们 不 过 多 介绍 。 


3. ID3v2 Frames 


在 1D3v2 中 ，1D3 Tag 是 由 一 系列 “frames” 来 摘 述 的 。 每 个 Frame 
最 大 可 达 16MB， 整 个 Tag 的 大 小 限制 在 256MB。 目 前 最 新 的 1D3v2 中 已 经 
有 多 达 84 种 Frame， 而 且 应 用 程序 也 可 以 自 定义 Frame 信 息 〈 尽 管 这 种 情 
况 比 较 少 ， 但 并 不 是 不 可 行 。 此 时 要 特别 注意 避 锡 Frame 名称 与 其 他 人 
定义 的 重 名 ) 。 


因为 一 个 1D3 Tag 中 通常 会 高 有 多 种 Frame， 所 以 同样 需要 有 Header 
来 描述 它们 。 根 据 官方 文档 的 解释 ， 这 个 头 信 息 格 式 如 下 : 


Frame ID $xx xx xx xx (four characters) 
Size $XX XX XX XX 
Flags $xx XX 


Frame ID 是 由 “A~Zz” 和 “0~9” 字 符 组 成 的 。 起 初 的 1D3 中 Frame 
1D 只 允许 3 个 字符 ， 后 来 改 为 4 个 字符 。 其 中 “X~2” 这 3 个 字符 可 以 供 
个 人 使 用 ， 而 不 需要 在 1D3v2 Header 中 特别 标注 。Size 域 用 于 表示 此 
Frame 的 大 小 ， 随 后 的 Flags 有 两 个 字 节 一 一 第 一 个 字 节 用 于 表 
示 “status messages”， 第 二 个 字 节 则 用 于 编码 说 明 。 如 下 所 示 : 


%abc00000 %ijk00000 
第 一 字 节 第 二 字 节 


Frame Flags 详 解 如 表 13-14 所 示 。 


表 13-14 Frame Flags 详 解 


rae Value | Description | 


Frame should be yn 4% frame unknown, 


aaa should be anes oe 
FE FUT AR AP EKA A 


discarded 


只 读 标 志 位 。 如 果 说 这 个 
1 Read only frame 是 只 读 的 ， 那 么 随意 
0 Not Read only 更 改 很 可 能 会 破坏 诸如 签 
名 等 重要 信息 


Frame is not compressed 

Frame is compressed 
using [#ZLIB zlib] with 4 bytes 压缩 标志 位 
for 'decompressed size’ 
appended to the frame header 


Frame is not encrypted 
Frame is encrypted 


加 密 标 志 位 


0 Frame does not contain 

group information 是 否 和 其 他 frames 同 属 一 
1 Frame contains group 

information 





JU) 


虽然 一 般 情 况 下 我 们 会 倾向 于 以 优先 级 顺序 来 对 Frame 进 行 排列 ， 
但 协议 标准 并 没有 强制 要 求 这 么 做 。 一 个 Tag 至 少 要 包含 一 个 Frame， 而 
每 个 Frame 又 至 少 要 有 一 个 字 节 大 小 ， 且 不 包括 头 信息 。 








通常 1D3 laa ee ace 8859-1， 当 然 也 可 以 使 用 Uni code. 
fags ah SSG, 就 用 于 表示 这 文 个 Frame 中 数据 所 采用 的 编 
码 方 


0: ISO-8859-1 
1: UTF-16 


ID3v2. 4 版 本 中 ， 还 支持 使 用 UTF-16BE 和 UTF-8 等 编码 格式 。 
举 个 例子 ， 图 13-35 所 示 是 某 MP3 文 件 的 1D3 信 息 。 





0 1 4345 6 ?8 
ooo000000h: 49 44 33 03 00 00 00.0 
00000010h: Naa Di FF FE DO B 













全 图 13-35 MP3 文 件 的 ID3 信 息 


按照 前 面 的 分 析 ， 这 个 范例 中 的 Frame 1D=TIT2， 数 据 部 分 一 共有 7 
SS, Bl: 


“01FFFE00673172” 。 

它 以 01 开 头 ， 因 而 是 UTF-16。 随 后 的 FFFE 表 明 它 是 Low Endian, 
而 实际 上 所 表达 的 数据 是 : 0x67007231 一 一 在 Uni code 码 中 ， 这 个 数字 
对 应 的 字符 是 中 文 “ 最 爱 ”。 


其 他 Frame 类 型 的 解析 都 差不多 ， 我 们 不 再 准 述 


13.11 Android 多 媒体 文件 管理 


和 Microsoft Windows 等 桌面 型 操作 系统 不 同 ，Android 系 统 主要 面 
向 终端 设备 ， 因 而 它 的 很 多 “行为 ”都 是 基于 这 一 “场景 需求 ”而 设计 
的 。 例 如 ，Android 对 多 媒体 文件 的 管理 就 女 合 了 “移动 终端 ”的 特 
性 。 


Windows 中 所 有 文件 类 型 都 是 趋 于 平等 的 ， 管 理 特定 多 媒体 文件 的 
工作 通常 由 应 用 程序 来 完成 。 比 如 Windows MediaPlayer 里 会 有 用 户 喜 
爱 的 各 种 播放 列表 ， 或 者 将 某 个 文件 路 径 设 为 默认 的 乐曲 存储 目录 。 而 
Android 系 统 作为 舱 入 式 系统 的 一 种 ， 有 其 局 限 性 。 比 如 ， 没 有 鼠标 、 
没有 完整 的 键盘 、 屏 幕 相 对 于 PC 小 、 操 作 不 便 等 。 因 而 ， 它 有 必要 为 用 
户 的 常用 功能 提供 足够 的 操作 便利 一 一 基于 这 样 的 思想 ， 由 系统 来 统一 
管理 多 媒体 文件 就 是 必然 的 。 


Android 对 多 媒体 文件 的 管理 主要 分 为 以 下 几 部 分 工作 。 
o 扫描 多 媒体 文件 -MediaScannefService 


扫描 的 对 象 包 括 内 部 和 外 部 存储 两 种 。 它 预先 将 设备 中 所 有 多 媒体 
文件 的 信息 (包括 1D3〉 提取 出 来 。 这 样 当 用 户 希 望 去 访问 这 些 文件 或 
者 读 取 文件 的 信息 上 时， 系统 就 可 以 做 到 快速 响应 ; 这 也 同时 减轻 了 应 用 
程序 的 负担 ， 如 APK 播 放 器 可 以 直接 向 系统 查询 当前 有 哪些 mp3 文 件 ， 而 
不 需要 再 做 耗 时 的 扫描 操作 。 这 部 分 工作 统一 由 MediaScannerService 
完成 ， 它 继承 于 BroadcastReceiver， 后 面 会 有 更 详细 的 介绍 。 


© 存储 多 媒体 文件 信息 -MediaPtovider 
MediaScannerService 得 到 的 扫描 结果 如 何 存储 ， 又 怎么 向 用 户 提 
供 查 询 呢 ? Android 系 统 选择 了 ContentProvider 的 方式 。 这 个 组 件 专门 
用 于 数据 进程 间 的 共享 ， 类 似 于 “仓库 ”的 概念 。 具 体 而 言 ， 存 储 多 媒 
体 文件 信息 的 工作 由 MediaProvider 来 完成 。 
o 用 户 的 查询 入 口 -MediaStore 


可 能 有 读者 会 问 ， 既 然 有 了 上 面 的 MediaProvider， 为 什么 还 要 有 
个 MediaStore? 它们 之 间 是 什么 关系 ? 举 个 例子 ， 就 比较 容易 理解 了 。 


MediaStore 从 名 称 来 看 是 商店 的 意思 ， 那 么 当 用 户 需要 购买 商品 时 Ct 
如 牙 言 、 牙 刷 这 些 生 活用 品 ) ， 显 然 大 都 是 通过 Store 来 完成 的 〈 当 然 
不 排除 个 别人 直接 从 厂家 拿 货 ) 。 但 是 牙 富 和 牙刷 本 身 并 不 是 商店 生产 
的 ， 商 店 只 是 为 生产 商 提供 了 展示 的 柜台 ， 让 顾客 和 这 些 商 品 有 一 个 统 
一 的 “接触 点 ”。 言 下 之 意 ， 对 于 没有 在 商店 中 摆 放 出 来 的 商品 ， 即 便 
厂商 有 大 批 现 货 ， 顾 客 也 买 不 到 。MediaStore 将 所 有 的 “商品 ”划分 为 
如 下 几 类 。 

e MediaStore.Files 

多 媒体 “仓库 ”中 的 所 有 文件 ， 不 论 它们 是 不 是 多 媒体 文件 。 

e MediaStore.Audio 
音频 文件 都 归于 这 一 类 。 
MediaStore. Video 


视频 文件 归 类 于 此 。 


e MediaStore.Image 

图 像 文 件 的 存储 地 。 

因为 不 同类 型 的 文件 向 外 提供 的 Content Provider 的 UR1 是 不 一 样 
的 ， 所 以 每 种 类 型 的 “仓库 ”都 会 提供 一 个 getContentUri ( 的 接口 来 
告诉 使 用 者 其 具体 的 引用 位 置 。 

从 上 面 的 解释 可 以 看 出 ，Android 系 统 中 的 多 媒体 文件 管理 者 实际 
上 是 一 个 “应 用 程序 ”， 用 到 BroadcastReceiver，ContentProvider 等 
组 件 。 这 就 不 难 理解 为 什么 它 对 应 的 源码 大 多 在 packages 目 录 下 了 。 


图 13-36 朱 述 了 多 媒体 文件 管理 的 几 个 主要 组 成 部 分 。 





O 


SRRI 


Ff 


HE- 










MediaStore URI 





MediaProvider 


MediaScannerService 


MediaScannerReceiver 
ACTION BOOT COMPLETED 


ACTION_MEDIA_SCANNER_SCAN_FILE 





ACTION_MEDIA_ MOUNTED 


全 图 13-36 ”多 媒体 文件 管理 


接 下 来 我 们 将 分 别 介绍 这 几 个 重要 的 组 成 部 分 。 





13.11.1  MediaStore 


“商店 ”的 工作 就 是 陈列 物品 ， 并 对 各 厂商 的 产品 进行 统一 管理 以 
响应 “用 户 ” 的 需求 ， 如 查询 、 购 买 等 。 因 而 ， 它 并 不 需要 了 解 商 品 的 
设计 原理 和 生产 过 程 。 


源码 路 径 : frameworks\base\core\java\android\provider 


MediaStore 是 面向 应 用 程序 的 入 口 ， 所 以 它 存 放 在 frameworks 中 ， 
并 且 作 为 SDK 的 一 部 分 开放 给 应 用 开发 者 。 


这 个 类 里 还 包含 几 个 子 类 ， 主 要 是 完成 上 面 所 说 的 媒体 类 型 划分 。 
读者 在 下 面 这 个 代码 段 中 可 侧重 看 看 每 种 类 型 的 Content URI: 


/*MediaStore.java*/ 
public final class MediaStore 4... 
public static final class Files { 
public static Uri getContentUri(String volumeName) { 
return Uri.parse(CONTENT_AUTHORITY_SLASH + volumeName 
/* CONTENT_AUTHORITY_SLASH = "content://media /", 因 而 Fil 
"content:// media /[volumeName]/file"*/ 
} 


eS 


public static final class Images {f/X*Images 还 可 以 再 分 为 Media 和 Th 
public static final class Media implements ImageColumns { 
public static Uri getContentUri(String volumeName) { 
return Uri.parse(CONTENT_AUTHORITY_SLASH + volumeName +"/ 
/* 所 以 Media 的 URI 为 : "content://media /[volumeName ]/images/ 
} 
wt 


public static class Thumbnails implements BaseColumns { 
public static Uri getContentUri(String volumeName) { 
return Uri.parse(CONTENT_AUTHORITY_SLASH + volume 
"/images/thumbnails"); 
/*ThumbnailsfYURIA: "content://media /[volumeName]/i 


} 
a 
… 其 他 类 型 是 相似 的 ， 读 者 可 以 自己 分 析 。 


由 上 面 的 分 析 可 以 总 结 出 MediaStore 所 提供 的 媒体 类 型 的 Content 
Uri 格 式 。 


content://media/[volumeName]/[media_type]/[sub_type] 


其 中 : 


e volumeName 分 为 Internal 各 External 两 种 。 

e media_type 即 Files、Images、Audio、Video 等 媒体 类 型 。 

e sub_type 是 上 述 媒 体 类 型 的 细 化 分 类 ， 如 Images 中 的 Media 和 
Thumbnails. 


MediaStore 中 描述 的 都 是 MediaProvider 与 应 用 程序 间 的 接口 内 
容 ， 开 发 人 员 可 以 通过 它 来 了 解 系统 都 提供 了 了 哪些 Media 分 类 以 及 各 类 
中 的 一 些 详细 信息 。 


下 面 我 们 将 讲解 MediaProvider 具 体 是 如 何 提供 这 些 UR1 所 指向 的 数 
据 的 。 


13. 11. 2 ”多 媒体 文件 信息 的 存储 “仓库 ” 


MediaProvider 是 多 媒体 文件 信息 的 存储 “仓库 ”， 因 而 不 论 是 
MediaScanner 还 是 MediaStore， 工 作 都 是 围绕 这 个 Provider 展 开 的 。 
MediaProvider 继 承 自 ContentProvider， 运 行 在 一 个 标准 的 应 用 程序 
中 。 只 不 过 这 个 应 用 程序 是 随 Android 系 统一 起 安装 进 设备 的 ， 并 且 多 
数 情况 下 由 系统 来 调用 和 控制 〈 理 论 上 普通 应 用 程序 也 可 以 操作 它 ) 。 


如 果 读 者 有 Android 设 备 ， 并 且 喜 欢 DIY 软 件 ， 相 信和 会 注意 到 系统 中 
有 一 个 名 为 “android. process. media” 的 常 驻 进程 。 那 么 
android. process. media 具 有 什么 样 的 功能 ， 为 什么 它 需 要 常 驻 内 存 ? 
如 图 13-37 所 示 。 


我 们 从 Android 源 码 中 可 以 找到 答案 。 这 个 进程 是 下 面 几 个 应 用 
的 “母体 ”: 





MediaProvider 


e MediaProvider ; 
e DownloadProvider ; 


e DrmProvider. 


可 见 ， 虽 然 名 称 市 有 “media”， 但 其 实 并 不 仅仅 和 多 媒体 有 关 


联 。 
接着 我 们 看 看 MediaProvider 在 AndroidManifest. xml PAJA PH: 


/*AndroidManifest.xml*/ 
<application android:process="android.process.media"android: label 
android: supportsRtl="true"> 
<provider android:name="MediaProvider" android:authorities="media 
android:multiprocess="false" android: exported="true 
<grant-uri-permission android: pathPrefix="/external/" /> 
/* 这 个 权限 允许 以 "/external" 开 头 的 path 可 以 临时 获取 访问 权 | 
<path-permissionandroid:pathPrefix="/external/" 
android: readPermission="android.permission.READ_ 
android: writePermission="android.permission.WRIT 
</provider> 


可 见 ，MediaProvider 对 访问 权限 设置 了 比较 严格 的 要 求 。 


我 们 知道 ContentProvider 本 质 上 是 对 数据 库 〈 或 者 其 他 存储 方 
式 ) 的 管理 ， 从 这 个 角度 来 说 MediaProvider 所 要 做 的 工作 就 是 创建 用 
于 存储 各 种 媒体 信息 的 数据 库 ， 并 提供 更 新 、 查询 寺 操 作 。 那么 ， 它 维 
护 了 哪些 数据 库 呢 ? 图 13-38 显 示 了 MediaProvider 安 装 目录 下 生成 的 所 
有 数据 库 。 





局 EF Android4.1 [emulator-5554] 0 e Android4.1 [4.1.1, debug] 
system_process 146 8600 
com. android. systemui 215 8601 
com. android. phone 245 8603 
com. android. launcher 266 3604 
com. android. settings 280 38605 
android. process. acore 311 3606 
com. android. calendar 330 3607 
com. android. deskclock 361 8606 
com. android. providers. calendar 381 8609 
com. android. contacts 396 3610 
com. android. mms 430 8611 
android. process. media 446 8612 
com. android. email 476 8613 
com. android. exchange 495 8602 
com. android. inputmethod. latin 536 3614 


A 413-37 一 个 刚 启 动 的 Android 设 备 的 进程 情况 


E & com.android.providers.media 2012-09-10 
由 (> cache 2012-09-10 17:15  drwxrwx--x 





日 (> databases 2012-09-10 17:16 CC drwxrwx--x 
司 external.db 159744 2012-09-10 17:16 CC -rw-rwe---- 
=) external.db-shm 32768 2012-09-24 20:12 -rwe------- 
=) external.db-weal 461472 2012-09-24 20:12  -rw------- 
司 internal.db 4096 2012-09-10 17:15 CC -rwe-rwe---- 
| internal.db-shm 32768 2012-09-24 20:12 -rwe------- 
司 internal.db-wal 325512 2012-09-24 20:12  -rwe------ 





全 图 13-38 MediaProvider #é 4 69 HK GE Æ 


可 以 清楚 地 看 到 ， 数 据 库 分 为 两 类 (Blinternal#external) , 

和 前 一 小 TiWediaStore 中 讲解 的 VolumeName 世 是 一 致 的 。 ie 
ih, t2 REI internal. db 和 external. db 来 分 别 表 示 系 统 内 部 和 外 
部 存储 设备 即 可 ， 为 什么 还 会 有 external. db-shm 这 样 的 数据 库存 在 
Ne? 和 很 多 应 用 程序 一 样 ， 数 据 库 的 操作 也 会 有 很 多 临时 文件 。 比 如 当 
某 笔 业务 失败 后 ， 需 要 回 退 ， 此 时 这 些 文件 就 派 上 用 场 了 。 当 应 用 程序 
成 功 完成 某 个 操作 ， 或 者 完全 退出 后 ， 这 些 临 时 的 辅助 文件 是 否 会 被 删 
除 则 取决 于 程序 本 身 的 设计 。 有 兴趣 的 读者 可 以 研究 下 Android 中 采用 
的 数据 库 一 一 sqlite。 


下 面 我 们 看 看 MediaProvider 是 如 何 创建 这 两 个 数据 库 的 : 


/*packages/providers/mediaprovider/src/com/android/provider 
/* 这 个 函数 就 是 创建 数据 库 的 地 方 : */ 
private Uri attachVolume(String volume) { 








synchronized (mDatabases) { 
if (mDatabases.get(volume) != null) { 
return Uri.parse("content://media/" + volume); /*4 
要 再 重复 创建 了 。 其 中 mDatabases 是 一 个 Hi: 
DatabaseHelper。 如 果 读 者 对 Android 中 1 
楚 ， 建 议 先 看 下 官方 文档 ， 这 样 对 于 分 析 后 面 


Context context = getContext(); 
DatabaseHelper helper;// 用 于 操作 Database 的 帮助 类 
if (INTERNAL_VOLUME.equals(volume)) { 
helper = new DatabaseHelper (context, INTERNAL_DATAB 
mObjectRemovedCallback);/*% 
此 时 创建 的 db 名 称 为 INTERNAL_DATABAS 
=internal.db。 不 过 数据 库 并 不 会 马上 
有 人 使 用 时 才 会 真正 生成 ， 比 如 getReada 
} else if (EXTERNAL_VOLUME.equals(volume)) {*external 











if (Environment .isExternalStorageRemovable()) {/* 
String path = mExternalStoragePaths[0]; 
int volumeID = FileUtils.getFatVolumelId(path) ;/ 


String dbName = "external-" + Integer.toHexStri 
helper = new DatabaseHelper(context, dbName, fa 
Callback); 


mVolumeId = volumeID; 
} else {/* 这 种 情况 用 于 兼容 之 前 版 本 中 的 命名 方式 ， 代 码 省 略 */ 
} else { 
throw new IllegalArgumentException("There is no vol 











} 
mDatabases.put(volume, helper) ;// HI) €MDatabaseHelr 


return Uri.parse("content://media/" + volume); 


其 中 ，lnternal 的 数据 库 在 MediaProvider 执 行 onCreate () 时 就 会 
创建 ， 而 external. db 则 需要 在 外 部 存储 设备 存在 的 情况 下 才 有 意义 ， 
比 前 者 的 判断 条 件 复杂 一 些 。 


由 此 我 们 知道 ，MediaProvider 为 内 外 存储 设备 分 别 建立 了 两 个 数 
据 库 。 不 过 很 明显 ， 每 个 数据 库 里 还 应 该 有 若干 数量 的 Table 存 在 ， 才 
能 满足 前 面 讲解 的 各 种 数据 操作 需求 。 比 如 images，audio，video 等 类 
型 的 文件 ， 其 数据 属性 有 较 大 差异 ， 放 在 同一 张 表 中 来 实现 并 不 现实 。 
接 下 来 我 们 结合 MediaProvider 所 提供 的 查询 过 程 ， 来 分 析 其 构建 出 的 
各 种 Table 的 集合 : 


public Cursor query(Uri uri, String[] projectionIn，String select 
selectionArgs, String sort) { 
int table = URI_MATCHER.match(uri);//Step1. Jl#cTable 
List<String> prependArgs = new ArrayList<String>(); 


if (table == VERSION) {//Step2. 如 果 是 查询 版 本 号 
MatrixCursor c = new MatrixCursor(new String[] {"vers 
c.addRow(new Integer[] {getDatabaseVersion(getContext 
return c; 


Ì 


B ae helper = getDatabaseForUri(uri); 


/* 通 过 Uri 来 选择 对 应 的 数据 库 ， 只 有 两 个 选项 一 即 internal 和 external 


helper .mNumQueries++; // 查 询 计 数值 
SQLiteDatabase db = helper.getReadableDatabase(); /*Step3 





if (db == null) return null; 
SQLiteQueryBuilder gb = new SQLiteQueryBuilder(); // 数 据 库 


switch (table) { //Step4. 下 面 的 每 个 case 将 分 别 对 相应 的 表 进行 操 


case AUDIO_MEDIA_ID: 
qb.setTables("audio"); /* 设 置 要 查询 的 表 。 注 意 : 上 面 通过 U 
变量 并 不 是 数据 库 里 的 表 名 ， 大 家 不 要 
qb.appendwhere("_id=?"); /*SQL 查 询 语句 的 WHERE*/ 
prependArgs.add(uri.getPathSegments().get(3)); 
break; 
case AUDIO_MEDIA_ID_GENRES_ID: 
qb.setTables("audio_genres");/* a LÆ], AUDIO_MEDI 
AUDIO_MEDIA_ID_GENRES_ID 其 实 是 从 同一 个 表 中 查询 ， 
qb.appendwhere("_id=?"); 
prependArgs.add(uri.getPathSegments().get(5)); 
break; 
SS AERA T ab Le i) Ar HE BEA, BATT AS eR 

















} 
Cursor c = qb.query(db, projectionIn, selection, 
combine(prependArgs, selectionArgs), groupBy, nul 
/* 利 用 qb 来 发 出 查询 请 求 ， 它 会 将 上 述 设置 的 各 种 查询 条 件 合成 为 
if (c != null) { 
c.setNotificationUri(getContext().getContentResolver ( 








return c; 


Step1@query。URI_MATCHER 在 MediaProvider 创 建 之 初 就 已 经 通过 
addUR1I 添 加 了 很 多 匹配 选项 。 例 如 ，URI_MATCHER. addURI ("media", 
"*/jimages/media’, IMAGES MEDIA). 


其 中 第 一 个 参数 是 Author ity， 第 二 个 参数 是 path， 它 们 在 后 续 的 
peo te eee 最 后 一 个 参数 是 本 条 Uri 匹 配 成 功 时 


Step2@query。 得 到 当前 数据 库 的 版 本 号 。 由 此 可 见 ， 一 个 
ContentProvider 的 数据 来 源 并 不 局 限于 数据 库 本 身 。 


Step3@query。 获 取 一 个 可 读 的 Db 实例 。 如 果 之 前 这 个 数据 库 还 没 
有 创建 ， 那 么 这 时 就 需要 真正 地 去 生成 这 个 数据 库 实例 。 


Step4@query。 这 一 步 执行 数据 库 查 询 指 令 。SQ1ite 提 供 了 
SQLiteQueryBui1der 来 帮助 用 户 轻 松 地 构造 各 种 查询 参数 ， 因 而 我 们 只 


需 按 照 要 求 填写 SQLiteQueryBui 1der 的 各 项 信息 即 可 ， 最 终 的 数据 库 查 
询 操作 是 由 SQLiteQueryBui Ider. query 来 完成 的 。 


MediaProvider 部 分 的 内 容 已 介绍 完 ， 这 里 小 结 一 下 。 


e MediaProvidet 是 一 个 公共 的 “仓库 ”: 一 方面 MediaScannet 的 打 描 结 
果 将 存储 到 这 里 ; 另 一 方面 上 层 应 用 发 起 的 所 有 查询 多 媒体 文件 的 
业务 也 在 这 里 展开 。 

e MediaPtovider 维 护 了 两 个 数据库 ， 即 intefrnaldb 和 extetnal.db。 

。 每 个 数据 库 里 又 创建 了 若干 Table， 来 满足 各 种 存储 和 查询 业务 需 

e MediaPtovidet 的 Content UYi 可 以 通过 MediaStote 来 查询 。 





下 一 小 节 将 讲解 多 媒体 文件 管理 的 核心 一 一 MediaScanner。 





Med i aScanner 


13.11.3 ”多 媒体 文件 管理 中 的 “生产 者 ” 


MediaScanner 在 整个 多 媒体 文件 管理 中 扮演 了 “生产 者 ”的 角色 。 
E ee ee 
Ja f 


通过 之 前 的 了 解 ， 我 们 知道 MediaProvider 中 的 数据 库 分 为 内 部 和 
外 部 两 种 。 这 说 明 在 扫描 阶段 ，MediaScanner 也 会 区 分 对 待 这 两 种 存储 
设备 。 本 小 节 将 围绕 以 下 几 个 问题 点 展开 : 


e MediaScanner WY 44 48 EY AIL 
e MediaScanner by H 4H XT & ; 
e MediaScannet 的 扫描 流程 。 


先 来 看 第 一 个 问题 。 前 面 曾经 提 到 过 ，WMediaScanner 由 一 个 
BroadcastReceiver (MediaScanner Receiver) 和 一 个 
Service (MediaScannerService) 组 成 ， 所 以 它 的 局 动 是 由 广播 来 触发 
的 。 目 前 MediaScanner 可 以 接收 4 种 类 型 的 广播 ， 如 下 所 示 : 


<receiver android:name="MediaScannerReceiver"> 

<intent-filter> 

<action android:name="android.intent.action.BOOT_COMPLETED" />//} 
</intent-filter> 


<intent-filter> 

<action android:name="android.intent.action.MEDIA MOUNTED" />/7/ 媒 1 

<data android:scheme="file" /> 

</intent-filter> 

<intent-filter> 

<action android:name="android.intent.action.MEDIA_UNMOUNTED" />// 

<data android:scheme="file" /> 

</intent-filter> 

<intent-filter> 

<action android:name="android.intent.action.MEDIA_SCANNER_SCAN_FI 
// 序 主动 

<data android:scheme="file" /> 

</intent-filter> 

</receiver> 


剩余 的 两 个 问题 我 们 将 通过 分 析 上 述 其 中 一 个 广播 触发 流程 
(android. intent. action. MEDIA MOUNTED) 来 一 并 解决 。 


当 MediaScannerReceiver 接 收 到 MEDIA_MOUNTED 的 广播 后 ， 其 首先 
要 对 这 个 广播 信息 进行 初步 处 理 ， 然 后 决定 是 否 启 动 
MediaScannerService。 源 代码 如 下 : 


/*packages/providers/mediaprovider/src/com/android/provider 
Receiver.java*/ 
public void onReceive(Context context, Intent intent) { 
final String action = intent.getAction(); 
final Uri uri = intent.getData(); 
if (Intent.ACTION_BOOT_COMPLETED.equals(action)) {// 开 机 时 
Scan(context，MediaProvider .INTERNAL_VOLUME ) ; 
scan(context, MediaProvider .EXTERNAL_VOLUME) ; 
} else {// 其 他 类 型 广播 的 处 理 
if (uri.getScheme().equals("file")) {// 其 余 广播 的 scheme 
String path = uri.getPath(); 
String externalStoragePath = Environment.getExter 
getPath( ) ;// 得 到 系统 当前 苍 
if (Intent.ACTION_MEDIA_MOUNTED.equals(action)) { 
scan(context, MediaProvider .EXTERNAL_VOLUME) ; 
} else if (Intent.ACTION_MEDIA_SCANNER_SCAN_FILE. 
path != null && path.startsWith(externalSt 
scanFile(context, path) ;// 扫 描 某 个 文件 









































这 个 函数 中 出 现 了 两 个 分 支 ， 即 scan () 和 scanFile 0 。 它 们 的 工作 
大 同 小 异 ， 其 中 scan () 在 启动 MediaScannerService 的 Intent 里 加 入 了 
一 个 Extra 数 据 。 具 体 如 下 所 示 : 


args.putString("volume", volume); 


而 scanFile 0 则 加 入 另 一 名 称 的 Extra 信 息 : 


args.putString("filepath", path); 


这 样 在 启动 了 MediaScannerService 后 ， 它 会 做 区 分 处 理 
(MediaScannerService 并 不 是 在 启动 后 就 直接 处 理 扫描 请 求 的 。 它 首 
先 会 创建 一 个 新 线程 ， 然 后 通过 SendMessage () 将 这 些 请 求 发 给 新 线程 
处 理 。 这 样 做 是 遵循 了 “主线 程 不 做 费时 操作 ”的 原则 ) : 


/*packages/providers/mediaprovider/src/com/android/providers/medi 
public void handleMessage(Message msg) 


Bundle arguments = (Bundle) msg.obj; 
String filePath = arguments.getString("filepath"); 
try { 
if (filePath != null) { // ACTION_MEDIA_SCANNER_SCAN_FILE 
IBinder binder = arguments.getIBinder("listener") ; 
IMediaScannerListener listener = (binder == null ? null : 
IMediaScannerListener.Stub.asInterface(binder) ); 
Uri uri = null; 
try { 
uri = scanFile(filePath, arguments.getString( "mim 
} catch (Exception e) { 
Log.e(TAG, "Exception scanning file", e); 


if (listener != null) { 
listener.scanCompleted(filePath, uri); 


} 

} else { 
String volume = arguments.getString("volume" 
String[] directories = null; // 需 要 扫描 的 目录 将 

















if (MediaProvider.INTERNAL VOLUME.equals(vol 
directories = new String[] { 
Environment.getRootDirectory() + "/ 
/* 内 部 存储 设备 ， 只 扫描 media 目 录 */ 














}; 


else if (MediaProvider .EXTERNAL_VOLUME.equal 


directories = mExternalStoragePaths; 


/外 部 存储 设备 的 扫描 目录 */ 














小 
if (directories != null) 4.. 
scan(directories, volume); 


} 
} catch (Exception e) { 
Log.e(TAG, "Exception in handleMessage", e); 








} 
stopSelf(msg.arg1); // 扫 描 结束 后 ， 退 出 service 











通过 上 面 代码 段 的 分 析 ， 可 能 有 的 读者 会 问 ， 系 统 到 底 支 持 几 个 外 
部 存储 设备 的 扫描 昵 。 也 就 是 说 ， 如 果 一 台 租 入 式 系 统 有 多 个 可 移 除 存 
储 设 备 〈 比 如 既 支 持 SD 卡 ， 又 支持 U 盘 ， 这 种 情况 很 常见 ) ， 那 么 能 否 
保证 这 些 存储 器 的 多 媒体 内 容 都 被 扫描 到 。 


我 们 来 总 结 下 系统 对 几 个 广播 事件 的 处 理 过 程 就 明白 了 ， 如 图 13- 
39 所 示 。 


aS Same MediaScanner 
| 


ACTION BOOT COMPLETED | 


ScanDirectory 


\ | À 
( “volume” ， ( “systemmedia” » 


“internal” ) “intemal” ) 





“extemal” ) 
\ 








/mntisdeard 
ACTION. MEDIA. MOUNTED 
StartService ScanDirectory 


\ A 
G, " F Rages i 
(volume (mExtemalStoragePaths, com android internal R.xml storage list 
extemal” ) “external” 


y 


(path, “externa 
mime Type) 








全 图 13-39 MediaScannet 对 3 种 广播 的 处 理 流 程 图 
e ACTION _BOOT_COMPLETED 


扫描 内 外 部 存储 设备 ， 路 径 分 别 为 “/system/media” 和 
mExternalStoragePaths 指 定 的 目录 。 


e ACTION_MEDIA_MOUNTED 


扫描 的 是 外 部 存储 设备 ， 具 体 路 径 是 由 StorageManager. 
ae ()—>MountService. getVolumeList () 取得 的 ， 而 后 者 又 
通过 解析 com. android. internal.R. xml. storage_1ist 文 件 来 获取 
的 ， 当前 storage_1ist 中 只 有 “/mnt/sdcard” 一 个 路 径 。 


e ACTION_MEDIA_SCANNER_SCAN_FILE 


是 应 用 程序 产生 了 一 个 新 的 多 媒体 文件 后 ， 发 出 请 求 让 系统 重 
新 扫描 ， 这 个 新 的 文件 就 能 被 其 他 用 户 看 到 了 。 


由 此 可 见 ， 当 前 Android 系 统 中 并 没有 处 理 多 种 外 部 存储 设备 的 情 
况 。 如 果 开 发 者 有 这 方面 的 需求 ， 可 以 尝试 修改 MediaScannerReceiver 
的 扫描 策略 。 


第 3 篇 
应 用 原理 骗 


操作 系统 对 于 用 户 来 说 最 大 的 价值 就 体现 在 应 用 程序 中 一 一 无 论 是 
Windows、i0S 还 是 Android， 生 态 系 统 都 无 一 不 是 建立 在 相当 规模 数量 
的 应 用 程序 上 。 因 而 如 何 为 APK 应 用 提供 高 效 的 开发 、 调 试 与 发 布 机 
制 ; 并 针对 研发 中 的 常见 问题 提供 统一 的 解决 方案 ， 是 保证 Android 系 
统 “ 长 盛 不 误 ” 的 法 宝 。 


阅读 本 篇 内 容 ， 和 希望 读 者 已 经 清楚 Android 应 用 程序 的 开发 流程 以 
及 常用 控件 、 布 局 的 使 用 。 做 到 这 一 点 并 不 难 一 一 只 要 依照 Android 的 
SDK 向 导 尝 试 建立 一 个 “He11oWor1d” 入 门 级 应 用 ， 然 后 加 入 一 个 想 实 
现 的 功能 ， 如 使 用 MediaPlayer 类 来 完成 简易 的 音乐 播放 器 即 可 。 
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第 22 章 Android 安 全 机 制 透 析 


Intent 的 匹配 规则 


写 过 Android 应 用 程序 的 开发 者 对 1ntent 一 定 不 陌生 。 从 字面 来 
看 ，lntent 是 “意愿 ”“ 意 图 ” 这 个 名 称 很 好 地 表达 了 1ntent 设 计 
Bay “WR” o WRitBinder SAA “BRT” , AAlntentH 
是 系统 判断 需要 在 哪 两 个 进程 间 建 立 Binder 关 联 的 重要 考量 因素 。 


打 个 比方 ，“ 婚 介 所 ” (Android) 在 匹配 一 对 新 人 〈 进 程 ) 时 ， 
假设 女方 的 要 求 (intent) 是 “年 龄 在 30 岁 以 下 ， 有 房 ， 有 车 ”， 那 
么 “媒人 “” 融 需要 从 一 堆 资料 中 找到 年 纪 不 超过 30 并 且 有 房 有 车 的 男 
士 。 如 果 恰 好 有 多 个 目标 对 象 同 时 满足 要 求 怎么 办 呢 ? 有 两 种 选择 : 


。 由 系统 自动 按 某 种 优先 级 进行 比较 ， 如 有 房 有 车 的 ， 且 又 长 得 昨 
的 ， 那 么 就 可 以 择优 录取 ; 
。 或 者 把 这 些 资 料 都 列 出 来 ， 由 女生 自己 来 选择 。 


后 一 种 方式 比较 民主 ， 因 为 “ 落 卜 青 菜 ， 各 有 所 爱 ”， 我 们 确实 没 
有 办 法 准确 知道 每 个 人 的 喜好 一 一 这 也 是 Android 系 统 采用 的 解决 方 
法 。 当 系统 匹配 出 有 多 个 目标 进程 符合 Intent 的 “意愿 ”时 ， 它 会 弹出 
提示 框 让 用 户 自己 选择 。 


Intent 并 不 是 某 个 组 件 〈 如 Activity) 专用 的 ， 它 所 承载 的 “ 意 
愿 ” 可 以 来 源 于 多 种 发 起 者 。 也 就 是 说 ， 上 面 的 “婚介 所 ” 既 可 以 为 女 
生 提 供 寻 找 优秀 男士 的 服务 ， 也 可 以 为 男生 找寻 合适 的 另 一 半 “ 奋 线 拱 
桥 ”。 不 管 发 起 方 是 谁 ， 目 标 对 象 又 是 谁 ， 他 们 所 采用 的 “意愿 ”格式 
都 个 会 发 生 本质 的 改变 ， 只 不 过 在 条 件 的 填写 上 有 所 不 同 罢 了 。 





14.1 lntent 属 性 


在 Android 系 统 的 设计 中 ，1ntent 可 以 被 应 用 于 除 ContentProvider 
外 的 其 他 3 种 组 件 〈 即 Activity、Service 和 和 BroadcastReceiver) 。 
此 ，lntent 的 属性 定义 一 定 要 有 共通 性 。 下 面 我 们 来 具体 看 看 它 有 哪些 
可 选 属 性 。 


e Component Name 


Intent 可 以 被 分 为 两 类 ， 即 显 性 (Explicit Intents) 和 隐 性 
(Implicit Intents) 。 如 果 我 们 在 Intent 中 特别 指定 了 目标 方 
的 “Component Name”， 比 
如 : “com. example. project.HelloActivity” ; 同时 指定 它 所 在 的 
PackageName， 如 “com. example. project”， 那 么 系统 就 会 直接 将 此 
Intent 发 往 这 个 特定 的 应 用 ， 而 不 需要 做 额外 的 匹配 工作 。 举 个 例子 ， 
如 果 女 方 的 择偶 要 求 规定 男方 的 名 字 就 得 叫 作 “ 某 某 人 ”， 且 带 有 详细 
的 居住 地 址 (这 样 才 能 唯一 确定 一 个 人 ， 因 为 同名 的 人 肯定 是 存在 
AY) ， 那 么 婚介 所 的 工作 就 简单 了 ， 直 接 约见 住 在 这 一 地 址 的 叫 作 “ 某 
某 人 ”的 男生 便 可 。 当 然 这 种 情况 比较 少见 ， 因 为 它 降低 了 女方 的 可 选 
择 性 ， 而 且 前 提 是 女生 事先 就 已 经 认识 这 位 男士 。 如 果 一 个 应 用 程序 通 
过 这 种 方式 显 性 调用 另 一 个 应 用 进程 ， 多 半 是 这 两 个 应 用 程序 同属 于 一 
家 研发 公司 ， 或 者 是 同一 进程 中 的 两 个 组 件 。 


e Category 


Category 是 “种 类 ”的 意思 ， 它 将 Intent 从 大 的 方向 上 进行 了 区 分 
和 归 类 。 如 果 说 上 面 的 Component Name 是 某 人 的 名 字 ， 那 么 Category 就 
好 比 国籍 。Android 系 统 中 已 经 预 设 了 一 些 “ 国 家 ”， 我 们 摘录 其 中 的 
部 分 核心 元 素 。 另 外 ， 由 于 Intent 的 所 有 属性 值 实际 上 都 只 是 一 串 字 
符 ， 因 而 是 可 以 自 定义 的 。 我 们 从 它 的 addCategory (String) 方 法 的 入 
参 也 可 以 推测 到 这 点 ， 如 表 14-1 所 示 。 


表 14-1 系统 预 设 的 Category 节选) 





PT 





目标 方 能 解析 并 正确 显示 网 页 链 
CATEGORY_BROWSABLE PPT TE HIAR, wK, E- 
mail 等 





CATEGORY_SAMPLE_CODE| 这 个 应 用 程序 是 一 个 Sample 
CATEGORY_TEST 这 个 应 用 程序 将 被 当成 测试 使 用 


这 个 应 用 程序 是 系统 局 动 后 的 第 
CATEGORY_HOME 一 个 应 用 ， 即 Launcher 


这 个 应 用 程序 可 以 通过 点 击 
Launcher 中 的 程序 图 标 来 启动 


CATEGORY_PREFERENCE | 这 个 应 用 程序 是 preference panel 





CATEGORY_LAUNCHER 











e Action 


动作 。 表 明 要 做 什么 ， 或 者 什么 事件 发 生 了 常用 于 广播 的 情况 。 
比如 设备 开机 时 会 有 系统 广播 发 出 ， 如 果 应 用 程序 希望 实现 开机 自 局 
动 ， 就 可 以 监听 这 个 广播 ) 。 和 Category 一 样 ， 用 户 也 可 以 自 定义 一 项 
唯一 的 Action， 如 “com. ThinkinglnAndroid. action. example”。 表 
14-2 是 Android 系 统 中 预定 义 的 部 分 常见 Action， 读 者 可 以 参考 一 个 。 


表 14-2 系统 预 设 的 Action (节选 ) 


名 望 启动 一 个 可 以 拨打 电话 
的 Activity 












ACTION_CALL 





| | 


| | 
希望 启动 一 个 提供 编辑 功能 
ACTION_EDIT 的 Activity， 通 常 是 和 其 他 属 
性 配合 使 用 
启动 的 Activity 是 其 应 用 程序 
启动 的 Activity 可 以 与 服务 器 


从 这 一 项 开始 到 表格 末尾 的 
ACTION 都 属于 “事件 ” 通 
， 它 们 面 回 Broadcast 组 





ACTION_BATTERY_LOW 


ACTION_BATTERY_LOW 
JE 5 FELT FEL ee (ERY Ac HH) 


ACTION _SCREEN_ON 屏幕 开启 时 发 出 








e Data 


打 个 比方 ， 如 果 上 面 的 Action 中 表明 了 某 人 去 公安 局 出 入 境 处 “办 
理 签证 ”的 “动作 ”， 那 么 这 里 的 Data 就 作为 “签证 ”业务 的 补充 材料 
一 一 比如 这 个 人 的 名 字 、 身 份 证件 等 。 所 以 ，Action 理 论 上 是 围绕 Data 


提供 的 数据 来 开展 业务 的 。 当 然 也 有 不 需要 Data 补 充 信息 的 情况 ， 如 在 
ACTION_CALL 的 情况 下 ， 电 话 号 码 是 必须 作为 Data 来 传递 的 ; 而 针对 
Broadcast (如 ACTION_SCREEN_ON) 组 件 的 Action， 它 们 本 身 就 列 含 了 
足够 的 信息 ， 因 而 不 需要 Data 的 支持 。 


不 同 的 Action， 其 对 应 的 Data 格 式 会 有 所 差异 ， 我 们 在 下 一 小 证 的 
匹配 过 程 中 再 进一步 讲解 。 


e Extras 


Extras 可 以 理解 为 Extra Data， 它 是 对 上 面 Data 属 性 的 补充 。 不 过 
两 者 在 数据 的 格式 上 有 明显 区 别 。Data 采 用 了 类 似 scheme://uri 的 表达 
方式 ; 而 Extras 则 是 一 种 键 值 对 实现 。 它 们 在 表达 不 同 场景 的 数据 时 有 
各 自 的 优势 ， 使 用 者 应 该 “具体 问题 具体 分 析 ”。 发 送 万 通过 一 系列 
putXXX () 方法 将 键 值 对 存 入 1ntent 中 ， 然 后 接收 方 就 可 以 用 相对 应 的 
getXXX () 来 获取 到 这 些 Extra 数 据 。 这 些 方法 的 内 部 会 维护 一 个 Bundle 
对 象 来 保证 进程 间 数 据 的 准确 传输 。 


e Flags 


Flags 和 Activity 中 的 LaunchMode 功 能 基本 相同 ， 它 规定 了 系统 如 
何 去 启 动 一 个 Activity (比如 指定 即将 启动 的 Activity 应 该 属于 哪 一 个 
Task) 。 举 个 例子 ， 如 果 一 开始 Task 栈 从 下 往 上 的 顺序 是 A-B-C， 随 后 C 
通过 带 有 Flag 为 FLLAG ACTIVITY CLEAR TOP 的 1ntent 来 启动 另 一 个 
Activity。 如 果 该 Activity 在 栈 中 已 经 存在 ， 比 如 说 是 B， 那 么 启动 后 
的 Task 栈 就 变 成 了 A-B; 否则 该 Activity 直 接 入 栈 ， 而 不 会 先 清理 栈 
] 贝 。 


14.2 lntent 的 匹配 规则 


Intent 是 和 Intent-fi1ter 配 套 使 用 的 。 具 体 而 言 ，Intent-filter 
是 每 个 组 件 的 属性 标签 ， 它 们 在 AndroidManifest. xml BARR RG 
经 “ 贴 上 ”了 。 而 Intent 则 是 程序 运行 过 程 中 产生 的 实时 “需求 ”。 系 
统 接收 到 这 些 请 求 后 与 现 有 的 Intent-filter 进 行 匹 配 ， 然 后 选择 最 合 
适 的 组 件 元 素 以 响应 。 


还 以 前 述 的 “婚介 所 ”为 例子 ，Intent 代 表 了 女生 的 择偶 意愿 ， 而 
Intent-filter 则 是 众 男士 的 属性 描述 年 龄 、 长 相 、 收 入 等 。 


图 14-1 描 述 了 广播 BroadcastReceiver 的 匹配 流程 ， 其 他 组 件 也 类 
似 。 





i 


onRecelve( 





全 图 14-1 Broadcast 匹 配 流程 图 
从 图 中 可 以 看 到 ，lntent 的 典型 匹配 过 程 包括 如 下 几 个 步骤 。 
Intent 匹 配 流程 步骤 1: 组 件 注册 


当 应 用 程序 安装 到 系统 中 时 ，Android 会 通过 扫描 它 的 


AndroidManifest 文 件 来 得 到 一 系列 信息 一 一 这 其 中 就 包括 了 它 的 
<intent-filter>; 而 且 系 统 还 会 根据 组 件 的 不 同 进 行 相应 的 细 化 归 
类 。 比 如 Activity 和 Service， 它 们 响应 lntent 的 场合 是 不 同 的 《前 者 
festartActivity, 后 者 则 是 startService) 。 换 句 话说 ， 当 某 人 调用 
JSstartActivityla, MRAZ 计 只 需 在 所 有 Activity 中 做 匹配 即 可 ， 而 
不 应 该 再 去 考虑 Service 中 的 ntent- filter. 


e idManifest 中 静态 注册 外 ，BroadcastReceiver 还 可 以 
在 程序 运 过 程 中 进行 动态 注册 o 


这 两 种 方式 的 区 别 如 下 : 
静态 RS J. 注册 


所 谓 静 态 ， 即 不 是 在 运行 过 程 中 执行 的 。 应 用 程序 事先 将 Intent- 
filter 书 写 到 AndroidManifest 文 件 中 。 


范例 如 下 : 


<application android:icon="@drawable/icon" android:label="@string 
<activity android:name=".MainActivity"android: label="@string/app_ 
<intent-filter> 
<action android:name="android.intent.action.MAIN" /> 
<category android:name="android.intent.category.LAUNCHER" /> 
</intent-filter> 
</activity> 
<receiver android:name="Receiveri">#receiver + 
<intent-filter> # 用 intent-filLlter 来 匹配 一 个 感 兴趣 的 广播 
<action android:name="android.intent.action.BOOT_COMPLE 
</intent-filter> 
</receiver> 
<receiver android:name="Receiver2"> # 系 统 对 应 用 进程 注册 的 filter 个 数 没 ; 
<intent-filter> 
<action android:name="android.intent.action. BATTERY_LO 
</intent-filter> 
</receiver> 
</application> 


。 动态 注册 


动态 是 指 注册 操作 发 生 在 程序 运行 过 程 中 。 这 种 注册 方式 的 典型 范 
例如 下 所 示 : 











IntentFilter filter = new IntentFilter("android.intent.action.BOO 
DynamicBroadcastReceiver br = new DynamicBroadcastReceiver(); 
registerReceiver(new DynamicBroadcastReceiver(), filter) ;//aaiEH 


class DynamicBroadcastReceiver extends BroadcastReceiver//4 Broa 


public void onReceive(Context context, Intent intent) // 当 匹配 

{ 
//Intent 是 通过 sendBroadcast 发 送出 来 的 
if(android.intent.action.BOOT_COMPLETED.equals(intent.get. 
{..//// 相 应 处 理 
} 
else 
{...//// 其 他 处 理 
} 























Intent 匹 配 流程 步骤 2: 发 起 方 主动 向 系统 提供 Intent 


一 步 是 在 程序 运行 过 程 中 发 生 的 ， 此 时 系统 已 经 掌握 了 所 有 组 件 
on filter>》 信 息 。 发 起 万 根据 自己 的 需求 填写 1ntent， 并 按照 
目标 方 是 Activity，Service 还 是 BroadcastReceiver 来 调用 对 应 的 函 
数 。 如 下 所 示 : 


Activity—*}startActivity(); 
Service -对 应 startService( ); 
BroadcastReceiver ,对 应 sendBroadcast(); 


MZA ENE, AA 会 户 格 区 分 对 待 这 些 组 件 分 类 。 所 以 利用 
startActivity 0 是 绝对 不可 能 启动 Service 的 即便 1ntent 和 
intent-filter 能 成 功 匹 配 。 


Intent 匹 配 流程 步骤 3: 系统 将 Intent 和 对 应 组 件 类 型 
(Activity, ao 里 所 有 的 intent-filter 进 行 匹 配 ， 以 寻找 最 
佳 的 结果 。 


这 是 整个 匹配 流程 中 的 核心 。 前 面 说 过 ，1ntent 分 为 显 性 和 隐 性 两 
种 。 如 果 是 显 性 的 情况 就 不 需要 做 匹配 了 ， 直 接 根据 Intent 中 的 
Component Name 来 启动 目标 组 件 〈 即 便 这 个 组 件 没 有 声明 任何 intent- 
filter) 。 所 以 ， 下 面 我 们 以 隐 性 1ntent 为 例 来 讲解 匹配 的 规则 。 





读者 在 学 习 的 过 程 中 也 可 以 和 下 一 章节 的 “资源 最 佳 匹 配 过 程 ” 进 
行 比较 ， 以 加 深 理解 。 总 的 来 说 ，Intent 的 最 终 匹 配 结果 可 以 是 多 个 ， 
而 资源 匹配 则 只 会 有 一 个 胜出 者 。 


影响 Intent 匹 配 规则 的 只 有 3 个 关键 因素 ， 即 : 


e Category; 
e Action; 


。 Data (URI 和 数据 类 型 都 要 同时 匹配 ) 。 


而 其 余 两 个 属性 Extras 和 Flags 则 只 有 在 选中 的 组 件 运行 后 才能 起 
作用 。 和 资源 匹配 不 同 的 是 ， 一 个 组 件 可 以 同时 声明 多 个 intent- 
filter。 而 在 匹配 过 程 中 ， 只 要 它 包 含 的 任何 一 个 filter 通 过 了 测试 ， 
它 就 会 被 选中 。 如 果 以 “身份 ”来 比喻 一 个 组 件 ， 这 相当 于 它 可 以 同时 
拥有 多 个 国籍 (Category) ， 或 者 承担 多 份 工 作 (Action， 如 在 中 国 是 
教师 ， 在 美国 是 牧师 ， 这 是 有 可 能 的 ) ， 以 及 每 份 工作 所 包含 的 数据 
(Data) 不 同 。 在 匹配 测试 中 ， 系 统 遵循 “ 子 集 ” 的 概念 。 换 句 话说 ， 
Intent 中 的 3 个 关键 因素 至 少 要 是 该 组 件 所 包含 的 其 中 一 个 intent- 
filter 的 子 集 (Data 有 点 特殊 ， 下 面 有 详细 解释 ) ， 才 能 通过 验证 ， 如 
图 14-2 所 示 。 


Component | 
| 
intent-fiter! 


必须 是 其中 一 个 


lr 的 了 信 | 





全 图 14-2  Intent#elIntent-filters 


图 中 有 几 个 地 方 需要 向 读者 解释 一 下 。 


e 每 个 Component (Activity, Service, BroadcastReceiver) 都 可 以 有 老 
干 个 intent-filter。 这 和 资源 匹配 不 同 ， 因 为 每 种 资源 只 能 有 一 种 标 
KE 
影响 匹配 的 只 有 Category、Action 和 Data， 不 包括 Extras 和 Flags。 

每 个 fillter 里 的 上 述 3 种 属性 都 可 以 不 是 唯一 的 (因此 我 们 在 图 中 标 
注 的 是 复数 形式 ) ， 可 以 参照 下 面 的 例子 。 

o 匹配 时 ，Intent 中 的 3 种 属性 都 需要 通过 测试 。 接 下 来 ， 我 们 逐个 分 

析 各 关键 因素 在 匹配 时 采用 的 详细 规则 。 








Category 测 试 : 


Intent 中 的 Category 需 要 在 filter 中 找到 完全 匹配 的 项 ， 才 能 通过 
测试 。 有 的 读者 可 能 会 问 : 那 如 果 1ntent 中 不 指定 任何 Category， 是 不 
是 一 定 能 通过 检查 ? 理论 上 确实 是 这 样 的 。 不 过 Android 系 统 已 经 预料 
到 这 种 情况 ， 因 而 这 里 有 个 特殊 的 地 方 需 要 注意 一 一 如 果 Intent 中 不 指 
定 任何 Category， 系 统 会 自动 为 其 添加 一 
个 “android. intent. category. DEFAULT” 。 这 也 就 是 想 接 收 隐 性 
Intent 的 filter 里 一 般 都 要 添加 一 个 DEFAULT 类 型 category 的 原因 。 当 
然 ， 如 果 Fi lter 里 已 经 带 
有 “android. intent. action. MAIN” JA “android. intent. category. LAL 
就 可 以 不 用 再 另外 书写 DEFAULT 了 ， 这 是 一 个 例外 。 


Action 测 试 : 
Action 的 匹配 相对 简单 ， 概 括 起 来 只 有 3 点 。 


。 如 果 filtet 没 有 任何 action， 那 么 所 有 intent 都 无 法 通过 测试 。 

e 如 果 filtet 中 的 action 不 为 空 ， 那 么 intent 中 不 带 action 的 fltetr 可 以 通过 
这 项 属性 测试 。 

e 如 果 filtet 中 的 action 不 为 空 ， 且 intent 中 的 action 也 不 为 空 ， 那 么 后 者 
必须 是 前 者 的 子 集 才 能 通过 测试 。 读 者 可 以 参见 下 面 的 Note Pad fl 
子 以 帮助 理解 。 


Data 测 试 : 





3 项 属性 测试 中 最 复杂 的 是 Data 检 验 ，Data 的 内 容 通常 包括 两 部 
Ia 


e MIME Type 


Multipurpose Internet Mail Extensions (MIME) 最早 是 电子 邮 
件 协议 SMTP (RFC 2046) 中 所 规定 的 Internet Email 的 文件 格式 类 型 ， 
后 来 逐渐 被 运用 于 其 他 多 种 互联 网 协议 〈 比 如 HTTP、RTP 等 ) PF. ER 
两 部 分 组 成 ， 即 主 类 型 (type) 和 子 类 型 (subtype) ， 中 间 以 “/” 分 
隅 。 

MIMEType 的 目的 很 简单 ， 就 是 指明 某 段 数据 是 什么 格式 类 型 ， 以 保 
证 程序 能 正确 解析 处 理 。 比 如 电子 邮件 中 的 附件 ， 如 果 不 特别 说 明 ， 接 
收 方 客户 端 就 没 办 法 知道 它们 是 图 片 、 文 本 还 是 应 用 程序 。 这 样 的 结果 
就 是 用 户 找 不 到 合适 的 途径 来 对 附件 进行 解析 。 国 际 标准 中 已 经 预 设 了 
很 多 常见 的 文件 类 型 ， 举 例如 下 。 


e Application 


application/javascript ##Javascr ipti% #ECMAScr ipt 类 型 


application/pdf ##Portable Document Format 
application/zip H#ZIP HY 

e Audio 
aud io/mp4 ##mp4 音 频 文 件 
audi o/mpeg ##MP3 或 者 其 他 MPEG 音 频 
audio/ogg ##0gg Vorbis，Speex 等 

e Video 
video/mp4 ##MP4 视 频 文 件 


video/quicktime ##QuickTime 视 频 


video/ogg ##0gg Theora 等 视频 


e Text 
text/htm| ##Htm| 文 件 
text/xml ##Xm | 文件 
text/plain ## 文 本 文件 
e Image 
image/gif ##Gif 文 件 
image/ jpeg ##JPEG 文 件 
image/png ##PNG 文 件 


另外 ，type 和 subtype 中 以 x- 开 头 的 属于 非 标准 格式 〈 未 向 1ANA 注 
iit) ; 而 subtype 中 以 vnd 开 头 的 则 是 厂商 自 定 义 的 〈vendor- 


specific) 。 


比如 : 

application/vnd. oasis. opendocument. text ##0penDocument 
文本 

app | ication/vnd. ms-excel #H#Microsoft 
Exce | 文件 

application/x-latex ##LaTeX 文 件 

audio/x-caf ##App le 公司 
的 CAF 音 频 文件 


Android 系 统 中 也 有 不 少 自 定义 的 类 型 ， 在 后 面 的 例子 中 会 看 到 。 


e URI 


URI (Uniform resource identifier) 是 某 种 资源 的 全 球 唯 一 定位 
标志 ， 因 而 通常 被 应 用 于 网 络 环境 中 ， 格 式 如 图 14-3 所 示 。 





URIAvthority 


A 414-3 URI 的 格式 


其 中 ，scheme 不 仅 包 括 了 传统 的 “http” 等 网 络 协议 ， 还 
有 “content” 来 表示 本 地 ContentProvider 所 提供 的 数据 。 如 图 所 
示 ，“host” 是 主机 的 名 称 ，“port” 指 明 通信 的 端口 ， 它 们 统称 
为 “Authority”; 而 且 如 果 host 不 存在 ， 后 面 的 端口 号 也 会 被 忽略 。 
最 后 一 部 分 是 文件 的 路 径 ， 它 是 该 资源 在 host 中 的 具体 位 置 。 


哩 然 我 们 允许 UR1 中 有 部 分 信息 缺失 的 情况 ， 但 要 特别 注意 它们 之 
间 并 不 是 完全 独立 的 一 一 如 果 scheme 不 指定 ， 则 author ity 就 没有 意 
SZ; 同样 ， 如 果 scheme 和 author ity 不 指定 ， 那 么 path 也 没有 意义 。 所 
有 元 素 组 合 后 构成 了 一 条 完整 的 UR1， 比 如 : 


content://com.google.provider .NotePad/notes 
content://com.example.project:200/folder/subfolder/etc 


了 解 了 Data 中 的 组 成 元 素 后 ， 我 们 再 来 具体 看 看 它 的 匹配 流程 。 
Data 和 上 面 的 Category 和 Action 有 本 质 区 别 。 如 果 说 前 面 的 Category 和 
Action 遵 循 的 是 “intent 中 属性 必须 是 fi lter 子 集 ” 的 原则 ， 那 么 Data 
则 大 相 径 庭 一 一 只 有 filter 中 存在 的 那 部 分 属性 〈 比 如 某 fi lter 中 只 指 
定 了 mimeType， 那 么 只 匹配 mimeType) ， 才 需要 进行 匹配 。 


根据 概率 组 合 ， 具 体 有 如 下 4 种 可 能 。 
(1) Intent 中 既 没 有 指定 数据 类 型 ， 也 没有 填写 UR1。 


在 这 种 情况 下 ， 只 有 filter 中 也 同样 没有 指定 数据 和 UR1， 才 可 能 
通过 测试 。 


(2) lntent 中 没有 指定 类 型 〈 且 无 法 从 URI 中 推断 出 ) ， 但 有 
URI. 


值得 一 提 的 是 ， 数 据 类 型 有 可 能 从 UR1 中 推断 出 来 一 一 如 果 是 就 属 
于 第 四 种 情况 。 前 面 已 经 说 过 ，“ 只 有 filter 中 存在 的 那 部 分 属性 ， 才 
需要 进行 匹配 ”， 因 而 这 种 情况 下 filter 必 须 没有 指定 类 型 ， 且 1ntent 
中 的 UR1 也 符合 要 求 ， 才 可 能 通过 测试 。 


(3) Intent 中 只 指定 了 类 型 ， 没 有 UR1 。 


这 和 上 面 的 情况 类 似 。 此 时 如 果 filter 中 也 没有 UR1， 且 1ntent 中 
指定 的 类 型 符合 要 求 ， 才 能 通过 测试 。 


(4) Intent 中 同时 指定 了 类 型 (或 可 以 从 UR1 推 断 出 ) AURI. 


这 时 类 型 和 UR1 都 必须 通过 测试 。 具 体 来 说 ， 以 filter 中 的 data 为 
主导 ， 将 其 中 存在 的 属性 逐一 与 ntent 中 的 data 进 行 比较 。 不 过 有 一 种 
特殊 情况 ， 即 fi lter 默 认 就 支持 content: 和 file: 的 scheme。 换 句 话 
说 ， 即 使 它 只 填写 了 类 型 部 分 ，UR1 中 也 会 有 这 两 个 scheme 存 在 。 


接 下 来 举 一 个 Android 官 方 文档 中 的 例子 以 帮助 大 家 加 深 理解 。 这 
个 NotePad 范 例 在 SDK 中 可 以 找到 源码 ， 它 的 intent-filter 定 义 如 下 所 
7N: 


/*<sdk>/samples/NotePad/ , AndroidManifest.xml*/ 
/* 为 了 讲解 方便 ， 下 面 我 们 给 每 个 filter 都 标注 了 序号 */ 
<manifest xmlns:android=http://schemas.android.com/apk/res/androi 
<application android:icon="@drawable/app_notes"android:1label="@st 
<provider android:name="NotePadProvider"android:authorities="com. 
<activity android:name="NotesList" android:label="@string/title_n 
<intent-filter> //NotesList-filter-1 

<action android:name="android.intent.action.MAIN" /> 

<category android:name="android.intent.category.LAUNCHER" /> 
</intent-filter> 





<intent-filter>//NotesList-filter-2 
<action android:name="android.intent.action.VIEW" /> 
<action android:name="android.intent.action.EDIT" /> 
<action android:name="android.intent.action.PICK" /> 
<category android:name="android.intent.category.DEFAULT" /> 
<data android:mimeType="vnd.android.cursor.dir/vnd.google.note" 
</intent-filter> 
<intent-filter>//NotesList -filter-3 
<action android:name="android.intent.action.GET_CONTENT" /> 
<category android:name="android.intent.category.DEFAULT" /> 
<data android:mimeType="vnd.android.cursor.item/vnd.google.note 
</intent-filter> 
</activity> 


<activity android:name="NoteEditor"android: theme="@android:style/ 
android: label="@string/title_note" > 
<intent-filter android: label="@string/resolve_edit"> //NoteEdito 
<action android:name="android.intent.action.VIEW" /> 
<action android:name="android.intent.action.EDIT" /> 
<action android:name="com.android.notepad.action.EDIT_NOTE" /> 
<category android:name="android.intent.category.DEFAULT" /> 
<data android:mimeType="vnd.android.cursor.item/vnd.google.note 
</intent-filter> 
<intent-filter> //NoteEditor -filter-2 
<action android:name="android.intent.action. INSERT" /> 
<category android:name="android.intent.category.DEFAULT" /> 
<data android:mimeType="vnd.android.cursor.dir/vnd.google.note" 
</intent-filter> 
</activity> 


<activity android:name="TitleEditor" android: label="@string/title 
android: theme="@android:style/Theme.Dialog"> 

<intent-filter android:label="@string/resolve_title"> //TitleEdi 
<action android:name="com.android.notepad.action.EDIT_TITLE" /> 
<category android:name="android.intent.category.DEFAULT" /> 
<category android:name="android.intent.category.ALTERNATIVE" /> 
<category android:name="android.intent.category.SELECTED_ALTERN 
<data android:mimeType="vnd.android.cursor.item/vnd.google.note 
</intent-filter> 

</activity> 

</application> 

</manifest> 


根据 上 面 的 AndroidManifest 文 件 ， 可 以 看 到 NotePad 共 包含 了 3 种 
Activity， 即 NotesLi st 〈 用 于 显示 已 经 保存 的 文章 ) ， 
NoteEditor 〈 用 于 编辑 文章 ) 和 TitleEditor 〈 用 于 编辑 文章 的 标 


题 ) 


o 


下 面 我 们 通过 列举 几 个 不 同 的 Intent 来 分 析 系 统 的 匹配 情况 
Intent 1: 


action: android.intent.action.MAIN 
category: android.intent.category.LAUNCHER 


Category 测 试 : 根据 子 集 原 则 ， 只 有 NotesList-filter-1 通 过 了 检 


Acti ee 依据 上 面 所 分 析 的 Act ion 测 试 第 3 点 ，NotesLi st- 
filter-1 通 过 了 检查 。 


Data 测 试 : 属于 第 一 种 情况 ， a 及 有 指定 类 型 ， 也 无 
UR1。 而 另外 ，filter 也 是 同样 的 情况 ， 因 此 根据 “只 有 filter 里 有 的 
那 部 分 属性 才 需 要 检查 ”的 原则 ， NotssList-filter-1 最 终 通 过 了 匹 
配 。 这 个 Intent1 将 对 应 NoteL ii st。 


| ntent2 : 


action: android.intent.action.VIEW 
data: content://com.google.provider .NotePad/notes 


Category 测 试 : Intent 中 没有 指定 Category， 系 统 会 自动 为 其 加 上 
DEFAULT 值 。 因 为 所 有 filter 都 写 上 了 这 个 默认 值 ， 因而 全 部 通过 测 
试 。 


Action 测 试 ， 只 有 NotesList-filter-2 和 NoteEditor-filter-1 通 
过 测试 。 


Data 测 试 : 表面 上 属于 第 二 种 情 、 Be 了 UR1 而 没有 类 型 。 
站 因而 属于 第 四 种 情 
况 。 推 断 出 的 类 型 为 "vnd. android. cursor. dir/vnd. note" (可 
以 参见 下 一 小 节 对 推断 过 程 的 源码 解析 ) ， 因 而 最 终 通过 测试 的 是 
NotesList-filter-2. 


Intent3: 


action: android.intent.action.GET_CONTENT 
data type: vnd.android.cursor.item/vnd.google.note 


Category 测 试 : 同 Intent2。 

Act ion 测 试 : 只 有 NotesList-filter-3 通 过 测试 。 

Data 测 试 : 只 有 Type， 而 没有 UR1， 属 于 第 三 种 情况 。 因 为 
NotesLi st-fi lter-3 也 是 同样 的 情况 ， 而 且 它 们 的 类 型 也 是 匹配 的 ， 
以 最 终 通过 测试 。 

Intent4: 


action: android.intent.action. INSERT 
data: content://com.google.provider .NotePad/notes 


Category 测 试 : 同 Intent2， 由 此 可 见 intent-filter 中 加 上 
DEFAULT 还 是 非常 必要 的 。 


Act ion 测 试 : 只 有 NotesEditor-filter-2 符 合 要 求 。 
Data 测 试 : 同 Intent2。 
Intent5: 


action: com.android.notepad.action.EDIT_TITLE 
data: content://com.google.provider .NotePad/notes/ID 


Category Mit: 同 Intent2。 
Action 测 试 : 只 有 TitleEditor-filter-1 符 合 要 求 。 
Data 测 试 : 同样 可 以 推断 出 类 型 ， 


即 "vnd. android. cursor. item/vnd. google. note"， 因 而 上 面 的 
TitleEditor-filter-1 最 终 通过 测试 。 


所 


14.3 ”lntent 匹 配 源码 简 析 
本 节 将 对 Intent 匹 配 过 程 所 涉及 的 核心 源码 进行 简单 的 分 析 。 
我 们 以 startActivity 为 例 ， 程 序 调用 流程 如 图 14-4 所 示 。 











ae Cont Cone some tation ioe ActivitylnentResolver | | [ntentFitter 
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全 图 14-4 AstartActivity F A Intent L feit Fz 


所 以 ， 最 终 执行 匹配 的 是 IntentFilter 中 的 match 0 函数 。 不 过 在 
这 之 前 已 经 涉及 很 多 快速 匹配 算法 优化 的 地 方 ， 若 读者 有 兴趣 可 以 自行 
阅读 中 间 过 程 的 代码 。 我 们 这 里 着 重 分 析 一 下 最 后 的 这 个 匹配 函数 : 





/*frameworks/base/core/java/android/content/IntentFilter.java*/ 
public final int match(String action, String type, String scheme, 
Set<String> categories, String logTag) { 
if (action != null && !matchAction(action)) {/* 首 先 匹 配 Acti 
matchAction ( ) 要 求 action 不 为 空 并 且 f: 
中 的 action， 否 则 返回 false 表 示 [ 匹 配 不 成 - 
return NO_MATCH_ACTION; /*Action 测 试 失败 ， 没 有 必要 再 往 下 中 

















} 
int dataMatch = matchData(type, scheme, data); /* 紧 接着 进行 
if (dataMatch < 0) {.. 
return dataMatch; 
} 


String categoryMismatch = matchCategories(categories); /* 
轮 测试 不 一 样 的 地 方 是 ， 它 


return dataMatch; /* 到 这 里 说 明 3 个 测试 都 通过 了 */ 





} 


整个 match 函 数 的 处 理 流 程 和 前 面 的 描述 一 致 ， 即 分 别 调用 
matchAction，matchData 和 matchCategor ies 来 执行 3 种 检验 测试 。 在 
match 过 程 中 只 要 有 一 轮 失 败 ， 函 数 就 会 直接 返回 错误 。 


下 面 专 门 分 析 match 中 最 复杂 的 Data 匹 配 过 程 : 


public final int matchData(String type, String scheme, Uri data 
final ArrayList&lt;String> types = mDataTypes; 
final ArrayList&lt;String> schemes = mDataSchemes; 
final ArrayList&lt;AuthorityEntry> authorities = mDataAutho 
final ArrayList&lt;PatternMatcher> paths = mDataPaths; 


int match = MATCH_CATEGORY_EMPTY; 
if (types == null && schemes == null) {/*Filter 的 type 和 URI 都 
intent 都 要 为 空 才能 匹配 成 功 。 注 意 复数 形式 的 是 filter 的 属性 ， 单 数 的 7 
return ((type == null && data == null)? 
(MATCH_CATEGORY_EMPTY+MATCH_ADJUSTMENT_NORMAL ) 























} 
if (schemes != null) {/*Filter 中 的 scheme 不 为 空 。 做 这 样子 判断 的 目 
在 ， 后 面 的 authority 也 就 没有 意义 了 */ 





if (schemes.contains(scheme != null ? scheme : "")) { 
match = MATCH_CATEGORY_SCHEME; 
} else { 


return NO_MATCH_DATA,; 


} 

if (authorities != null) {//authority 不 为 空 
int authMatch = matchDataAuthority(data); /*JlAcAuth 
if (authMatch >= 0) {/x* 只 有 在 匹配 了 Authority 以 后 ， 下 面 日 

















if (paths == null) { 
match = authMatch; 

} else if (hasDataPath(data.getPath())) { 
match = MATCH_CATEGORY_PATH; 

} else { 
return NO_MATCH_DATA; 





} 
} else { 
return NO _MATCH_DATA; 
; } 
} else {/* 这 就 是 我 们 在 上 一 小 节 的 data 测 试 中 提 到 的 一 种 特殊 情况 ， 即 系统 
和 file 两 种 Scheme*/ 
if (scheme != null && !"".equals(scheme) && !"content". 


&& !"file".equals (scheme)) { 
return NO_MATCH_DATA; 


} 


} 
if (types != null) {/* 匹 配 类 型 ， 过程 和 上 面 URI 是 类 似 的 */ 
if (findMimeType(type)) { 
match = MATCH_CATEGORY_TYPE; 
} else { 
return NO_MATCH_TYPE; 








} 
} else { 
if (type != null) { 
return NO_MATCH_TYPE; 
} 


return match + MATCH_ADJUSTMENT_NORMAL ; 


在 前 一 节 中 ， 我 们 提 到 当 Intent 中 只 包含 URI 时 ， 是 有 可 能 推断 出 
Type 的 。 那 么 这 个 过 程 是 在 什么 时 候 做 的 ， 为 什么 NotePad 中 
HY) “content://com. google. provider. NotePad/notes” 最 终 可 以 得 
Type= “vnd. android. cursor. dir/vnd. google. note” ? 


实际 上 对 Type 的 推断 在 startAct ivity 起 始 就 执行 了 ， 具 体 而 言 是 
在 execStartActivity 中 。 源 码 如 下 : 
/*frameworks/base/core/java/android/app/Instrumentation. java* 


public ActivityResult execStartActivity(Context who, IBinder 
token, Activity target,Intent intent, int requestCode, 


try {.. 
int result = ActivityManagerNative.getDefault() 


.StartActivity(whoThread, intent, intent.resolveType 
Resolver()), token, target != null ? target.mEmbedd 
©, null, null, options); 
checkStartActivityResult(result, intent); 
} catch (RemoteException e) { 
} 
return null; 


J 


上 述 代码 段 就 是 应 用 进程 把 startActivity 请 求 投递 给 AMS 的 地 方 ， 
其 中 的 重点 在 于 函数 将 调用 的 resolveType1fNeeded 通过 函数 名 也 


可 以 看 出 ， 它 负责 从 Intent 中 解析 出 相应 的 类 型 。 下 面 我 们 对 这 个 子 数 
做 进一步 分 析 : 





/*frameworks/base/core/java/android/content/Iintent.java*/ 


public String resolveTypeIfNeeded(ContentResolver resolver) { 
if (mComponent != null) { 


return mType; /* 如 果 已 经 指定 了 Component Name， 那 就 没 必要 再 
} 


return resolveType(resolver); 








} 


疯 数 resolveType1fNeeded 先 判断 ComponentName 是 否 为 室 ， 是 就 直 
接 返 回 结果 ， 否 则 继续 调用 如 下 方法 : 


public String resolveType(ContentResolver resolver) { 
if (mType != null) { 


return mType; // 已 经 指定 了 类 型 ， 当 然 不 需要 再 从 URI 中 推断 了 


if (mData != null) { 
if ("content".equals(mData.getScheme())) {/*URI 中 的 sch 
推断 出 类 型 。 言 下 之 意 ， 像 http7 这 种 网 络 协 
return resolver.getType(mData); /* 利 用 ContentResol 














} 
} 
return null; 


} 
由 此 可 见 ， 最 终 的 类 型 推断 是 由 ContentResolver 来 完成 的 。 即 : 


/*frameworks/base/core/java/android/content/ContentResolver. 
public final String getType(Uri url) { 
IContentProvider provider = acquireExistingProvider (url); 
ContentProvider 来 完成 解析 。 这 给 了 我 们 一 个 提示 
Provider 自 己 来 完成 的 ， 而 不 是 系统 统一 处 理 的 */ 




















if (provider != null) {//provider 存 在 ， 直 接 由 它 完成 解析 
try { 
return provider.getType(url); 
} catch (RemoteException e) { 
al | Fes ETE 
} 


} 

if (!SCHEME_CONTENT.equals(url.getScheme())) {// 又 判断 了 一 
return null; 

} 


try { 
String type = ActivityManagerNative.getDefault().getPr 


return type; 


are 








如 果 已 经 有 现成 的 Provider， 那 么 直接 由 它 来 解析 类 型 ; 如果 没 
可 用 的 Provider， 那 么 就 要 先 动用 AMS 来 找到 相对 应 的 Provider。 这 和 
startActivity 中 利用 1ntent 来 找到 Activity 类 似 一 一 这 里 是 通过 URI 来 
匹配 Content Provider。 因 为 Intent 中 的 URI 
是 “content://com. google. provider. NotePad/notes” , Authority 
是 com. google. provider. NotePad， 所 以 最 终 会 匹配 到 NotePad 这 个 
Provider。 


所 以 getType 的 核心 步骤 有 两 个 。 


(1) 根据 UR1 在 AMS 中 找到 对 应 的 Content Provider， 在 这 个 例子 
中 也 就 是 NotePadProvider。 


(2) 根据 provider 中 的 getType 0 函数 来 解析 类 型 。 


原来 绕 了 一 圈 ， 类 型 的 解析 还 是 由 应 用 程序 本 身 来 完成 的 。 这 样 的 
设计 是 合理 的 ， 因 为 它 让 应 用 程序 有 机 会 来 扩展 Type 的 解析 能 力 。 因 而 
可 以 肯定 的 是 ， 每 个 provider 都 必须 实现 getType (方法; 并 且 这 个 接 
口 还 应 该 是 抽象 的 ， 验 证 如 下 : 


public abstract class ContentProvider implements ComponentCallbac 


public abstract String getType(Uri uri); // 确 实 是 抽象 接口 


最 后 来 看 看 NotePadProvider 是 如 何 解 析 类 型 的 。 这 也 是 分 析 
Android 源 码 一 个 有 趣 的 现象 ， 很 多 时 候 答 案 就 在 眼前 : 


@Override 
public String getType(Uri uri) { 
switch (sUriMatcher.match(uri)) { 
case NOTES: 
case LIVE_FOLDER_NOTES: 
return NotePad.Notes.CONTENT_TYPE; 
case NOTE_ID: 
return NotePad.Notes.CONTENT_ITEM_TYPE; 
default: 
throw new IllegalArgumentException("Unknown URI " 
} 
} 


UriMatcher 一 共 添 加 了 3 种 模式 ， 当 
uri="content://com. google. provider. NotePad/notes" 时 ，[ 匹 配 的 类 
型 是 CONTENT TYPE ="vnd. android. cursor. dir/vnd. google. note". $R 
据 之 前 对 MIME 类 型 的 讲解 ，vnd 表 示 用 户 自 定义 的 类 型 。 


当 uri="content://com. google. provider. NotePad/notes/1D" 时 ， 
匹配 的 类 型 是 : 


CONTENT_ITEM_TYPE="vnd.android.cursor.item/vnd.google.note". 
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APK 应 用 程序 的 资源 适 配 


我 们 在 本 书 其 他 章节 中 曾经 提 过 ，Android 相 比 于 i0S 有 一 个 非常 让 
开发 者 头痛 的 问题 ， 即 市 面 上 Android 设 备 种 类 繁多 、 硬 件 配置 五 花 八 
门 。 特 别 是 层出不穷 的 屏幕 分 辩 率 和 尺寸 ， 往 往 对 一 款 应 用 程序 的 U1 界 
面 有 非常 大 的 影响 一 一 应 用 程序 在 屏幕 A 上 可 以 完美 显示 ， 而 在 屏幕 B 上 
则 可 能 是 一 团 糟 。 鉴 于 此 ， 应 用 开发 商 往往 需要 同时 适 配 多 达 上 百 款 主 
流 设 备 才 敢 将 产品 投入 市 场 ， 这 无 疑 加 大 了 研发 的 成 本 和 时 间 。 


作为 开源 工程 ，Android 无 法 像 i0S 一 样 从 本 质 上 去 规避 这 种 情况 。 
因此 ， 如 何 尽 可 能 减 小 它 所 这 来 的 影响 就 成 了 开发 人 员 首先 考虑 的 问 
题 。 这 也 是 本 章 的 目的 一 一 我 们 将 从 适 配 一 款 设备 所 要 做 的 主要 工作 入 
手 ， 结 合 Android 系 统 提 供 的 通用 适 配 方案 和 准则 ， 来 学 习 如 何在 项 目 
开发 初期 就 将 这 些 “ 烦 人 ”的 问题 掌握 在 可 控 范 围 内 。 


我 们 先 从 理论 层面 来 分 析 适 配 的 过 程 ， 如 图 15-1 所 示 。 
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全 图 15-1 设备 资源 适 配 的 通用 流程 图 





。 未知 设 











对 于 发 布 后 的 应 用 程序 而 言 ， 它 将 运行 于 什么 配置 的 硬件 设备 上 是 
一 个 未 知 数 。 比 如 一 个 APK 闸 钟 小 工具 ， 不 但 手机 用 户 可 以 下 载 使 用 ， 
平板 电脑 用 户 也 同样 可 以 去 下 载 使 用 。 


。 提取 设备 参数 


对 于 不 同 的 设备 而 言 ， 它 们 的 硬件 和 软件 参数 都 可 能 不 一 样 。 例 如 
平板 电脑 相对 于 手机 通常 屏幕 都 会 大 一 些 ， 而 且 是 模 屏 ; 即便 是 同一 款 
手机 ， 也 可 能 在 系统 软件 版 本 上 存在 差异 。 这 些 参 数 都 会 对 资源 池 的 最 
人 


。 资源 池 
资源 池 是 对 一 个 应 用 程序 所 能 提供 的 “可 选 资源 ”的 形象 称 1 
过 “最 佳 资 源 匹配 ” 应 用 程序 可 以 为 当前 设备 入 选 出 最 全 过 的 资源 。 
。 最 佳 匹配 规则 


这 是 整个 匹配 流程 的 核心 ， 也 是 最 终 仲 裁 者 。 从 应 用 程序 资源 池 中 
寻找 到 最 佳 匹 配 的 资源 ， 并 不 是 件 容易 的 事 。 我 们 将 在 本 章 后 续 小 节 对 
Android 目 前 采用 的 匹配 算法 进行 详细 分 析 。 


15.1 资源 类 型 


APK 应 用 程序 发 布 以 后 一 一 比如 通过 Android Market (2012 年 3 月 7 
日 起 更 名 为 Google Play Store) 这 样 的 开放 平台 来 提供 下 载 ， 我 们 预 
先 没 有 办 法 知晓 下 载 者 将 会 把 这 个 应 用 程序 安装 在 什么 样 的 Android 机 
器 上 。 所 以 为 了 达到 最 佳 的 适 配 效果 ， 一 方面 ， 开 发 者 需要 提供 尽 可 能 
多 的 可 选 资源 ; 另 一 方面 ，Android 系 统 本 身 也 会 根据 设备 的 配置 来 对 
应 用 程序 做 运行 时 的 优化 。 比 如 适当 地 拉 缩 图 片 以 更 好 地 适应 屏幕 ， 或 
者 选择 合适 的 layout 来 搭配 横 屏 、 竖 屏 ， 以 及 根据 系统 的 配置 来 决定 应 
用 程序 的 显示 语言 等 。 


如 果 把 Android 系 统 比 作 和 舞蹈 编排 者 ， 那 么 它 如 何 保证 “和 舞 者 ”的 
正常 演出 呢 ?” 首 先 它 需要 为 表演 者 提供 舞步 指导 ， 这 样 才 可 以 要 求 他 们 
展示 一 场 精彩 的 表演 ; 反之 ， 如 果 在 没有 弄 清楚 整 支 舞 蹈 动作 编排 的 情 
况 下 就 仓促 上 阵 ， 很 可 能 会 出 现 各 种 意 想不到 的 窒 相 。 


本 小 节 我 们 将 解释 Android 系 统 包 含 了 哪些 应 用 程序 资源 以 及 内 部 
又 是 如 何 处 理 这 些 资源 的 。 


原生 态 Android 工 程 包含 的 资源 (resource) 类 型 比较 多 ， 它 们 都 
统一 放置 在 程序 源码 的 res/ 目 录 下 。 每 种 资源 还 会 建立 自己 的 子 目 录 
因而 大 部 分 资源 的 类 型 从 它们 的 目录 名 称 上 就 可 以 知晓 。 比 如 
drawable 表 示 图 像 文 件 ，1ayout 表 示 布 局 文件 ，anim 表 示 动 画 实现 等 。 
这 些 名 称 都 是 固定 的 ， 不 允许 更 改 ， 完 整 的 列表 如 表 15-1 所 示 。 





表 15-1 Android 支持 的 资源 类 型 


pet [fe ete purt H 


Java: 
Tween E R S R.anim.filename 
| 动画 XML: 
动画 页 源 @[package: Janim/filename 
( Animation 


Java 中 : 








状态 颜色 资 Java 中 : 配色 方案 


源 R.color.filename FF FY LARS 
l 

(Color nes/Co ON XML: 程序 的 V 

State List @[package: ]color/filename KA Ba 

Resource ) FEW HR 


图 形 资源 Java 中 : 


R.drawable.filename 


( Drawable 


Resources ) XML: 


@[package: ]drawable/filename 
Java 中 : 

R.layout.filename 

XML 中 : 

@[package: Jlayout/filename 





布局 资源 
(Layout 
Resource ) 





See Java 中 : 
s5 AY 
RGM R.menu.filename a ope 
(Menu 中 KA 
Resource) SMET 
@[package:]menu.filename 
Java 中 : 
> ZA R.string.string_name, SENTSI 
字符 串 资 源 à ENTR 
(String res/values RE a 人 RFF 
Resources ) ‘P PAA 组 等 


XML 中 : 
@string/string_name 等 

Java 中 : 

R.style.stylename 

XML: 

@|[package: |style/style_name 
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fe} 、 ig 
原始 资源 pua Jie 
(Raw R.raw.filename acco) 


可 以 使 用 Resources.openRaw en 
Ni ` yA N 9 x i 
Resource) Resource 函 数 打开 此 类 资源 F, X 
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15.1.1 状态 颜色 资源 


之 所 以 称 为 “ 状 克 
个 View 对 象 的 不 同 状 克 
某 个 颜色 的 属性 ， 请 参 


状态 颜色 的 文件 结构 由 一 个 selector>， 内 驴 若 干 <item> 而 成 。 每 
个 《item> 描 述 了 一 个 View 状 态 与 某 种 颜色 的 对 应 值 : 


<?xml version="1.0" encoding="utf-8"?> 
<selector xmlns:android="http://schemas.android.com/apk/res/andro 


颜色 ” (Color State) ， 是 因为 我 们 可 以 为 某 
分 另 Ea Sa all 
a 


: 3 a 


<item 
/> 
</selector> 
其 中 , 《item> 的 声明 语法 如 下 : 
<item 
android:color="hex_color" 
andoird: [VIEW_STATE]=["true" | "false"] 


andoird: [VIEW_STATE]=["true" | "false"] 


/> 


需要 格外 注意 的 是 ， 系 统 只 会 简单 地 选择 第 一 个 符合 要 求 的 


<“item>， 而 不 是 从 众多 “item> 中 选择 一 个 最 合适 的 。 另 外 ， 即 便 第 一 个 
“item> 里 不 包含 任何 状态 poe E pa 选中 。 因 此 ， 我 们 在 编 
写 时 一 定 要 把 默认 的 值 放 在 最 后 


android:colorkh “#” 开头， 可 是 以 下 4 种 表达 形式 之 一 : 


e #AARRGGBB; 
e #RRGGBB; 
#ARGB; 
#RGB, 


目前 可 选 的 VIEW_STATE 有 以 下 几 种 类 型 。 


e android:state_pressed (被 按 下 状态 ) o 

e android:state_focused (已 获取 焦点 状态 ) 。 

android:state_selected (被 选中 状态 ， 如 一 个 tab 被 打开 时 ) o 
android:state_checkable ( 指 一 个 View 是 可 勾 选 的 ) o 
android:state_checked (View ER A2) 。 

android:state_enabled (处 于 使 能 状态 ， 即 这 个 view 可 以 接收 触摸 /点 
击 等 事件 ) 。 

e android:state_window_focused (应 用 程序 的 窗口 获得 了 焦点 ) 。 

















15.1.2 图 形 资源 
图 形 资源 (Drawable Resources) 的 定义 比较 抽象 ， 指 的 是 所 有 可 
以 被 显示 到 屏幕 上 的 图 像 ， 因 此 包含 的 类 型 比较 多 。 下 面 我 们 对 其 中 一 
些 核心 类 型 进行 解释 。 
@ Bitmap 
位 图 文件 ， 常 见 的 格式 有 . png、. jpg 和 . gif 
e Clip 


这 个 概念 被 广泛 应 用 在 图 形 图 像 处 理 中 ， 字 面 意思 是 图 像 被 剪 切 、 
裁剪 。 这 里 表达 的 是 一 个 图 形 随 着 状态 值 (0~10000) 的 变化 而 处 于 不 


同 的 被 裁剪 状态 。 比 如 ， 一 个 进度 条 视图 会 根据 进度 的 百分比 大 小 而 变 
化 。 


e Inset 


这 种 类 型 的 图 像 资源 用 于 插入 另 一 图 像 中 ， 而 且 插 入 位 置 可 以 设 
置 。 比 如 一 个 视图 需要 一 张 比 其 外 边框 小 的 背景 图 ， 就 可 以 使 用 


Inset. 
e Level List 


和 颜色 状态 资源 类 似 ，Level List 管 理 的 是 一 组 图 像 资 源 ， 每 个 图 
像 又 有 相应 的 等 级 范围 。 当 我 们 利用 setLevel () 或 者 set1lmageLevel () 
函数 传 入 所 希望 的 等 级 值 时 ， 系 统 会 选择 一 个 符合 要 求 的 图 像 。 


e Layer List 


ESADE A. CHe-ABHeARARWES. MLevel List 不 
同 的 是 这 些 图 像 会 被 全 部 显示 ， 而 且 绘 制 的 顺序 是 它们 在 列表 中 的 声明 
顺序 。 也 就 是 说 ， 列 表 中 的 最 后 一 个 元 素 会 被 显示 在 最 上 面 。Layer 
Li st 通常 可 以 用 来 产生 层 倒 效果 。 


e Nine-patch 


Android 自 定义 的 一 种 PNG 格 式 的 图 像 资源 。 它 让 图 像 在 拉 伸 时 按照 
一 定 的 规则 进行 〈 即 只 有 指定 的 “ 拉 伸 区 域 ” 会 被 拉 伸 ) ， 而 不 是 传统 
的 整 图 拉 伸 。 这 样 做 可 以 有 效 避 免 图 像 因 拉 伸 而 产生 变形 。 


e Scale 


和 C1ip Drawable 在 用 法 上 类 似 ， 用 于 定义 一 种 尺寸 大 小 随 等 级 变 
化 而 改变 的 图 形 。 


e Shape 


用 于 特定 形状 的 定义 ， 如 长 方形 、 椭 圆 形 、 环 形 等 ; 并 能 设置 其 厚 
圆 角 、 填 充 、 线 条 等 。 其 一 般 的 语法 如 下 : 


X 


度 


<?xml version="1.0" encoding="utf-8"?> 

<shape xmlns:android="http://schemas.android.com/apk/res/android" 
android:shape=["rectangle" | "oval" | "line" | "ring"] > 
<corners.../> 

<gradient.../> 

<padding.../> 

<size.../> 

<solid.../> 

<stroke.../> 

</shape> 


e State List 


这 是 我 们 在 应 用 程序 开发 中 最 常用 的 一 种 资源 ， 描 述 了 视图 在 不 同 
状态 下 的 变化 。 它 和 颜色 状态 资源 在 使 用 及 语法 上 基本 一 致 ， a AN 可 一 
个 体现 了 颜色 值 的 变化 ， 而 另 一 个 则 通常 是 背景 图 的 改变 。 


其 格式 如 下 : 


<?xml version="1.0" encoding="utf-8"?> 
<selector xmlns:android="http://schemas.android.com/apk/res/andro 


android: constantSize=["true" | "false"] 

android:dither=["true" | "false"] 

android: variablePadding=["true" | "false"] > 

<item 
android: drawable="@[ package: |drawable/drawable_resource" 
android: [VIEW_STATE]=["true" | "false"] 

/> 

</selector> 


WIT ER EAS ee POA RA ASVIEW_STATE, XBR ASA. YA 
下 是 此 资源 新 增 的 两 种 状态 : 


A) state_hovered (光标 悬浮 在 上 面 的 状态 ) 
@ state_activated (视图 对 象 被 持久 选择 的 状态 ) 


e Transition 


这 种 类 型 的 资源 包含 最 多 两 个 图 形 ， 并 实现 了 它们 之 间 的 互相 切换 
一 一 如 果 需 要 进行 前 向 切换 ， 就 使 用 startTransition() HM; RZ, 
可 以 使 用 reverseTransition() 国 数 。 


15.1.3 布局 资源 


布局 文件 定义 了 U1I 丙 面 的 框架 ， 并 且 详 细 描述 了 每 个 View 对 象 的 属 
性 和 Layout 〈 大 小 、 位 置 ) 。 


一 般 格式 如 下 : 


<?xml version="1.0" encoding="utf-8"?> 
<ViewGroup xmlns:android="http://schemas.android.com/apk/res/andr 
android: id="@[+][package: ]id/resource_name" 


android: layout_height=["dimension" | "fill_parent" | "wrap_conten 
android: layout_width=["dimension" | "fill_parent" | "wrap_content 
[ViewGroup-specific attributes] > 
<View 
android: id="@[+][package: ]id/resource_name" 
android: layout_height=["dimension" | "fill_parent" | "wrap_cont 
android: Llayout_width=["dimension" | "fill_parent" | "wrap_conte 
[View-specific attributes] > 
<requestFocus/> 
</View> 
<ViewGroup> 
<View /> 
</ViewGr oup> 
<include layout="@layout/layout_resource"/> 
</ViewGroup> 


o 最 外 围 的 元 素 可 以 是 ViewGtoup、View 或 者 mertee， 同 时 有 且 只 能 有 
一 个 顶层 元 素 。 

。 顶层 元 素 下 面 可 以 包含 者 干 其 他 元 素 ， 如 ViewGroup、View 等 。 每 
个 View 对 象 会 声明 各 自 的 属性 。 

。 可 以 通过 include 来 引用 其 他 的 布局 文件 ， 这 样 可 以 把 一 个 非常 大 的 
布局 分 而 治之 ， 便 于 书写 和 阅读 。 

e ViewGroup 既 可 以 是 系统 预先 提供 的 RelativeLayout、LinearLayout、 
FeameLayout 等 组 件 ， 也 可 以 是 用 户 自 定义 的 扩展 组 件 。 








15.1.4 菜单 资源 


菜单 资源 使 我 们 可 以 方便 地 定义 出 各 种 Menu 选 项 ， 包 括 0ptions， 
Context 和 submenu。 它 的 格式 比较 简单 ， 如 下 : 


<?xml version="1.0" encoding="utf-8"?> 


<menu xmlns:android="http://schemas.android.com/apk/res/android"> 


<item.../> 

<group android:id="@[+][package: ]id/resource name" 
android:checkableBehavior=["none" | "all" | "single" ] 
android:visible=["true" | "false" ]android:enabled=["tru 
android:menuCategory=["container" | "system" | "seconda 
android:orderInCategory="integer" > 
<item... /> 

</group> 

<item> 
<menu> 
<item /> 
</menu> 

</item> 

</menu> 


。 每 一 个 item 代 表 一 个 菜单 选项 ， 可 以 设置 它 的 id 值 、 标 题 及 点 击 后 
的 响应 函数 等 ; 

。 一 个 菜单 的 group 是 指 属 性 相同 的 一 组 item ; 

。 REA MAY KET RE. 


15.1.5 字符 串 资 源 


我 们 知道 ， 在 编写 Android 应 用 程序 源码 上 时， 不 允许 对 某 个 文本 属 
性 直接 赋 子 一 串 字 符 一 一 这 是 出 于 字符 串 国际 化 和 规范 化 的 考虑 。 正 确 
的 做 法 是 先 定义 一 个 字符 串 资源 ， 并 根据 不 同 的 地 区 语言 进行 赋值 。 字 
符 串 资源 分 为 3 类 ， 分 别 是 普通 字符 串 、 字 符 串 数组 以 及 数量 字符 
(Quantity Strings) 。 


这 是 字符 串 中 最 常用 的 格式 ， 用 于 定义 一 个 简单 的 字符 串 资 源 : 


<?xml version="1.0" encoding="utf-8"?> 

<resources> 
<stringname="string_name">text_string</string> 

</resources> 


值得 一 提 的 是 ，Android 系 统 目前 已 经 可 以 支持 一 些 简 单 的 字符 串 
格式 的 自 定 义 。 


。 利用 format 格 式 
我 们 在 程序 中 经 常会 用 到 String. format (String format, 
0bject. . .args) 来 对 字符 串 进 行 格 式 化 。 在 字符 串 资 源 的 定义 中 ， 也 
可 以 使 用 类 似 的 方法 来 达到 目标 。 
比如 我 们 可 以 定义 如 下 字符 串 : 


<string name=“Test_Format_String”> Hi, %1$s, your waiting number 
</string> 


这 样 在 编写 源码 时 ， 使 用 如 下 语句 就 可 以 完成 字符 串 的 格式 化 : 
String.format(res.getString (R.string. Test_Format_String), name, 
。 利用 简单 的 HIML MARKUP 语 法 
目前 支持 的 元 素 只 有 3 种 ， 即 : 


。 <b> 用 于 加 粗 显示 ; 
。 <i> 用 于 和 斜体 显示 ; 
e <u> 用 于 加 入 下 画 线 。 


2. 字符 串 数 组 


字符 串 数组 的 格式 如 下 : 
<?xml version="1.0" encoding="utf-8"?> 
<resources> 


<string-arrayname="string_array_name"> 
<item>text_string</item> 


</string-array> 
</resources> 


当 程 序 访问 这 一 资源 时 ， 可 以 通过 数组 名 将 所 有 的 字符 串 元 素 一 次 
性 提取 出 来 。 


3. 数量 字符 串 


HeriaheKea nwo, CrekiEee<AR Sete Mee 
串 做 相应 调整 。 格 式 如 下 : 


<?xml version="1.0" encoding="utf-8"?> 


<resources> 
<pluralsname="plural_name"> 
<itemquantity=["zero" | "one" | "two" | "few" | "many" 
text_string 
</item> 
</plurals> 
</resources> 


这 样 ， 我 们 就 可 以 通过 如 下 接口 来 获取 所 需 的 字符 串 : 
public String getQuantityString (int id, int quantity) 


需要 注意 的 是 ，“zero”“one” 这 些 词 并 不 代表 传统 意义 上 的 数 
值 0(、1， 而 是 体现 了 字符 串 中 的 元 素 〈 如 上 述 的 Song) 在 复数 语法 上 的 
区 分 。 比 如 在 英语 中 ，0 或 者 2 的 复数 形式 都 是 一 样 的 ， 它 们 只 和 1 不 同 


(zero books, one book, two books) 。 
15.1.6 样式 资源 


样式 资源 相当 于 将 常用 的 U1 外 观 保存 成 “模板 ” 一 一 这 样 当 下 次 
需要 使 用 同一 种 样式 时 ， 就 可 以 直接 调用 ， 而 不 是 重 写 一 遍 。 


格式 如 下 : 


<?xml version="1.0" encoding="utf-8"?> 
<resources> 
<stylename="style_name"parent="@[ package: ]style/style_to_inh 
<itemname="[package: ]style_property_name">style_value</ 
</style> 
</resources> 


e 一 种 样式 可 以 继承 自 其 他 样式 用 parent 属 性 表示 。 
e 可 以 定义 多 个 item 来 表示 不 同 的 样式 属性 ， 如 android:textColotr， 


android:textSize 等 。 


如 果 我 们 只 是 需要 把 样式 应 用 于 菏 个 View 视 图 ， 可 以 通过 View 的 
Style 属 性 来 设置 。 而 如 果 样式 需要 被 应 用 于 整个 Activity 甚 至 





Application， 可 以 设置 它 的 android:theme 属 性 一 一 这 时 我 们 又 可 以 称 
为 “主题 样式 ”。 


15.1.7 其 他 资源 


除了 前 面 几 个 小 节 介 绍 的 资源 外 ，Android 系 统 还 包含 了 一 些 特 殊 
的 资源 。 它 们 有 点 类 似 于 变量 值 的 定义 ， 比 如 : 


e Bool; 

e Color; 

e Diemension; 
e ID; 
e Integer; 

e Integer Array; 
e Typed Array. 


E asa 
行 讲解 。 


和 前 面 闫 色 状 态 资 源 中 的 描述 一 样 ， 一 种 特定 的 颜色 可 以 “#” 开 
头 ， 并 通过 #RGB、#ARGB 等 4 种 格式 来 赋值 。 


语法 如 下 : 
<?xml version="1.0" encoding="utf-8"?> 
<resources> 
<colorname="color_name">hex_color</color> 
</resources> 


15.1.8 属性 资源 


不 论 是 哪 种 资源 ， 都 是 由 “属性 ”来 描述 的 ， 只 不 过 不 同 的 资源 类 
别 拥 有 的 “属性 ” 值 有 一 定 区 别 。Android 系 统 已 经 为 我 们 预定 义 了 不 
少 常用 的 属性 ， 可 统一 以 “android”+“:”+[ 属 性 名 ] 的 方式 访问 ， 如 
android:id，android:visible 等 。 


本 小 节 我 们 将 讲解 两 方面 的 内 容 : 


e Android 预 定义 的 属性 ; 
e 如 何 添加 自己 的 属性 。 


所 有 framework 相 关 的 资源 都 在 源码 工程 中 的 
frameworks/base/core/res/res/ 目 录 下 ， 而 关于 属性 的 定义 则 放 在 
attrs. xm| 文 件 中 。 可 以 看 到 ， 这 个 文件 以 《resource>》 作 为 外 围 标 签 ， 
其 余部 分 则 由 一 系列 的 declare-styleable> 以 及 <attr> 标 俭 组 成 。 比 
如 : 


<declare-styleable name="Theme"> 

<!-- Default color of foreground imagery. --> 
<attr name="colorForeground" format="color" /> 
<!-- Default color of foreground imagery on an inverted backgroun 
<attr name="colorForegroundiInverse" format="color" /> 
<!-- Color that matches (as closely as possible) the window backg 
<attr name="colorBackground" format="color" /> 


</declare-styleable> 


以 及 : 


<resources> 

<attr name="textIsSelectable" format="boolean" /> 
<attr name="gravity"> 

<flag name="top" value="0x30" /> 

<flag name="bottom" value="0x50" /> 

<flag name="left" value="0x03" /> 

<flag name="right" value="0x05" /> 

<flag name="center_vertical" value="0x10" /> 
<flag name="fill_vertical" value="0x70" /> 
<flag name="center_horizontal" value="0x01" /> 
<flag name="fill_horizontal" value="0x07" /> 
<flag name="center" value="0x11" /> 


</attr> 


</resources> 
<attr> 的 格式 如 下 : 


<attr name="[ATTR_NAME]" format="[FORMAT]" /> 


其 中 format 可 以 是 string、dimension、boolean 等 一 系列 常用 单 


位 ， 还 可 以 是 enum 枚 举 基 型 ， 或 者 flag 这 种 “或 运算 ”的 数值 。 比 如 上 
面 “gravity” 的 flag 中 包含 

了 “center vertical” 和 “center_horizontal” (分 别 为 0x10 和 
0x01) , 人 就 可 以 执行 “或 运 
算 ” 得 到 0x11 (实际 上 也 就 是 “center”) 。 这 种 特性 是 enum 所 不 具备 
28, 所 以 单独 以 “flag” 来 表示 。 


如 果 读 者 仔细 观察 ， 会 发 现 有 的 <attr> 位 于 declare-styleable> 
中 ， 而 有 的 <attr> 则 直接 在 <resources> 中 。 那 么 ， 这 两 种 形式 有 什么 
区 别 呢 ? 


简单 来 讲 ， 位 于 《declare-styleable> 中 的 元 素 代 表 了 某 种 特定 资 
源 的 属性 ， 而 外 围 的 属性 则 是 “共有 的 ” 。 换 句 话说 , 《declare- 
styleable> 可 以 使 用 外 围 的 属性 值 。 举 个 例子 ， gravity 这 个 属性 在 l 
围 有 完整 定义 ， 而 且 在 很 多 declare-styleable> 中 也 会 被 引用 到 。 

如 TextView 中 : 


<declare-styleable name="TextView"> 
<attr name="gravity" /> 


</declare-styleable> 


而 且 引 用 的 地 方 没有 再 对 它 进行 定义 一 一 它 的 属性 值 和 外 围 
的 “gravity” 一 样 。 


整个 文件 中 的 <attr> 是 不 允许 重 名 的 ， 即 便 它 们 位 于 不 同 的 
styleable 中 。 


在 xm1 文 件 中 使 用 属性 值 时 ， 首 先 要 引用 它 的 xmlns。 比 如 要 使 用 
android 系 统 提 供 的 这 些 预 定义 属性 ， 则 需要 


xmlns:android=http://schemas.android.com/apk/res/android 


n 如 果 是 后 期 自己 添加 的 属性 ， 这 里 的 URL 地 址 就 要 转换 成 相应 的 包 
路 径 。 


所 有 属性 最 终 会 被 ADPT 工 具 自 动 生成 R. java 中 的 一 个 类 成 员 变 量 ， 
供应 用 程序 代码 调用 。 


比如 View 组 件 有 如 下 属性 定义 : 


/*frameworks/base/core/res/res/values/attrs.xml*/ 
<declare-styleable name="View"> 

<attr name="id" format="reference" /> 

<attr name="tag" format="String" /> 


<!-- The initial horizontal scroll offset, in pixels.--> 
<attr name="scrollx" format="dimension" /> 
<!-- The initial vertical scroll offset, in pixels. --> 


<attr name="ScrollY" format="dimension" /> 
<attr name="background" format="reference|color" /> 


View 相 关 属 性 生成 的 结果 : 


/*R.java*/ 
public static final int[] View = { 16842851, 16842852, 16842853, 
16842965, 16842966, 16842967, 16842968, 16842969, 16842970, 16842 


public static final int View_background = 12; 

public static final int View_clickable = 29; 

public static final int View_contentDescription = 41; 
public static final int View_drawingCacheQuality = 32; 
public static final int View_duplicateParentState 33; 
public static final int View_focusableInTouchMode 19; 
public static final int View_hapticFeedbackEnabled = 39; 
public static final int View_id = 8; 
public static final int View_tag = 9; 
public static final int View_scrollx 
public static final int View_scrollY 


10; 
11; 


这 个 R. java 会 放 在 一 个 名 为 “android” 的 包 中 ， 如 Android 4.14 
的 范例 如 图 15-2 所 示 (Android 4. 3 也 是 一 样 的 ) 。 


E-S Android 4.1 

= ý android. jar - C:\Program Files\Androidiandroi 
=) android 

+ tnd Manifest. class 
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全 图 15-2 范例 的 内 容 


这 也 同时 解释 了 为 什么 我 们 使 用 “Android:[ 属 性] ”就 可 以 访问 到 


R. java 中 的 相应 变量 。 


读者 可 能 已 经 注意 到 上 面 R. java 中 有 一 个 View 数 组 ， 其 后 的 成 员 
量 值 实际 上 是 该 数组 的 序号 : 


/*frameworks/base/core/java/android/view/View. java*/ 
public View(Context context, AttributeSet attrs, int defStyle) { 
this(context); 
TypedArray a = context.obtainStyledAttributes(attrs, 
com.android.internal.R.styleable.View, d 


Ket 


final int N = a.getIndexCount(); 
for (int i = 0; i < N; i++) { 
int attr = a.getIndex(1); 
switch (attr) { 
case com.android.internal.R.styleable.View_backgr 
background = a.getDrawable(attr); 
break; 
case com.android.internal.R.styleable.View_paddin 
padding = a.getDimensionPixelSize(attr, -1); 
break; 
case com.android.internal.R.styleable.View_paddi 
leftPadding = a.getDimensionPixelSize(attr, - 
break; 


上 面 这 段 代 码 是 Vi ew 的 构造 函数 之 一 ， 我 们 在 xml 布 局 文件 中 的 
Vi ew 组 件 惑 是 通过 这 个 函 数 来 生成 的 。 这 里 要 解决 的 问题 是 : 代码 中 如 
何 获取 通过 xm1 指 定 的 某 个 属性 ? 


首先 调用 如 下 语句 : 


TypedArray a = context.obtainStyledAttributes(attrs, 
com.android.internal.R.styleable.View, d 


可 以 看 到 ， 上 面 加 深 的 部 分 就 是 前 面 所 说 的 View 数 组 。 然 后 依据 各 
个 属性 在 数组 中 的 位 置 〈( 比 如 background 是 
com. android. internal. R. styleable. View background=12) ， 就 可 以 
得 到 background 属 性 对 应 的 资源 号 ， 最 后 通过 Resource 类 提供 的 各 种 加 
载 方 法 就 可 以 把 资源 提取 出 来 了 : 


public Drawable getDrawable(int index) { 
final TypedValue value = mValue; 
if (getValueAt (index*AssetManager.STYLE_NUM_ENTRIES, valu 


return mResources.loadDrawable(value, value.resourcel 


} 
return null; 


除了 这 些 系 统 自 市 的 资源 属性 外 ， 很 多 时 候 我 们 还 需要 自 定义 新 的 
属性 值 。 比 如 ， 基 于 已 有 的 View 组 件 来 扩展 一 个 控件 。 升 级 后 的 View 组 
oe eo ATER St A) LA EA RA 
新 的 属性 。 


可 行 的 方法 有 很 多 种 ， 不 过 推荐 读者 使 用 declare-styleable。 一 
方面 这 是 Android 系 统 内 部 所 采用 标准 的 属性 添加 机 制 ; 另 一 方面 它 在 
编译 时 就 会 做 相应 的 错误 检查 ， 而 不 是 等 到 代码 运行 时 再 报错 〈 此 时 程 
。 具 体 添加 过 程 和 前 面 的 标准 属性 没有 太 大 差异 ， 此 处 
TAZE. 


15.2 提供 可 选 资源 


为 一 个 应 用 程序 提供 多 种 可 选 资源 是 实现 设备 适 配 的 基础 。 比 如 对 
于 同一 张 图 片 ， 我 们 可 以 提供 高 分 辨 率 、 中 分 辨 率 和 低 分 辨 率 3 个 版 
本 。 一 般 的 目录 结构 如 下 : 


res/ 

drawable/ 
test.png 

drawable-hdpi/ 
test.png 

drawable-mdpi/ 
test.png 

drawable-1ldpi/ 
test.png 


上 面 展 示 了 test. png 这 个 图 像 资 源 的 几 个 不 同 版 本 。 需 要 注意 的 
是 ， 它 们 都 必须 以 相同 的 名 字 存 储 在 各 drawab1e 目 录 下 。 当 应 用 程序 运 
行 时 ， 系 统 会 依据 当前 设备 的 实际 屏幕 分 辩 率 来 选择 最 佳 的 资源 。 
除了 分 辨 率 外 ， 同 种 资源 之 间 还 可 有 以 下 几 种 标签 属性 。 


(注意 : 以 下 的 标签 修饰 语 是 按照 优先 级 从 高 到 低 的 顺序 排列 
Jo ) 


e MCC 和 MNC (MCC and MNC) 
MCC (Mobile Country Code) 和 MNC (Mobile Network Code) 是 网 
络 运 营 商 的 全 球 唯 一 编号 。 其 中 MCC 指 国家 码 ， 后 者 则 是 网 络 编号 。 比 
如 MCC-310 属 于 美国 ，MCC-460 属 于 中 国 。460-00 代 表 中 国 移动 ，460-01 
代表 中 国联 通 。 一 般 情 况 下 ，SIM 卡 中 存 有 此 卡 的 主 归属 地 。 


用 作 资 源 标签 时 ， 我 们 可 以 同时 使 用 MCC，MNC 组 合 ， 也 可 以 只 使 用 
MCC 。 


比如 : 


e mcc460 ; 


mcc460-mnc00. 


在 程序 编码 时 ， 可 以 通过 Configuration 类 中 的 mcc 和 mnc 属 性 来 获 


取 当 前 设备 的 这 两 个 值 。 


。 语言 和 地 区 (Language and Region) 


Android 系 统 中 采用 的 是 1S0 639 
地 区 代码 则 遵照 1S0 3166-1-al pha-2 


-1 国际 语言 码 ， 由 两 个 字母 组 成 。 
标准 执行 ， 也 是 两 个 字母 。 其 中 地 


区 码 是 可 选 的 ， 如 果 加 上 的 话 ， 需 要 在 前 面额 外 加 上 “r”。 


例如 : 
en 《表示 英语 ) ; 
fr 《表示 法 语 ) ; 
en-rUS 《表示 英语 和 美国 地 
fr-rCA 《表示 法 语 和 加 拿 大 


在 程序 编码 时 ， 可 以 通过 Config 
当前 设备 的 语言 地 区 信息 。 


e 最 小 宽度 (Smallest Width) 





格式 是 : 
sw<N>dp 

需要 特别 指出 的 是 ， 这 里 的 宽度 
中 较 小 的 那个 。 

例如 : 

° sw300dp ; 


sw600dp. 


K) ; 
地 区 ) 。 
uration 类 的 locale 属 性 值 来 获取 


—— 
= 
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其 实 是 指 传统 意义 上 屏幕 的 宽 和 


如 果 用 res/1ayout-sw600dp/ 来 标志 自己 的 布局 资源 ， 那 就 相当 于 
告诉 系统 ， 屏 幕 的 可 显示 尺寸 必须 在 任何 时 刻 都 大 于 600dp 《因为 有 时 
是 横 屏 显示 ， 有 时 是 坚 屏 显示 ) ， 才 可 以 使 用 这 一 资源 。 和 语言 值 不 
同 ， 设 备 的 最 小 宽度 值 是 固定 的 ， 不 会 随 着 设置 的 变化 而 改变 。 


在 AndroidManifest. xm| 中 ， 可 以 通 
过 “android:requiresSmal lestyWidthDp” 属 性 值 来 表示 此 程序 要 求 的 
最 小 宽度 值 。 


在 程序 编码 时 ， 可 以 通过 Configuration 类 中 的 
smal lestScreenWidthDp 成 员 变 量 来 获取 当前 设备 的 最 小 宽度 值 。 





e 可 用 宽度 (Available Width) 
格式 是 : 
w<N>dp 
和 上 面 的 最 小 宽度 不 同 ， 设 备 的 可 用 宽度 值 随 着 当前 是 横 屏 还 是 坚 
屏 会 产生 变化 ， 即 它 表 示 的 是 当前 真实 的 宽度 值 。 如 果 读 者 的 多 种 可 选 
资源 中 都 采用 了 这 一 标签 进行 修饰 ， 那 么 系统 会 自动 选择 一 个 最 接近 于 
(但 不 超过 〉 当前 值 的 资源 。 
例如 : 
e w/20dp; 
e w1024dp. 


可 以 通过 Configuration 类 的 screenWidthDp 成 员 变 量 来 获取 当前 的 
可 用 宽度 值 。 


e 可 用 高 度 (Availabe Height) 
格式 是 : 
h<N>dp 


这 个 标签 和 上 面 的 可 用 宽度 所 表达 的 含义 类 似 ， 只 不 过 前 面 是 宽 


度 ， 而 这 里 是 指 高 度 。 它 同样 会 随 着 设备 横 、 罕 屏 的 变化 而 产生 差异 。 
当 有 多 个 可 选 资 源 时 ， 系 统 会 选择 一 个 最 接近 〈 但 不 超过 ) 当前 真实 值 
的 资源 选项 。 
我 们 可 以 通过 Confi guration 类 的 screenHeightDp 来 获取 设备 的 这 
一 属性 值 。 
e 屏幕 大 小 (Screen Size) 


因为 市 面 上 的 屏幕 尺寸 非常 多 ， 而 且 还 在 不 断 地 涌现 出 新 的 类 型 ， 
所 以 我 们 不 太 可 能 为 每 种 特定 的 尺寸 大 小 分 配 一 个 选项 。 在 Android 系 
统 中 ， 将 屏幕 尺寸 大 致 分 为 以 下 几 类 。 


e small 


尺寸 类 似 于 QVGA- 低 密度 和 VGA- 高 密度 的 屏幕 ， 归 属于 这 一 类 。 最 
小 的 布局 尺寸 约 为 320*426 dp. 


e normal 


尺寸 类 似 于 HVGA- 中 密度 、WVGA- 低 密度 和 WQVGA- 低 密度 的 屏幕 属于 
这 一 类 。 最 小 的 布局 尺寸 约 为 320*470dp。 


e large 


尺寸 类 似 于 VGA- 中 密度 和 WVGA- 中 密度 的 屏幕 属于 这 一 类 。 最 小 的 
布局 尺寸 约 为 480*640dp。 


e xlarge 
对 于 尺寸 远 超 传统 HVGA- 中 密度 的 屏幕 属于 这 一 类 。 最 小 布局 尺寸 
oe 这 种 尺寸 的 屏幕 往往 用 于 平板 电脑 而 不 是 移动 手持 电 
TA o 


我 们 同样 可 以 通过 Conf iiguration 类 中 的 screenLayout 成 员 变量 来 
获取 当前 设备 的 屏幕 大 小 。 


o 屏幕 宽 高 外 观 (Screen Aspect) 


这 个 属性 是 指 当 前 屏幕 的 宽 高 比 (aspect ratio) 。 有 两 种 结果 : 
e long 

长 屏幕 ， 如 WQVGA、WVGA、FWVGA 等 。 
e notlong 

非 长 屏幕 ， 如 QVGA、HVGA、VGA 等 。 


可 以 通过 Configuration 类 中 的 screenLayout 成 员 变 量 来 获知 屏幕 
是 否 为 长 屏 。 


。 屏幕 方向 (Screen Orientation) 
分 为 两 种 ， 即 : 
。 X (port) 
屏幕 处 于 竖 屏 状态 (portrait orientation) 。 
。 模 屏 (land) 
屏幕 处 于 横 屏 状 态 (landscape orientation) 。 
显然 这 个 值 会 随 着 用 户 的 操作 而 变化 ， 但 我 们 可 以 通过 
on iguration 类 中 的 orientation 成 员 变 量 来 获知 当前 设备 的 屏幕 方 
e UI 模式 (UI Mode) 
U1 模式 分 为 以 下 几 种 : 
° car; 


° desk; 


° television; 


° appliances 


它 表 示 设 备 被 放置 在 底盘 (dock) 时 的 模式 ， 如 汽车 上 的 手机 托 


盘 、 桌 面 托盘 等 。 这 个 模式 会 随 着 用 户 的 操作 而 改变 ， 可 以 通过 
UiModeManager 来 开启 和 关闭 这 一 功能 。 


e 夜间 模式 (Night Mode) 
分 为 两 种 ， 即 : 

e night 
当前 处 于 夜间 模式 。 

© notnight 


当前 不 处 于 夜间 模式 。 


如 果 夜 间 模 式 被 设置 为 自动 ， 那 么 系统 会 根据 当前 时 间 来 自行 
是 不 是 夜间 模式 。 可 以 通过 UiModeManger 来 开启 或 关闭 这 一 功能 。 





。 屏幕 像素 密度 (dpi) 


和 前 面 的 屏幕 大 小 类 似 ， 屏 幕 的 密度 种 类 也 比较 多 ， 因 而 在 
Android 系 统 中 将 dpi 粗 略 地 分 为 以 下 几 类 。 


e Idpi 

低 密度 屏幕 ， 大 约 为 120dp i 。 
e mdpi 

中 密度 屏幕 ， 大 约 为 160dp i 。 
。hdpi 


高 密度 屏幕 ， 大 约 为 240dp i 。 


si 


决定 


e 
ps 
D` 
Ou 
T 
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8 高 密度 屏幕 ， 大 约 为 320dpi。 


© 
5 
O 
Ou 
T 
=. 


表示 这 些 资 源 不 希望 被 改变 尺寸 以 适应 屏幕 。 


tvdpi 


介 于 mdpi 和 hdpi 之 间 ， 大 约 为 213dpi。 主 要 用 于 电视 产品 ， 普 通 的 
应 用 程序 并 不 推荐 使 用 。 


。 人 触摸 屏 的 类 型 (Touchscreen Type) 
有 如 下 两 种 可 选 值 。 

e notouch 

设备 不 带 触摸 屏 。 

e finger 

触摸 屏 是 通过 手指 操作 的 。 


通过 Configuration 类 的 touchscreen 成 员 变 量 ， 可 以 获知 当前 设备 
的 触摸 屏 类 型 。 


o 键盘 可 用 性 
当前 键盘 的 状态 有 3 种 可 能 值 
e keysexposed 


设备 有 可 用 键盘 。 如 果 当 前 的 软 键盘 被 启用 ， 那 么 即便 设备 没有 键 
盘 或 者 键盘 不 可 用 ， 这 个 状态 仍 可 能 有 效 。 


e keyshidden 


设备 有 键盘 ， 但 当前 被 隐藏 ， 而 且 没有 软 键盘 启用 。 
e keyssoft 
设备 当前 的 软 键盘 启动 ， 即 便 它 处 于 可 见 或 不 可 见 状态 。 


个 值 在 运行 过 程 中 可 能 会 变化 ， 可 以 通过 Configuration 类 的 
E e a idden 和 keyboardHidden 变 量 来 获知 当前 状态 。 


e 首选 文本 输入 方法 (Primary Text Input Method) 
这 个 名 字 可 能 会 引起 误解 ， 其 实 它 是 关于 设备 按键 的 。 


nokeys 


WET AAT ATA BERG 


qwerty 
设备 有 一 个 qwerty 键 盘 ， 无 论 它 是否 可 见 。 


1 2key 
设备 有 一 个 12 键 的 键盘 ， 无 论 它 是 否 可 见 。 


可 以 通过 Configuration 类 的 keyboard 变 量 来 获知 当前 的 首选 文本 
输入 方法 。 


o 定位 键 可 用 性 (Navigation Key Availability) 


定位 键 是 否 可 用 CES: 这 里 个 是 指 GPS 导航 的 定位 ， 而 是 光标 定 
位 ) : 


e navexposed 
定位 键 对 用 户 可 用 。 


e navhidden 


定位 键 不 可 用 。 


这 个 值 也 会 在 运行 中 动态 变化 ， 可 以 通过 Configuration 类 的 
navigationHidden 变 量 来 获取 当前 值 。 


。 主 要 的 非 触摸 屏 定位 方式 (Primatry non-touch Navigation Method) 
这 个 属性 是 指 除 触 摸 屏 以 外 的 定位 方法 ， 有 以 下 几 种 。 
设备 除了 触摸 屏 外 没有 其 他 定位 方式 。 
e dpad 
设备 配备 dpad 来 定位 。 
。 trackball 
设备 配备 轨迹 球 来 定位 。 
e wheel 
设备 有 方向 滚轮 用 于 定位 ， 不 常用 。 


可 以 通过 Configuration 类 的 navigation 变 量 来 获取 设备 当前 的 非 
触摸 屏 定 位 方式 。 


e 平台 版 本 (Platform Version) 


旨 的 是 设备 所 支持 的 AP1 等 级 值 ， 如 v3、v4、v8 等 。 


15.3 最 佳 资源 的 匹配 流程 

针对 大 多 数 APK 应 用 程序 ， 开 发 人 员 都 会 提供 各 种 不 同 版 本 的 资 
源 。 那 么 ， 系 统 在 运行 时 是 如 何 动态 选择 最 合适 的 资源 来 使 用 呢 ? 理解 
最 佳 资 源 的 匹配 流程 至 少 有 如 下 两 个 好 处 。 


。 当 设计 应 用 程序 时 ， 我 们 可 以 有 针对 性 地 提供 正确 的 资源 。 
。 对 于 我 们 适 配 多 种 设备 有 重要 的 指导 意义 。 


最 佳 资 源 的 匹配 规则 如 图 15-3 所 示 。 






KITTS | 


ARE | 


RARMAN 
优先 级 顺序 考察 得 


个 资源 是 全 包 合 这 个 标 人 


全 图 15-3 资源 的 匹配 过 程 
我 们 以 官方 文档 中 的 一 个 例子 来 具体 分 析 匹 配 流程 。 
假设 某 应 用 程序 中 的 drawable 资 源 有 如 下 几 种 选项 : 


drawable/ ; 
drawable-en/ ; 
drawable-fr-rCA/ ; 
drawable-en-pott/ ; 


drawable-en-notouch-12key/ ; 


drawable-port-ldpi/ ; 


drawable-port-notouch-12key/ o 
设备 的 当前 配置 为 : 


Locale = en-GB; 


Screen orientation = port; 


Screen pixel density = hdp1; 


Touchscreen type = notouch; 


Primary text input method = 12key. 


匹配 目标 : 逐一 排除 资源 选项 ， 直 到 只 剩 下 唯一 的 选择 〈 即 选 
择 最 优 解 的 过 程 ) 。 


匹配 过 程 : 分 为 两 个 阶段 。 
。 第 一 阶段 : 筛选 掉 与 设备 当前 配置 不 相符 的 资源 选项 
在 淘汰 过 程 中 ， 对 于 资源 选项 里 没有 显 式 与 出 来 的 配置 ， 不 作为 评 
判 标准 ; 而 资源 选项 里 显 式 与 出 来 的 ， 符 合 当前 配置 的 可 以 通过 筛选 ， 
否则 直接 淘汰 。 


比如 上 面 例子 中 ， 第 3 个 资源 选项 中 的 “fr-rCA” 及 第 6 个 选项 中 
的 “1dpi” 都 不 符合 当前 的 设备 配置 ， 应 该 被 淘汰 。 


个 过 还 需要 指出 的 一 个 特例 是 ，Android 了 明确 规定 : density 标 签 不 
在 第 一 阶段 的 淘汰 范围 内 。 因 而 ， 第 一 轮 游戏 结束 时 结果 如 下 : 


° drawable/; 

° drawable-en/; 

e drawable-fr-rCA/ (淘汰 ) ; 

e drawable-en-port/; 

e drawab |e-en-notouch-12key/ ; 


° drawable-port-Idpi/ (作为 特例 被 保留 下 来 ) ; 


° drawable-port-notouch-12key/. 
。 第 二 阶段 : 选择 最 优 解 


经 过 第 一 轮 的 “资格 淘汰 赛 ” 后 ， 剩 余 的 选项 都 是 完全 符合 设备 当 
前 配置 要 求 的 (除了 特例 外 ) 。 因 此 ， 接 下 来 这 一 轮 竞 赛 中 我 们 需要 在 
所 有 “选手 ”中 选择 一 个 最 优秀 的 。 这 就 好 比 才艺 比赛 一 样 ， 我 们 首先 
设 定 了 参赛 者 的 入 门 条 件 〈 阶 段 一 ) ; 而 只 有 通过 初步 筛选 后 ， 才 再 按 
一 定 的 优先 级 标准 来 评定 每 个 选手 的 表现 《阶段 二 ) 。 比 如 歌唱 技巧 是 
最 重要 的 考察 因素 ， 最 后 是 舞台 表现 力 ， 最 后 是 表情 张力 等 。 


前 一 小 节 我 们 介绍 资源 标签 时 采用 的 内 容 编排 顺序 ， 就 是 根据 它们 
的 优先 级 来 定 的 。 应 用 到 这 个 例子 中 : 


Step1， 我 们 先 选择 MCC，MNC 来 考察 ， 发 现 没 有 任何 “选手 ”包含 


这 个 标签 。 


_ Step2， 选 择 语言 与 地 区 标签 。 由 于 当前 配置 是 en-GB， 所 以 没有 市 
这 个 标签 的 “选手 ”被 淘汰 。 结 果 如 下 : 


° drawable/ 淘汰) ; 


e drawab | e-en/; 


e drawable-en-port/; 
e drawab|e-en-notouch-12key/ ; 
e drawable-port-Idpi/ (淘汰 ) ; 


e drawable-port-notouch-12key/ (淘汰 ) ào 


接 下 来 的 步骤 中 我 们 重复 利用 这 一 规则 ， 直 到 最 终 只 剩 一 个 “ 选 
手 ” 为 止 。 在 这 个 例子 中 ，“ 冠 军 ” 要 直到 “屏幕 方向 ”标签 时 才 出 现 
《设备 的 当前 屏幕 方向 是 port) : 

e drawable-en/ (淘汰 ) ; 
e drawable-en-port/ (FEW) ; 


° drawable-en-notouch-12key/ (淘汰 ) 。 


15.4 ”屏幕 适 配 


屏幕 适 配 是 确保 Android 应 用 程序 兼容 性 一 个 至 关 重要 的 环节 。 我 
们 知道 ，Android 设 备 种 类 繁多 ， 这 意味 着 APK 开 发 者 不 可 能 只 针对 某 种 
特定 型 号 的 设备 来 做 匹配 《当然 ， 如 果 你 的 应 用 程序 只 打算 运行 在 有 限 
的 已 知 设备 上 ， 就 可 以 做 有 针对 性 的 适 配 ) ， 而 应 尽 可 能 考虑 到 所 有 可 





能 出 现 的 设备 一 一 因而 如 何 对 这 些 设备 的 屏幕 进行 合理 有 效 的 分 类 是 首 
先 要 解决 的 难点 。 


15.4.1 屏幕 适 配 的 重要 参数 
本 小 节 中 ， 我 们 先 来 看 看 Android 系 统 中 和 屏幕 相关 联 的 几 个 重要 


o 屏幕 分 辨 率 (Screen Resolution) 


分 辨 率 是 指 屏 幕 上 物理 像素 的 多 少 ， 它 直接 反映 了 屏幕 显示 的 精细 


度 。 通 常 像素 点 越 多 ， 男 面 就 越 清晰 ， 可 以 显示 更 多 细节 ; 相反 ， 像 素 
点 少 的 屏幕 显示 出 的 图 像 容 易 出 现 锯齿 ， 男 面相 对 模糊 。 常 见 的 屏幕 分 
辩 率 有 QVGA (320*240) 、VGA (640*480) =. 


但 是 在 Android 的 设计 理念 中 ， 我 们 并 不 能 直接 去 使 用 分 辨 率 一 一 
而 是 由 以 下 所 提 到 的 屏幕 密度 和 大 小 来 做 组 合 表达 。 





o 屏幕 密度 (Screen Density) 


单位 间距 内 物理 像素 点 数量 的 多 少 ， 以 dpi (Dots per Inch) 表 
示 。Android 系 统 将 屏幕 密度 分 为 4 类 ， 分 别 为 : 


° Idpi (low) ; 

° mdpi (medium) ; 

° hdpi (high) ; 

° xhdpi (extra high) 。 


° 屏幕 尺寸 (Screen Size) 。 


一 般 是 指 屏幕 的 对 角 线 尺寸 值 ， 用 inch 表 示 。 比 如 常用 的 尺寸 包括 
3.7inch, 4.0inch, 6.1inch 等 。 在 Android 系 统 中 ， 将 所 有 可 能 的 屏 


幕 尺 寸 分 为 4 种 ， 妈 : 


° Smal | ; 
° Normal ; 
e Large; 
° xlargeo 


RREEMRTA (small, normal, large) 并 不 是 根据 绝对 
的 某 个 范围 值 来 划 定 的 ， 如 图 15-4 所 示 。 


再 来 看 看 Goog le 官方 发 布 的 一 份 数 据 一 一 截至 2012 年 7 月 ， 市 面 上 


Android 产 品 的 屏幕 大 小 和 密度 的 分 布 〈《 这 份 报告 也 可 以 作为 应 用 开发 
者 的 市 场 参考 ) 如 表 15-2 所 示 。 


Actual size (inches) 2 4 7 10 
Generalized Size NS NS 
oo | 
small arge 
normal xlarge 

Actual density (cpi) 100 200 300 
Generalized density w 

IlGpi gg hapi RE 

mapi xhdpi 


全 图 15-4 Android 系 统 中 屏幕 尺寸 和 密度 对 照 图 


表 15-2 不同 屏 幕 尺 寸 与 密度 的 Android 设 备 的 市 占 率 





由 此 可 见 ， 市 面 上 最 常见 的 Android 设 备 的 屏幕 尺寸 为 normal， 屏 
幕 密度 为 hdpi， 如 图 15-5 所 示 。 


Normal/mdp! 


YXXXX Var 







AYA 


Normal/Idp1 
Normal/xhdp1 


Small/hdpi 
Small/ldpi 


Xlarge/mdpi 


Large/ldpi 
Large/mdpi 


Normal/hdpi 


全 图 15-5 屏幕 尺寸 占 比 
。 RARE th (Aspect Ratio) 


屏幕 的 宽 和 高 的 比值 ， 称 为 Aspect Ratio。 比 如 16:9 一 一 如 果 宽 度 
为 16， 那 么 高 度 值 为 9。 


o 屏幕 方向 (Screen Orientation) 


以 用 户 的 视线 方向 为 准 ， 如 果 宽 高 比 大 于 1， 称 为 横 屏 
(landscape) ， 否 则 就 是 竖 屏 (portrait) 。 











o 设备 独立 像素 (Density Independent Pixel) 


DIP 是 为 了 更 好 地 自 适 应 不 同 的 屏幕 而 提出 的 概念 。 中 心思 想 是 dip 
的 值 会 随 着 当前 屏幕 的 密度 变化 而 做 相应 改变 。 它 的 计算 公式 为 : 
Px = dp * (dpi /160) 


也 就 是 说 ， 在 dpi 为 160 的 设备 上 ，dip 数 值 和 屏幕 物理 像素 是 一 样 
AY; 而 在 dpi 为 240 的 机 器 上 ， 这 个 值 会 是 实际 值 的 1. 5 倍 。 


下 面 以 Android 官 方 提供 的 一 个 例子 来 解释 采用 dip 的 好 处 。 
假如 有 3 台 设 备 ， 它 们 的 屏幕 尺寸 是 一 样 的 ， 而 密度 分 别 为 1dpi、 


mdpi 和 hdpi， 那 么 采用 dip 和 不 采用 dip 的 区 别 可 以 参见 图 15-6 和 图 15- 
7s 
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全 图 15-6 不 采用 dip 时 的 情况 


DensityTest Density Test 


Low Density P Medium P 


Density Test 


Density High Density 





全 图 15-7 采用 dip 时 的 情况 


由 此 可 见 ， 对 于 不 采用 dip 来 描述 的 物体 比如 一 个 Button) ， 随 
着 屏幕 密度 的 增 大 ， 它 的 大 小 相对 于 整个 屏幕 在 缩小 ; 而 使 用 dip 摘 述 
的 情况 则 没有 这 个 问题 ， 即 它 可 以 基本 保持 此 物体 的 相对 尺寸 。 显 然后 
一 种 效果 才 是 我 们 所 期 望 的 ， 因 为 前 一 种 很 可 能 导致 UI 表 面 的 变形 。 

当然 ，dip 虽 然 可 以 在 某 种 程度 上 帮助 我 们 去 更 好 地 适应 不 同 密度 
的 屏幕 ， 但 它 也 并 不 是 万 能 的 。 大 家 可 以 想 一 下 ， 一 个 尺寸 标注 为 N dp 
的 物体 ， 它 在 不 同 屏幕 上 的 实际 物理 尺寸 〈 单 位 inch) 为 多 少 呢 ? 

计算 公式 如 下 : 
physical_size = N*(dpi/160)*(1/dpi)=N/160 

其 中 dpi 代 表 了 这 款 屏幕 的 密度 。 

我 们 得 出 一 个 结论 : 

用 dp 标注 的 物体 ， 它 在 不 同 屏幕 上 的 实际 物理 尺寸 理论 上 将 保持 不 


Is 
= 


换 句 话说 ，N 为 160 的 物体 ， 它 在 不 同 屏幕 上 的 实际 物理 矿 寸 将 为 1 
inch; N 为 320 的 物体 ， 它 在 不 同 屏幕 上 的 实际 物理 尺寸 将 为 2 inch。 


假设 全 世界 所 有 Android 设 备 的 物理 屏幕 都 是 同一 个 Size， 那 么 这 
无 疑 可 以 解决 适 配 问 题 一 一 但 显然 这 是 不 现实 的 。 


那么 这 将 导致 什么 问题 呢 ? 举 个 例子 来 说 ， 假 设 有 一 个 View 的 宽度 
设置 为 160dp， 那 么 它 在 1inch 宽 的 屏幕 上 ， 其 宽度 与 屏幕 一 致 ， 但 在 一 
个 2 inch 宽 的 屏幕 上 时 ， 它 的 宽度 则 仅 有 屏幕 的 一 半 。 这 种 情形 下 采用 





(或 者 说 只 采用 ) dp 机 制 ， 个 人 认为 就 不 是 一 个 明智 的 选择 了 。 
15.4.2 如何 适 配 多 屏幕 


Android 系 统 支 持 同 一 应 用 程序 在 多 种 屏幕 上 使 用 。 为 了 达到 这 一 
目标 ， 系 统 本 身 已 经 做 了 不 少 工作 一 一 按照 Android 的 设计 思想 ， 它 将 
尽量 为 开发 者 考虑 各 种 可 能 发 生 的 情况 。 比 如 它 会 根据 当前 设备 的 具体 

参数 自动 为 应 用 程序 选择 最 佳 的 显示 资源 ; 适当 的 时 候 还 会 对 资源 进行 
修正 ， 以 满足 实际 需求 等 。 


不 过 ，Android 系 统 本 身 也 不 是 万 能 的 ， 而 且 有 时 候 “ 智 能 ”是 
把 “ 双 刃 剑 ” 在 无 法 准确 掌握 其 工作 原理 的 情况 下 ， 越 “ 智 能 ”的 
机 制 反 而 越 有 可 能 违背 我 们 的 意愿 。 因 此 ， 理 解 Android 系 统 在 支持 多 
屏幕 时 所 做 的 工作 ， 才能 “ 取 其 精华 ， 去 其 糟粕 ”， 真 正 将 Android 的 
设计 精髓 运用 得 “淋漓 尽 致 ”。 


。 Android 系 统 为 当前 屏幕 配置 选择 最 佳 资源 的 流程 


这 一 过 程 和 我 们 前 一 小 节 讨 论 的 最 佳 资源 匹配 过 程 一 致 。Android 
系统 将 根据 现 有 的 资源 标签 以 及 实际 的 设备 屏幕 参数 ， 来 寻找 最 合适 的 
资源 类 型 。 但 是 ， 如 果 经 过 两 轮 匹 配 后 ， 还 是 没有 任何 符合 要 求 的 资源 

( 即 所 有 可 选 资源 均 被 淘汰 ) ， 那 么 它 会 选择 默认 的 资源 配置 《没有 被 
贴 上 标签 的 资源 ) 。 


默认 资源 是 应 用 程序 在 不 得 已 之 情况 下 的 选择 ， 开 发 者 应 该 提供 这 
类 资源 以 备 “不 时 之 需 ”。 


。 为 不 同 的 屏幕 尺寸 提供 多 种 layout 布 局 


我 们 已 经 在 前 几 节 讨论 过 如 何在 应 用 程序 中 提供 多 种 “可 选 资 
源 ”， 如 果 读 者 还 不 是 很 清楚 ， 建 议 回头 复习 一 下 ， 这 里 不 再 兽 述 。 


不 同 的 屏幕 尺寸 ， 所 需 的 layout 布 局 通常 也 有 所 差异 。 举 个 例子 ， 
有 一 个 显示 9 个 按钮 控件 的 layout， 它 在 大 屏幕 上 可 以 正确 显示 ; 但 一 
旦 切换 到 小 屏幕 上 ， 即 便 这 9 个 控件 都 可 以 被 显示 出 来 ， 也 可 能 会 被 压 
4a (由 此 产生 的 用 户 体 验 效果 是 很 差 的 ) 。 因 而 我 们 建议 对 于 尺寸 跨度 
大 的 屏幕 ， 应 用 程序 应 该 提供 多 种 1ayout 布 局 文件 。 





e 为 不 同 的 屏幕 方向 提供 多 种 layout 布 局 
不 同方 向 屏幕 布局 的 差异 如 图 15-8 所 示 。 


HERE 


一 


MEEN EDMAN 


全 图 15-8 横 屏 和 坚 屏 的 布局 差异 


由 图 可 知 ， 当 设备 处 于 “ 横 屏 ”状态 时 ， 可 以 正常 显示 2*3 个 尺寸 
一 样 的 控件 ; 然而 ， 当 屏幕 方向 改 为 “ 坚 屏 ”时 ， 情 况 发 生 了 很 大 变 
化 。 如 果 我 们 仍然 采用 原先 的 布局 ， 效 果 一 定 不 会 很 好 。 因 此 ， 为 不 同 
的 屏幕 方向 提供 合适 的 布局 已 成 为 应 用 开发 者 的 共识 。 


。 为 不 同 的 屏幕 密度 提供 相应 的 图 片 资源 
我 们 知道 ， 在 尺寸 不 变 的 情况 下 ， 密 度 越 大 ， 所 需 的 像素 点 越 多 ， 


显示 越 细 腊 。 而 如 果 应 用 程序 所 提供 的 图 片 资源 没有 考虑 到 这 一 点 , AB 
么 在 实际 运行 时 很 可 能 被 拉 伸 ， 从 而 造成 显示 效果 相对 模糊 。 





。 显 式 声明 应 用 程序 支持 的 屏幕 类 弄 


系统 提供 了 《supports-screens》 元 素来 让 应 用 程序 在 
AndroidManifest 文 件 中 显 式 声明 其 所 支持 的 屏幕 种 类 。 除 此 之 外 ， 这 
个 元 素 还 可 以 控制 屏幕 的 兼容 模式 (Screen Compatibility Mode) 
一 一 它 是 为 解决 应 用 程序 在 大 屏幕 上 显示 时 出 现 的 困难 而 专门 设计 的 。 
对 于 不 同 的 Android 版 本 ， 其 表现 和 设置 都 有 所 差异 。 详 细 信 息 可 以 参 
见 官 方 文档 。 


《supports-screens》 的 语法 如 下 : 


<supports-screens android:resizeable=["true"| "false"] 
android:smallScreens=["true" | "false" ] 
android:normalScreens=["true" | "false" ] 

android: largeScreens=["true" | "false" ] 

android: xlargeScreens=["true" | "false" ] 
android:anyDensity=["true" | "false" ] 


android: requiresSmallestWidthDp="integer" 
android: compatiblewidthLimitDp="integer" 
android: largestWidthLimitDp="integer"/> 


当 开发 人 员 显 式 地 声明 了 所 支持 的 屏幕 类 型 后 ， 可 以 有 效 阻止 那些 
不 符合 要 求 的 设备 安装 此 应 用 。 表 15-3 给 出 了 这 一 元 素 的 属性 描述 。 


o 支持 特定 的 屏幕 
有 的 应 用 程序 是 被 设计 专门 运行 于 某 些 特定 设备 上 的 。 在 这 种 情况 
E A ae eee 
用 程序 。 


表 15-3 <supports-screens> 的 属性 值 





表示 程序 是 否 可 以 调整 尺寸 默 

认 值 为 “true”。 如 果 是 “false” 的 

android:resizeable ; 系统 会 在 大 屏幕 时 开启 屏 
Ye He AS 





android:smallScreens 


android:normalScreens 


android:largeScreens 


android:xlargeScreens 


android:anyDensity 


android:requiresSmallestWidthDp 两 小 节 中 关于 
~ 


是 否 支 持 small 尺 寸 的 屏幕 默认 


是 否 文 持 normal 尺 寸 的 屏幕 默 
认 值 为 “true” 


是 人 否 文 持 large 尺 寸 的 屏幕 默认 
值 随 版 本 而 变化 ， 但 如 果 

是 “false”， 将 可 能 局 动 屏 幕 兼 
容 模式 





是 否 文 持 xlarge 尺 寸 的 屏幕 和 上 
面 的 属性 类 似 ， 这 个 属性 的 默 
认 值 也 会 根据 版 本 的 不 同 而 有 
所 差异 ， 因 此 建议 开发 者 最 好 
每 次 都 能 显 式 写 出 。 如 果 
te“false”, HM Ha Ao bee 
He A Rk 





Fe Ta 5 FF AT BB ES YY 
幕 。 这 意味 着 程序 提供 了 各 种 
可 选 资源 以 满足 不 同 屏幕 密度 
的 需求 从 Android 1.6 开 始 ， 默 
认 值 是 “true” 











指定 此 应 用 程序 所 能 文 持 的 最 
小 smallestWidth。 可 以 参见 前 
“最 小 宽度 


(Smallest Width) ”的 描述 











这 个 属性 可 以 让 “屏幕 兼容 模 
式 ” 作 为 一 种 用 户 选 项 体现 出 
来 。 比 如 ， 一 台 设 备 的 最 小 宽 

android:compatibleWidthLimitDpll 度 大 于 这 里 的 值 ， 那 么 兼容 模 
式 将 会 被 启动。 在 这 种 情况 
下 有 周 户 将 可 以 通过 一 个 按钮 
手工 控制 屏幕 莱 容 模式 





和 上 面 的 属性 类 似 ， 不 同 之 处 
TEP REH BE ie AR AR 


android:largestWidthLimitDp 式 ， 即 用 户 不 能 通过 按钮 来 手 
工 选择 是 否 需 要 开启 兼容 模式 





《compatible-screens> 可 以 用 来 实现 这 个 功能 。 它 的 语法 如 下 : 


<compatible-screens> 
<screen android:screenSize=["small" | "normal" | "large" | 
android:screenDensity=["ldpi" | "mdpi" | "hdpi" | "xhdp 


</compatible-screens> 


每 个 <screen> 项 用 来 表示 一 种 屏幕 兼容 配置 ， 一 个 
AndroidManifest 文 件 里 可 以 有 多 个 《screen》 描 述 。 其 中 的 screenSize 
和 screenDensity 是 必须 成 对 出 现 的 ， 否 则 会 被 视 为 无 效 。 


对 于 一 些 应 用 程序 的 服务 商 “比如 Google Play) ， 在 用 户 下 载 应 
用 程序 时 都 会 有 相应 的 检测 机 制 来 保证 用 户 使 用 的 设备 是 否 符合 
<compatible-screens> 的 限制 。 一 方面 这 将 有 效 阻止 达 不 到 要 求 的 设备 
安装 使 用 此 应 用 程序 ， 而 男 一 方面 可 能 会 阻隔 潜在 的 用 户 群 。 因 此 在 发 
布 程序 时 开发 商 一 定 要 想 清楚 ， 是 否 一 定 要 采用 这 一 属性 。 


。 布局 时 的 注意 事项 


布局 时 ， 应 尽量 避免 使 用 “绝对 ”的 表示 方法 。 比 如 不 用 或 尽量 少 
用 AbsoluteLayout (MAndroid 1.5 开 始 ， 已 经 被 废弃 ) ; 杜绝 以 “ 物 
理 像 素 点 ”为 单位 来 描述 组 件 属 性 ， 而 应 采用 dip 和 sp 来 分 别 表示 布局 
大 小 和 字体 大 小 。 





实践 证 明 ， 只 有 严格 遵循 以 上 几 点 要 求 的 应 用 程序 ， 才 能 在 “屏幕 
适 配 ”这 一 难关 中 “ 脱 疾 而 出 ”， 也 才能 为 用 户 提 供 尽 可 能 完美 的 U1 体 


JM o 
15.4.3 ”横竖 屏 切 换 的 处 理 


横竖 屏 切 换 事件 在 终端 设备 中 的 发 生 频 率 非常 高 ， 因 而 也 是 应 用 程 
序 在 开发 过 程 中 需要 特别 注意 的 。Android 系 统 在 处 理 这 一 事件 时 ， 通 
常会 重新 加 载 和 刷新 Activiy 〈 因 为 横 倒 屏 更改 有 很 大 机 率 会 融 来 表面 
的 变化 ) ， 所 以 开发 人 员 需 要 在 必要 的 情况 下 重 载 这 一 行为 以 避免 不 可 
预期 的 问题 发 生 。 


我 们 首先 分 析 一 下 发 生 横 竖 屏 切换 时 系统 的 具体 处 理 流程 ， 以 便 大 
家 可 以 根据 自己 的 需求 做 出 正确 的 选择 。 


Step1， 根 据 系统 设置 的 不 同 ， 有 两 种 可 能 : 

。 系统 设置 中 关闭 了 屏幕 旋转 功能 

此 时 系统 不 会 主动 检测 屏幕 的 旋转 事件 ， 所 以 正常 情况 下 应 用 程序 
也 就 不 会 感应 到 屏幕 方向 的 变化 了 。 当 然 ， 这 并 不 代表 应 用 程序 不 能 
动 获取 屏幕 的 横竖 屏 切 换 事件 。 事 实 上 不 少 应 用 程序 因为 自身 的 功能 需 
求 〈 如 视频 播放 器 在 横 屏 时 实现 全 屏 显 示 ) ， 会 自行 向 传感器 注册 并 获 
取信 息 一 一 这 样 一 来 就 摆脱 了 系统 设置 的 限制 了 。 

o 系统 设置 开启 了 屏幕 旋转 功能 


此 时 会 向 Sensor 注 册 一 个 监听 请 求 ， 具 体 源码 实现 在 
WindowOrientationListener. java 中 。 一 旦 有 事件 发 生 ， 将 进入 下 一 步 


Step2， 在 经 过 一 系列 的 前 期 处 理 后 ， 系 统 会 判断 应 用 程序 所 设置 
的 android:screen0rientation 值 。 关 于 这 一 属性 的 主要 可 选 值 和 释义 
如 表 15-4 所 示 。 


表 15-4 android:screen0rientaion 释 义 





unspecified ”| 默认 值 。 由 系统 根据 实际 情况 做 选择 


per fie 前 的 首选 方向 
por 根据 传感器 来 确定 方向 
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这 个 属性 来 做 相应 配置 。 


Step3， 如 果 确 定 应 用 程序 需要 响应 横 侠 屏 切 换 ， 那 么 正常 情况 下 
系统 会 重新 启动 一 次 Activity 的 生命 周期 流程 。 但 这 可 能 并 不 是 开发 人 
oe 《比如 用 户 体验 不 好 ) 。 那 么 有 没有 办 法 阻止 系统 的 这 一 默 
认 形 为 呢 ? 


答案 是 肯定 的 ， 利 用 android:configChanges 就 可 以 做 到 。 当 然 ， 
除了 正确 设置 这 一 属性 外 ， 代 码 中 还 需要 增加 对 
onConfigurationChanged 函 数 的 重 载 实现 。 这 样 惑 可 以 迫使 系统 改变 常 
规 的 处 理 流 程 ， 而 改 由 onConfigurationChanged 来 全 权 负 责 。 


上 述 3 个 步 又 是 屏幕 方向 切换 后 系统 和 应 用 程序 的 通用 处 理 流程 
在 不 同 设备 上 的 具体 表现 可 能 会 有 些 差 异 〈 取 决 于 设备 厂商 的 定制 策 
略 ) 。 建 议 大 家 在 实际 项 目 开发 中 能 针对 目标 设备 做 一 次 全 面 的 测试 
以 尽量 避免 异常 问题 的 发 生 。 


EMEA 
Android 字 符 编 码 格式 


在 工程 项 目 开发 过 程 中 ， 让 不 少 工程 师 很 头痛 的 一 个 问题 就 是 “ 乱 
码 ”。 特 别 是 当 产品 涉及 国际 化 时 ， 情 况 就 更 加 错综复杂 了 。Android 
系统 在 全 球 范围 内 者 获得 了 广泛 使 用 ， 因 而 字符 串 国际 化 的 问题 不 容 小 
iM. 


“万 变 不 离 其 宗 ”， 本 章 我 们 将 首先 从 字符 串 编码 的 基础 知识 入 
手 ， 然 后 过 渡 到 Android 项 目 中 的 实际 解决 方案 。 很 多 时 候 ， 只 要 基础 
打 扎 实 ， 问 题 也 融 迎 丸 而 解 了 。 


16.1 字符 编码 格式 背景 


从 计算 机 存储 的 角度 来 讲 ， 并 不 存在 字符 编码 格式 的 概念 ， 因 为 任 
何 资源 在 计算 机 系统 中 都 以 二 进 制 进行 存储 。 就 好 比 一 门 语言 一 一 只 有 
双 万 基于 同样 的 发 音标 准 才能 互相 理解 ， 编 码 格 式 也 就 是 编码 者 与 解码 
者 之 间 的 规范 ; 而 且 不 论 是 汉语 、 英 语 、 法 语 ， 核 心目 的 都 是 让 双方 能 
够 正常 沟通 。 编 码 格式 的 宗旨 也 类 似 ， 因 而 格式 本 身 可 以 有 多 种 形式 ， 
只 要 通信 双方 都 清楚 每 个 字 节 的 含义 即 可 。 


我 们 接 下 来 先 看 看 几 种 常见 的 字符 编码 格式 。 
e ASCII 


这 可 能 是 大 家 最 熟悉 的 一 种 编码 ， 我 们 简单 叙述 一 下 。ASC11 只 需 
一 个 字 节 ， 占 用 的 空间 很 小 ， 不 过 它 容纳 的 字符 数 也 相当 有 限 。 除 了 
128 个 字符 作为 常规 使 用 外 〈 最 高 位 为 0， 用 于 英文 字母 、 数 字 、 控 制 字 
符 等 ) ， 另 128 个 则 是 “扩展 ASC11”。 后 面 的 这 部 分 ASC11 实 际 上 没有 
统一 的 国际 标准 ， 因 而 被 “各 方 人 士 ” 利 用 起 来 用 于 自己 的 编码 规范 ， 
这 就 是 ANS1。 


e ANSI 


ANS|44 (American National Standards Institute) 实际 上 是 各 
个 国家 对 ASC11 以 外 字符 的 扩展 ， 通 常 占 2 个 字 节 。 比 如 中 国 是 6GB2312， 
日 本 则 是 J1S。 可 想 而 知 ， 这 些 “ 各 地 ”编码 是 不 兼容 的 。 因 为 ASC1 1 已 
经 占用 了 0x00-0x7F 之 间 的 范围 ， 所 以 ANS1 必 须 只 使 用 这 一 范围 以 外 的 
数值 。 另 外 ，ANS1 中 的 ASC11 字 符 仍 然 只 占用 1 个 字 节 。 举 个 例子 ，“ 我 
是 第 1” 的 ANS1 编 码 是 7 个 字 节 ， 其 中 最 后 的 “1” 只 占用 1 个 字 节 ， 其 他 
的 中 文字 符 则 各 占 2 个 字 节 。 


。 中 文 简体 /繁体 


理论 上 简体 和 繁体 字符 和 编码 没有 太 大 关联 ， 它 们 更 多 的 是 属 
于 “显示 ”范畴 的 区 别 。 举 一 个 例子 ， 一 个 繁体 字 同 样 也 可 以 用 简体 字 
的 方式 显示 出 来 。 换 句 话说 ， 我 们 先 使 用 与 该 字符 相同 的 编码 标准 将 
其 “理解 ”出 来 ， 接 下 来 要 怎么 显示 就 是 男 外 一 回 事 了 。 不 过 现实 中 简 
体 / 繁 体 与 编码 格式 还 是 息息相关 的 。 


中 文 显示 由 于 地 域 、 历 史 、 政 治 等 多 方面 的 原因 ， 最 初 主 要 有 3 种 
编码 方式 ， 即 6GB2312、Big5 和 HKSCS。 第 一 个 大 家 应 该 比较 熟悉 ， 它 是 
由 我 国 国 家 标准 总 局 于 1980 年 发 布 的 ， 因 而 也 被 称 为 6G82312-80 或 者 
GB2312-1980。 它 收录 了 6763 个 汉字 和 682 个 非 汉 字 ， 分 为 94 区 ， 每 区 又 
有 94 位 。 这 一 标准 规定 的 中 文字 符 虽 然 能 满足 大 众 的 常规 需求 ， 但 对 于 
古 汉 语 等 罕见 字 则 还 是 无 法 处 理 。 男 外 它 和 我 国 台 湾 地 区 的 Big5 也 是 不 
兼容 的 ， 因 而 造成 了 不 少 麻 烦 。 基 于 这 些 因 素 ，GBK 编 码 应 运 而 生 ， 于 
1995 年 12 月 发 布 。 这 个 标准 不 但 完全 兼容 旧 的 GB2312， 而 且 包 括 了 1S0 
10646 中 的 全 部 中 日 韩 汉字 以 及 B165 中 所 有 汉字 。1S0 10646 是 1S0 组 织 
发 布 的 编码 规范 ， 即 我 们 熟知 的 UCS (Universal Character Set) , € 
又 兼容 于 Unicode 码 。 关 于 UCS 与 Uni code 之 间 的 “ 恩 恩怨 怨 ” 还 会 牵扯 
出 很 多 事情 ， 有 兴趣 的 读者 可 以 自行 了 解 。 


随后 几 年 ， 即 2000 年 和 2005 年 ， 中 国 又 在 GBK 基 础 上 进行 了 进一步 
升级 ， 这 就 是 6B18030 系 列 。 它 们 不 但 收录 了 汉字 ， 而 且 将 沽 族 、 蒙 古 
族 、 傣 族 等 少数 民族 的 字符 都 合成 进来 ， 形 成 了 一 个 超大 型 的 编码 规 
范 。 虽 然 标准 很 多 ， 但 国家 颁发 的 这 些 字 符 集 规 范 是 向 下 兼容 的 。 


e Unicode#4 


这 也 是 我 们 比较 熟悉 的 一 种 规范 ， 只 不 过 其 中 又 有 很 多 繁杂 的 细 
节 ， 因 而 大 部 分 人 “只 知 其 一 ， 不 知 其 二 ”。 由 于 历史 原因 ， 计 算 机 发 
展 初期 并 没有 充分 考虑 国际 上 众多 语言 和 字符 的 存在 。 这 也 难怪 ， 谁 也 
不 会 预料 到 计算 机 后 来 的 发 展会 如 此 迅猛 ， 以 致 成 为 “ 走 进 干 家 万 
户 ”的 一 种 日 常用 品 。 后 期 的 问题 接 旺 而 至 ， 全 球 各 国都 已 经 意识 到 统 
一 编码 标准 的 必要 性 ， 于 是 Uni code 国 际 组 织 出 现 了 。 这 个 组 织 的 意愿 
就 是 将 世界 上 所 有 的 字符 统一 用 一 种 编码 方式 来 表达 ， 以 解决 各 种 各 样 
的 不 兼容 问题 。 虽 然 Unicode 码 和 GB 码 、B16G5 码 都 不 兼容 ， 但 它 还 是 未 
来 发 展 的 一 个 大 趋势 ， 是 一 个 软件 产品 能 否 国际 化 的 关键 ， 因 而 我 们 有 
必要 对 它 进 行 更 详细 的 讲解 。 


16.2 ISO/IEC 8859 


在 学 习 Uni code 之 前 ， 我 们 先 来 了 解 下 8859 系 列 规范 。 它 是 由 1S0 和 
IEC (International Electrotechnical Commission) 共同 推出 的 协 
议 ， 共 有 15 部 分 〈1 一 16， 但 是 12 被 废弃 ) ， 如 1S0/1EC 8859-1, 
ISO/IEC 8859-2 等 。 


虽然 ASC11 码 在 英语 中 已 经 足够 使 用 ， 但 是 很 多 以 Latin 为 基础 的 其 
他 语言 〈 主 要 是 欧洲 国家 ) ， 却 需要 更 多 额外 的 字符 来 表示 。8859 就 是 
利用 了 ASC11 以 外 的 编码 空间 来 表示 这 些 字 符 。 所 以 8859 实 际 上 能 表达 
的 字符 数 相 当 少 ， 每 个 子 集 〈 比 如 8859-1) 的 范围 是 0xA0-0xFF 即 96 个 
字母 或 者 符号 ， 详 表 可 查询 官方 说 明 ， 我 们 这 里 不 逐一 列 出 。 


显然 ，8859 这 样 的 字符 协议 是 没有 办 法 满足 像 中 文 这 样 的 语言 的 。 
我 们 的 “方块 字 ” 和 英语 语言 有 很 大 区 别 。 英 文 无 论 是 什么 词 ， 都 是 由 
最 基础 的 26 个 字母 组 成 的 。 比 如 “Answer” 这 个 词 在 英文 中 是 由 6 个 字 
母 拼 起 来 的 ;同样 “Question” 也 是 由 字母 组 合 的 。 而 中 文中 不 论 
是 “回答 ”还 是 “问题 ”中 的 任何 一 个 字 ， 都 不 能 拆 分 成 类 似 英文 字母 
这 样 的 组 成 元 素 。 这 就 注定 了 “中 文字 符 集 ”必须 是 足够 庞大 的 ， 才 能 
容纳 下 古往今来 的 所 有 汉语 字符 。 

Unicode 出 现 后 ，1S0/1EC 8859 也 逐步 向 其 靠拢 ， 目 前 它 的 15 个 子 


集 都 可 以 在 Unicode/UCS 中 找到 对 应 项 ; 而 且 原 8859 的 部 分 工作 组 也 已 
经 转向 1S0/1EC 10646。 


16.3 ISO/IEC 10646 


说 到 10646 协 议 大 家 可 能 会 觉得 很 陌生 ， 其 实 它 是 国际 标准 的 一 个 
aS, LEE “Information technology 一 Universal multiple- 
octet coded character set”， 也 就 是 UCS。 这 个 标准 于 1993 年 正式 颁 
布 ， 规 定 了 字符 集 的 总 体 框架 ， 如 表 16-1 所 示 。 

也 就 是 说 ，UCS 可 表达 的 范围 是 128256256*256， 这 是 一 个 非常 大 的 
数值 。 不 过 实际 上 UCS 的 范围 不 能 超过 21bit， 即 0x000000- 

Ox10FFFF 〈 即 1114111) 。 


表 16-1 UCS 的 结构 简 图 


Range oo Ox00-OxFF |IOx00-OxFF lOx00-OxFF 


它 的 第 一 个 平面 “第 0 组 的 第 0 平面 中 的 0x0000-0xFFFD) ， 被 称 
为 “Basic Multilingual Plane” (BMP) 或 者 “Plane 0”， 用 于 容纳 
最 基本 的 字符 。1993 年 发 布 的 1S0 10646-1 添 加 了 BMP 中 的 内 容 ， 而 2001 
ISO 10646-2 版 本 则 进一步 更 新 了 BMP 范围 外 的 内 容 。 到 了 2003 年 ， 这 
两 个 规范 被 合成 为 1S0 10646 标 准 ， 并 仍 在 不 断 完善 中 。 





16.4 Unicode 


前 面 说 过 ，Unicode 是 为 了 容纳 世界 上 所 有 文字 及 符号 而 诞生 的 。 

可 想 而 知 ， 当 时 以 这 个 目标 为 宗旨 创建 的 组 织 肯定 不 止 一 个 。 其 中 ， 最 
有 名 的 就 是 Unicode 和 1S0 中 的 10646 项 目 。 不 过 值得 庆幸 的 是 双方 在 后 
期 都 意识 到 这 个 世界 上 不 应 该 出 现 两 个 不 兼容 的 规范 ， 否 则 就 违背 了 制 
定 世 界 统一 编码 的 初衷 。 于 是 它们 终于 约定 好 协同 工作 ， 且 互 不 干扰 ， 
这 样 就 有 力 地 保证 了 不 兼容 问题 的 出 现 〈 从 Unicode 2. 0 开始 它们 已 经 
兼容 了 ， 因 而 个 人 觉得 没有 必要 纠结 它们 到 底 有 多 大 差异 ， 只 要 了 解 好 
Uni code 协 议 即 可 ) 。 


本 小 节 我 们 主要 讲解 Uni code 的 一 些 基础 知识 。 


Uni code 早 期 是 由 Joe Becker, Lee Collins 等 人 于 1987 年 发 起 研究 
的 ， 并 出 现 于 1988 年 8 月 他 们 为 一 个 系统 所 写 的 提议 中 。 哩 然 当 
时 “Unicode” 已 经 有 其 他 含义 〈 比 如 一 种 编程 语言 ) ， 但 几 位 创始 人 
的 初衷 则 是 “The name 'Unicode' is intended to suggest a 
unique, unified, universal encoding”， 因 而 仍然 沿用 了 这 个 名 
fo 


早期 的 Unicode 只 有 16bit， 在 当时 看 来 这 已 经 足够 使 用 了 ， 至 少 远 
远 超越 了 ASC11 以 及 其 他 一 些 流 行 编码 格式 的 表达 范围 。 随 着 Uni code 的 
不 断 壮 大 与 流行 ， 其 他 字符 编码 与 Unicode 间 的 mapping 也 在 持续 进行 ， 
并 于 1990 年 底 取 得 阶段 性 突破 。1991 年 1 月 3 日 ，Unicode 组 织 成 立 ， 同 
年 10 月 发 布 了 第 一 版 Uni code 标 准 。 至 今 为 止 ，Uni code 已 经 支持 超过 
100 种 语言 以 及 各 种 字符 。 它 的 表达 范围 是 我 们 前 面 提 到 的 0x0- 
0x10FFFF， 即 最 多 可 支持 1114112 个 字符 。 


Unicode 的 优点 是 明显 的 ， 但 也 并 不 是 没有 缺点 。 和 其 他 国际 规范 
一 样 ， 它 也 是 在 不 断 成 长 的 。 比 如 第 一 个 版 本 的 Uni code 是 固定 的 16- 
b it 编码 。 这 样 固然 很 方便 ， 但 对 有 的 字符 来 说 是 不 够 用 的 ， 而 对 于 像 
ASC11 这 种 字符 来 说 却 又 太 浪费 空间 。 另 外 ，UCS 只 是 定义 了 字符 对 应 
的 “Code Point”， 要 想 在 实际 生活 中 取得 广泛 应 用 还 是 有 很 多 问题 要 
解决 的 。 比 如 这 些 数值 在 计算 机 中 如 何 存储 ; 如果 要 在 网 络 上 面 交 互 应 
该 如 何 传输 等 。 于 是 就 有 了 UTF 系 列 规范 ， 如 UTF-8、UTF-16 及 UTF-32。 
下 面 以 UTF-8 为 主 来 讲解 。 


UTF-8 (UCS Transformation Format 8 bit) 是 一 种 可 变 长 度 的 
bs 表示 方法 又 称 “ 万 因 码 。。 最 袖 的 设计 思想 来 源 于 180_10646 中 的 
不 过 当时 这 个 规范 并 不 让 人 满意 。 后 来 《1992 
年 7 月 ) Unix 实 验 室 的 Dave Prosser 提 交 了 一 份 新 的 提议 ， 可 以 看 作 
UTF-8 的 原型 ， 但 仍然 有 较 大 的 缺陷 。 于 是 到 了 1992 年 的 8 月 ，Be1 1 实验 
室 的 Ken Thompson 开 始 对 Dave 的 方案 进行 修正 与 完善 ， 并 最 终 将 这 一 修 
改 于 次 年 的 USENIX 会 议 上 发 表 出 来 ， 这 就 是 UTF-8。 


由 于 历史 因素 ， 各 种 编码 格式 比较 混乱 。 为 了 让 读者 更 清楚 地 理解 
这 些 编码 与 字符 集 的 和 关系 ， 下 面 举 个 例子 来 看 看 UTF 所 要 解决 的 问题 。 


比如 “你 ”的 Unicode 码 是 0x4F60， 我 们 新 建 一 个 文本 文件 ， 写 
入 “你 ”， 并 把 它 以 ANS1 编 码 保存 。 根据 我 们 之 前 的 讲解 ， 可 以 计算 出 
它 将 占用 两 个 字 节 的 大 小 ， 如 图 16-1 所 示 。 





ET 





[Eee “i E3 
AA16-1 占用 两 个 字 节 的 大 小 
如 果 把 它 以 “Unicode” 编 码 格式 保存 ， 如 图 16-2 所 示 。 


r Unicode_Test. tzt 一 记事 本 
净 件 还) AEO BAO) BW HEAD 


VALS 





TS WD: RF (S) 
保存 类 型 (T): [文本 文档 (k. txt) M | 取消 
编码 (E): [Unicode | 


全 图 16-2 “Unicode” 编 码 格 式 保存 
然后 查看 这 个 文件 中 的 二 进 制 ， 如 图 16-3 所 示 。 


56789 a 
I I 1 工 1 aud 


UE Sar a 
o0000000h: FF FE 60 M 





全 图 16-3 文件 中 的 二 进 制 


可 以 看 到 ， 编 码 后 的 数值 是 “0xFFFE604F” 。 
我 们 再 把 这 个 文件 保存 成 UTF-8 格 式 ， 如 图 16-4 所 示 。 


WHS OD): [uni code_Test. txt = 了] {RF (3) 
保存 类 型 T): [文本 文档 (k. txt) 了 | 取消 


编码 E): 





全 图 16-4 文件 保存 成 UIF-8 格 式 


此 时 文件 中 的 编码 数值 如 图 16-5 所 示 。 


ee 
OOO00000h: EF BB BF E4 BD Ad 





从 图 16-5 文件 中 的 编码 数值 
即 “0xEFBBBFE4BDA0”， 也 就 是 高 达 6 个 字 节 。 


后 我 们 把 它 存 成 Unicode big endian， 然 后 看 看 它 的 编码 ， 如 图 
16-6 所 示 。 











oo000000h: awe 

全 图 16-6 Unicode big endian 2 #4 

MiXMIFHP, RINEOAMSHAPILA. 
。 字 节 序 


“你 ”的 Unicode 码 是 0x4F60， 但 在 存储 时 是 高 位 在 前 〈 大 端 ，Big 
Endian) ， 还 是 低位 在 前 呢 “〈 小 端 ，Little Endian) ? 数据 在 传输 过 
程 中 必须 要 考虑 这 个 问题 。 因 为 不 同 的 机 器 很 可 能 采用 的 字 节 序 是 不 一 
样 的 ， 如 果 没 有 相应 的 规范 来 约束 ， 就 很 可 能 导致 致命 问题 。 在 
Unicode 中 ， 这 是 由 BOM (Byte Order Mark) 来 保证 的 。 从 上 面 的 例子 
可 以 看 出 ， 头 两 个 字 节 如 果 是 “0xFFFE” 表 示 小 端 ，0xFEFF 则 代表 大 
Ti o 


。 编码 格式 的 选择 
同一 个 字符 ， 使 用 不 同 编码 格式 得 出 的 数值 是 截然 不 同 的 。 很 多 人 
以 前 可 能 一 直 困 惑 于 UCS 和 UTF 系 列 有 什么 关联 ， 这 就 是 最 好 的 例子 。 选 
择 一 个 好 的 编码 格式 无 疑 可 以 让 整个 系统 更 加 高 效 。 
。 编码 格式 的 标志 
既然 有 不 同 的 编码 格式 可 选 ， 那 么 在 对 字符 进行 解码 时 ， 自 然 也 要 
采取 对 应 的 编码 标准 。 这 就 引出 了 另 一 个 问题 : 如 何 知 道 一 个 字符 采用 
了 什么 编码 格式 ? 通常 我 们 用 Unicode 保 存 文件 时 ， 它 会 在 文件 开头 加 
上 编码 标志 。 如 下 所 示 : 
ANS1: 没有 标志 
Unicode: OxFFFE (Little Endian) 
Unicode Big Endian: OxFEFF 
UTF-8: OxEFBBBF 
可 见 ， 只 有 UTF-8 的 标志 头 占 用 了 超过 两 个 字 节 的 大 小 。 
。 可 变 长 度 
我 们 知道 UTF-8 是 可 变 长 度 的 ， 即 一 个 字符 占 多 少 字 节 并 不 是 固定 


的 。 那 么 在 一 堆 编 码 后 的 数值 中 ， 如 何 准 确 珊 定 每 个 字符 的 结束 位 置 
呢 ? UTF-8 规 范 中 给 出 了 如 表 16-2 所 示 的 转换 表 。 


表 16-2 UTF-8 编 码 规则 





Unicode 编 码 〈 十 六 进 制 ) UTF-8 (二 进 制 |》 





[Zone2: 0x000080 - |i toxxxxx 10xxxxxx | 


i | | 


11110xxx 10xxxxxx 10xxxxxx 
10xxxxxx 





:证 二 
9 注意 


最 初 的 UTF-8 协 议 规定 可 用 bit 是 可 以 达到 31 位 以 上 的 ， 所 以 部 
分 参考 书 中 给 出 的 UTF-8 最 长 是 由 6 个 字 节 〈 因 为 还 有 一 些 Leading 
Byte, FAENA) 来 表示 的 。 到 了 2003 年 11 月 ，RFC3629 限 
制 了 这 个 范围 ， 即 只 能 到 0x10FFFF， 因 而 起 过 四 字 节 的 部 分 就 被 移 
除了 ; 而 且 Zone4 所 能 表达 的 范围 也 降低 了 一 部 分 (Zone4 中 的 x 有 
21 个 bit 位 ， 最 大 可 表达 0x1FFFFF， 目 前 只 用 到 0x10FFFF) 。 


表 16-2 右 边 : UTF-8 中 的 x 是 需要 根据 具体 要 表达 的 Unicode 字 符 进 
行 填 写 的 。 比 如 前 面 的 例子 ， 因 为 “你 ”的 Unicode 码 是 
0x4F60=0100111101100000， 属 于 第 Zone3 区 域 ， 因 而 转换 后 的 值 是 : 


11100100 10111101 10100000=0xE4BDA0 
这 和 我 们 前 面 所 看 到 的 结果 是 一 致 的 。 


从 Zone2 开 始 ， 每 个 区 域 的 字符 都 以 一 个 “Leading Byte” 起 头 ， 
它们 的 高 位 都 是 由 多 个 “1” 最 后 跟随 “0” 来 表示 的 ， 而 且 “1 ”的 数 
量 同时 也 等 于 该 字符 点 用 空间 的 大 小 比如 Zone3 有 3 个 “1”， 它 的 字 
符 是 由 3 个 字 市 来 表示 的 。 “Leading Byte” 后 面 的 字 节 称 
为 “Continuation Bytes”。 可 以 看 到 ， 它 们 都 以 “10 ”开头 。 


因为 每 个 区 域 的 开头 标志 是 不 同 的 ， 并 且 相 互 间 不 会 有 歧义 ， 所 以 


保证 了 UTF-8 表 示 的 字符 可 以 被 正确 解析 。 
如 图 16-7 所 示 〈 是 不 是 有 点 像 Haffman 编 码 ) 。 


全 图 16-7 二 又 树 


这 样 解 码 时 就 可 以 准确 知道 这 个 字符 属于 哪个 区 域 ， 也 就 知道 它 占 
用 几 个 字 节 了 。 这 种 特性 称 为 “Se1f-Synchronizing”， 使 得 我 们 在 处 
理 一 个 UTF-8 码 时 不 需要 加 入 特定 的 “ 头 信 息 ” 就 可 以 正确 解析 出 它 所 
表达 的 字符 一 一 这 同时 也 是 它 能 获得 广泛 应 用 的 一 个 重要 “法 宝 ”。 


顺便 说 一 下 ，UCS-2 是 早期 的 标准 ， 即 Unicode 编 码 固 定 以 两 个 字 节 
表示 字符 ; 而 UCS-4 则 是 以 国定 长 度 的 4 字 节 来 表示 一 个 字符 。UCS-2 因 
为 没有 办 法 提供 足够 的 空间 容纳 越 来 越 多 的 字符 数量 ， 因 而 逐步 被 UTF- 
16 所 代替 。 实 际 上 我 们 平常 所 见 到 的 Unicode 一 般 都 是 UTF-16， 如 前 面 
例子 中 Wi ndows 文 本 保存 时 的 选项 “Unicode”。 哩 然 很 容易 引起 歧义 和 
混淆 ， 但 是 人 们 已 经 养 成 了 习惯 ， 请 读者 一 定 要 注意 区 分 。 


那么 ，UTF-16 为 什么 能 解决 UCS-2 的 缺陷 呢 ? 


首先 要 清楚 ，UTF-16 也 是 变 长 的 。 具 体 来 说 ， 一 个 字符 既 可 能 是 
个 字 节 ， 也 可 能 是 4 个 子 节 ， 当 然 编码 范围 还 是 0x000000-0x10FFFF。 那 
么 和 UTF-8 遇 到 的 问题 一 样 ， 在 解析 时 我 们 如 何 知 道 一 个 字符 到 搬 是 用 
两 个 字 节 还 是 4 个 子 贡 表示 的 呢 ? 


UTF-16 的 基本 规则 如 下 。 


o 当 编 码 范 围 在 0x0000-0xFFFF 时 ， 只 占用 两 个 字 节 。 
。 当 编码 范围 超过 上 述 区 域 ， 即 在 0x10000-0x10FFFF 时 ， 需 要 4 个 字 节 
表示 。 为 了 正确 区 分 两 字 节 和 四 字 节 编码 ， 需 要 特别 预 留 出 
0xD800-0xDFFF 作 为 代理 区 域 (Surrogate) 。 其 中 0xD800-0xDBFF 
是 高 代理 ， 而 0xDC00-0xDFFF 是 低 代 理 ， 两 个 代理 组 成 的 4 个 字 节 
FARRAR DS FH: 

OxD800= 1101100000000000 

OxDBFF=1101101111111111 


OxDCOO=1101110000000000 
OxDFFF=1101111111111111 


解析 时 ， 高 低 代理 取出 各 自 低 10 位 ， 分 别 作为 数值 的 高 低 10 位 ， 然 
后 加 上 0x10000， 融 是 此 UTF-16 所 要 表达 的 字符 。 因 为 代理 所 用 的 数值 











范围 与 前 述 2 个 字 节 表示 的 字符 不 重复 ， 因 而 我 们 可 以 判断 出 此 字符 到 
帮 是 2 字 节 还 是 4 字 贡 编码 。 另 外 根据 上 面 的 描述 ， 使 用 代理 机 制 所 能 表 
示 的 字符 区 域 是 : 


0000000000 0000000000 (二 进 制 ， 高 低 代 理 末 10 位 〉+0x10000- 
1111 1111 1111 1111 1111 (OxFFFFF) +0x10000， 也 就 是 : 


0x10000-0x10FFFF， 这 正好 符合 Unicode 所 能 表达 的 区 域 范围 。 


因为 是 多 字 节 存储 ， 就 会 涉及 字 节 序 问题 ， 分 为 UTF-16LE 和 UTF- 
16BE， 这 两 种 分 别 对 应 前 面 的 Unicode 和 Unicode Big Endian。 


16.5 String A! 


String 类 型 是 我 们 在 编写 Java 和 Android 应 用 程序 时 使 用 非常 广泛 
的 一 个 类 。 它 提供 了 各 种 便捷 的 封装 接口 让 开发 者 轻松 处 理 字符 串 数 
据 。 这 个 看 似 不 显眼 的 类 实际 上 是 “ 麻 八 哩 小 ， 五 脏 俱 全 ”一 一 因而 深 
入 分 析 Str ing 对 于 我 们 理解 字符 编码 大 有 宰 益 。 


先 来 看 看 Android 官 方 文档 对 Str ing 的 描述 : 


“An immutable sequence of characters/code units (chars). A String 


也 就 是 说 ，String 内 部 对 字符 采用 的 存储 格式 是 UTF-16。 有 具体 而 
言 ， 它 有 一 个 char 数 组 类 型 的 全 局 变量 value。 


private final char[] value; 
所 有 对 字符 串 的 操作 都 是 以 此 为 基础 的 。 
16.5.1 构建 String 


String 提 供 了 多 种 构造 函数 以 满足 开发 者 不 同方 面 的 需求 。 比 如 : 


String(); 

String(byte[] data); 

String(byte[] data, int high); 

String(byte[] data, int offset, int byteCount); 

String(byte[] data, int high, int offset, int byteCount); 
String(byte[] data, int offset, int byteCount, String charsetName 
String(byte[] data, String charsetName) ; 

String(byte[] data, int offset, int byteCount, Charset charset); 
String(byte[] data, Charset charset); 

String(char[] data); 

String(char[] data, int offset, int charCount); 

String(String toCopy); 

String(StringBuffer stringBuffer ); 

String(int[] codePoints, int offset, int count); 
String(StringBuilder stringBuilder ); 


另外 ，Android 还 提供 了 其 他 辅助 类 来 创建 String 对 象 ， 如 
StringBuffer 和 StringBuilder。 


StringBuffer 字符 串 变 量 ， 它 生成 的 对 象 是 可 以 动态 修改 的 。 比 
如 下 面 这 段 代 码 : 


List<String> values = splitByNullSeperator((String) value); 
StringBuffer sb = new StringBuffer(); 
for(int i=0;i<values.size();i++) 


if(i!=0) 
{ 

sb.append("\u0Q000") ; 
sb.append(values.get(1)); 


return sb.toString(); 


StringBuffer 提 供 了 append 方 法 来 追加 字符 串 ， 这 个 接口 也 有 多 种 
参数 形式 。 比 如 : 


append(char[] chars, int start, int length); 
append(long 1); 

append(int i); 

append(String string); 


用 于 满足 不 同类 型 的 数据 转换 成 字符 串 的 需求 。 另外 它 还 提供 
delete，insert， 并 可 以 通过 toStr ingly 
内 部 数据 转换 成 String 类 型 变 


StringBui 1der 所 能 提供 的 接口 方法 和 Str ingBuffer 几乎 一 样 ， 那 
么 两 者 有 什么 本 质 区 别 呢 ? 我 们 来 分 别 看 看 Android 对 于 它们 的 解释 。 


StringBuffer : 


“A modifiable sequence of characters for use in creating 
strings, where all accesses are synchronized. This class has 
mostly been replaced by StringBuilder because this 
synchronization is rarely useful.” 


StringBuilder: 


“A modifiable sequence of characters for use in creating 
strings. This class is intended as a direct replacement of 
StringBuffer for non-concurrent use; unlike StringBuffer this 


class is not synchronized. ” 
也 就 是 说 ，StringBuffer 是 线程 安全 的 ， 而 Str ingBui lder 则 是 针 
对 单线 程 的 情况 设计 的 ， 可 以 理解 为 StringBuffer 的 特例 。 因 为 
StringBui 1der 没 有 同步 机 制 ， 所 以 如 果 是 多 线程 的 环境 ， 建 议 使 用 
StringBuffer 。 不 过 按照 官方 的 解释 ， 需 要 同步 的 情况 并 不 多 见 ， 所 以 
鉴于 StringBui lder 的 执行 速度 更 快 ， 它 大 有 取代 前 者 的 趋势 。 开 发 人 
员 应 该 根据 项 目的 实际 需求 来 选择 合适 的 辅助 类 。 
16.5.2 String 对 多 种 编码 的 兼容 
从 前 面 几 个 小 节 的 分 析 ， 我 们 知道 String 是 以 UTF-16 来 存储 数据 
那么 如 果 原 本 的 字符 编码 并 不 是 这 种 格式 的 ， 就 难免 要 先进 行 转 
String 类 的 构造 函数 已 经 考虑 到 这 种 情况 ， 比 如 : 
public String(byte[] data, int offset, int byteCount, Charset cha 
参数 中 data 是 原始 数据 ，Charset 是 指数 据 的 编码 格式 。 
Char set 用 于 Uni code 字 符 与 byte 字 节 流 之 间 的 转换 。 具 体 来 说 : 
e Decode 
这 是 Charset 的 基础 工作 ， 因 而 要 求 必 须 支持 。 


Encode 


部 分 Charset 还 支持 编码 工作 ， 可 以 通过 canEncode () 来 查询 。 
Android 系 统 内 置 了 以 下 几 种 Charset。 

1S0-8859-1: 可 以 参照 前 面 的 介绍 

US-ASCI1: ASC11 编 码 


UTF-16 


UTF—16BE 


UTF—-16LE 


UTF-8: UTF 的 这 几 种 编码 格式 在 前 一 个 小 节 也 都 有 详细 分 析 ， 不 再 


述 


接 下 来 我 们 通过 上 述 String 构 造 函数 的 内 部 实现 来 进一步 理解 这 些 
编码 间 的 转换 过 程 : 


public String(byte[] data, int offset, int byteCount, Charset 
if ((offset | byteCount) < © || byteCount > data.length - 
throw failedBoundsCheck(data.length, offset, byteCoun 
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String canonicalCharsetName = charset.name();// 编 码 格式 
if (canonicalCharsetName.equals("UTF-8")) { 
…// 后 面 详细 分 析 
} else if (canonicalCharsetName.equals("ISO-8859-1")) { 
…// 代 码 略 
} else if (canonicalCharsetName.equals("US-ASCII")) { 
…// 代 码 略 
} else { 
CharBuffer cb = 
this.offset = 0; 
this.count = cb.length(); 
if (count > 0) { 
this.value = new char[count]; 
System.arraycopy(cb.array(), ©, value, ©, count); 
} else { 
this.value = EmptyArray.CHAR; 
} 


charset ,decode(ByteBuffer .wrap(data， 


} 


整个 函数 分 为 两 部 分 ， 如 果 原 始 数据 是 UTF-8，1S0-8859-1 或 者 US- 
ASC11 中 的 任何 一 种 ， 都 会 直接 进行 转换 处 理 ; 否则 调用 charset 变 量 本 
身 的 decode 方 法 进行 解码 。 


UTF-8 是 这 几 种 处 理 中 最 复杂 的 一 个 ， 我 们 来 具体 分 析 下 : 


byte[] d data; 

char[] v new char[byteCount ]; 
int idx = offset; 

int last = offset + byteCount; 


int s = 0; 


上 面 几 个 变量 ，d 是 原始 数据 ，v 是 将 要 在 String 中 存储 的 UTF-16 的 
编码 结果 ，idx 和 1ast 分 别 是 原始 数据 中 被 处 理 部 分 的 起 止 位 置 。 


由 于 UTF-8 是 可 变 字 贡 的 编码 方式 ， 因 而 最 为 关键 的 是 确认 一 个 字 
符 的 结束 位 置 。 下 面 的 主 循环 将 逐一 处 理 data 中 从 [0, last] TF 
列 ， 并 依据 前 一 小 节 讲 解 的 UTF-8 几 个 区 域 标志 码 确定 每 个 字符 的 字 长 
大 小 。 为 了 方便 读者 阅读 ， 我 们 再 把 这 个 表 列 出 来 ， 如 表 16-3 所 示 。 


表 16-3 ”确定 每 个 字符 的 字 长 大 小 


Unicode 编 码 〈 十 六 进 制 ) UTF-8 (二 进 制 》 


110xxxxx 10xxxxxx 


11110xxx 10xxxxxx 10xxxxxx 
10xxxxxx 





主 循环 代码 如 下 : 


outer: 
while (idx < last) { 
byte bo = d[idx++]; 
if ((bO & 0x80) == 0) { 
int val = bO & Oxff; 
v[st+] = (char) val; 


当 字 节 最 高 位 为 时， 说明 它 是 ASC11 码 ( 表 中 的 Zone1) ， 因 而 只 
一 个 字 节 。 处 理 时 只 要 将 这 个 字 节 存 入 v 变 量 中 即 可 : 


} else if (((bO & 0xe0) == OxcO) || ((bO & OxfO) == 0xe0) || 
((bO & Oxf8) == 0xf0) || ((bO & Oxfc) == Oxf8) || ((bO & Oxfe 


9 注意 
上 面 的 b0 是 变量 ， 不 是 十 六 进 制 的 pb0。 


0xe0=11100000，0xc0=11000000， 当 第 一 个 等 号 成 立时 ， 表 示 
Zone2。 


0xf0=11110000，0xe0=11100000， 当 第 二 个 等 号 成 立时 ， 表 示 
Zone3。 


0xf8=11111000，0xf0=11110000， 当 第 三 个 等 号 成 立时 ， 表 示 
Zone4。 


后 面 的 几 个 等 号 分 另 人 前 一 个 小 节 我 们 已 经 解释 
这 是 针对 早期 版 本 的 处 理 ， 因 而 可 以 跳 过 


int utfCount = 1; 

if ((bO & Oxf0) == Oxe0 ) utfCount = 2; 
else if ((bO & Oxf8) == OxfO) utfCount 
else if ((bO & Oxfc) == Oxf8) utfCount 
else if ((bO & Oxfe) == Oxfc) utfCount 


Woe al 
ob Ww 


~ 


这 里 的 utfCount 表 示 “Continuation Bytes” 的 个 数 ， 因 为 前 面 
idx 已 经 自 增 了 ， 而 “Leading Byte” 用 b0 来 表示 : 
if (idx + utfCount > last) { 


v[st+] = REPLACEMENT_CHAR; 
break; 


当 idx+utfCount 超 过 数据 边 开 时， 说 明 数据 有 错误 ， 跳 出 循环 。 
REPLACEMENT_CHAR = (char) Oxfffd: 


int val = bO & (Ox1if >> (utfCount - 1)); 


for (int i 0; i < utfCount; i++) { 
byte b d[idx++]; 
if ((b & OxCO) != 0x80) { 
v[st+] = REPLACEMENT_CHAR; 
1dx--; 
continue outer; 


val <<= 6; 
val |= b & Ox3f; 


上 面 这 段 代码 用 于 取出 UTF-8 中 的 数据 部 分 。 


。 首先 ， 取 出 Leading Byte 即 b0 中 的 有 效 数 据 。 

e 根据 utfCount 的 数量 ， 逐 一 取出 剩余 Continuation Bytes 中 的 有 效 数 
据 。 因 为 这 些 字 市 的 首 两 位 必须 是 10， 所 以 b&0xC0 等 于 0x80， 否 则 
数据 无 效 。 最 后 将 它们 统一 拼接 成 UTF-16 值 。 

上 面 的 计算 还 没有 考虑 数值 超过 两 个 字 节 的 情况 〈 因 为 val 是 int 类 
型 ， 足 够 容纳 所 有 范围 的 数值 ) ， 所 以 接 下 来 还 要 进一步 判断 : 
if ((utfCount != 2) && (val >= OxD800) && (val <= OXxDFFF)) { 


v[st+] = REPLACEMENT_CHAR; 
continue; 


假如 数值 大 小 超过 两 个 字 节 ， 那 么 必须 使 用 代理 : 
if (val > Ox10FFFF) { 
v[st+] = REPLACEMENT_CHAR; 
continue; 
先 检 查 va1 是 否 大 于 Uni code 所 能 表达 的 范围 ， 即 0x10FFFF 。 
然后 对 Zone4 部 分 采用 代理 模式 进行 编码 : 


if (val < 0x10000) { 
v[s++] = (char) val; 


} else { 
int x = val & Oxffff; 
int u = (val >> 16) & Ox1f; 
int w = (u - 1) & Oxffff; 


int hi = 0xd800 | (w << 6) | (x >> 10); 
int lo = OxdcOO | (x & Ox3fFf); 
v[st+] = (char) hi; 
v[st++] = (char) lo; 
} 
} else { 


// Illegal values Ox8*, QOx9*, Oxa*, Oxb*, Oxfd-OxfFf 


v[s++] = REPLACEMENT_CHAR; 


最 后 ， 把 上 述 处 理 结果 存 入 String 的 value 数 组 中 。 因 为 byteCount 
是 用 户 通 过 传 参 进来 的 ， 如 果 计 算出 的 结果 和 这 个 参数 值 一 致 ， 那 么 可 


以 直接 保存 结果 ， 否 则 还 需要 重新 申请 合适 的 空间 进行 复制 : 


if (s == byteCount) { 
this.offset = 0; 
this.value 
this.count 
} else { 
this.offset = 0; 
this.value = new char[s];// 重 新 申请 空间 
this.count = s; 
System.arraycopy(v, 0, value,，0，Ss);// 复 和 


V; 
S; 





F 
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其 他 几 种 编码 比较 简单 ， 读 者 可 以 自行 阅读 理解 。 


Android 和 OpenGL ES 


在 本 书 显 示 系 统 的 学 习 中 ， 读 者 应 该 已 经 发 现 无 论 是 Surface、 — 
SurfaceFlinger 还 是 View 体 系 ， 都 直接 或 间接 地 以 0penGL ES 为 设计 核 
Lo 


一 方面 ，0penGL ES 在 Andro id 系统 中 起 到 了 重要 作用 ; 而 另 一 方 
面 ， 并 不 是 所 有 读者 都 深 请 0penGL ES 〈 根 据 Android 项 目 经 验 ， 不 少 开 
发 者 在 理解 显示 系统 时 的 最 大 阻力 就 是 缺乏 0penGL 基 础 一 鉴于 此 ， 本 章 
将 有 目的 性 地 引导 读者 学 习 与 Android 设 计 相 关 的 那 部 分 0penGL ES 知 
识 。 


OpenGL (Open Graphics Library) 最 初 是 由 SG1 (Silicon 
Graphics Inc.) 公司 开发 的 。 发 展 到 今天 ， 它 已 经 占据 了 包括 虚拟 现 
实 、CAD、 能 源 、 游 戏 研发 等 多 个 行业 领域 ， 成 为 名 副 其 实 的 跨 语 言 、 
跨 平 台 的 2D/3D 图 形 处 理 “ 王 者 ”。 


0penQL 的 管理 者 为 Khronos 组 织 ， 这 是 一 个 2000 年 成 立 的 ， 由 ATI1、 
Intel、NVIDIA、SG1、SUN 等 行业 内 领先 企业 发 起 的 非 营 利 性 联盟 。 目 
前 其 旗下 已 经 分 为 若干 个 工作 组 ， 具 体 如 下 所 列 。 


e OpenGL: 跨 平 台 的 计算 接口 。 

e OpenGL SC: 应 用 于 对 安全 有 和 较 高 需求 的 OpenGL ES 市 场 。 

e OpenKODE: 提供 了 访问 文件 系统 、 网 络 之 类 的 操作 系统 资源 的 接 
= 

e OpenGL ES: 本 章节 的 主角 。 它 是 专门 面向 于 褒 入 式 领域 的 。 


EGL: 它 是 Rendering API (比如 OpenGL ES) 和 本 地 窗口 平台 之 间 
的 一 个 接口 层 。 

OpenGL VG: 用 于 2D 向 量 图 的 处 理 加 速 。 

OpenML: 用 于 数字 媒体 的 捕获 、 传 输 、 处 理 、 显 示 和 同步 等 。 
WebGL: 浏览 器 中 绑 定 的 OpenGL ES 的 一 个 JavaSctipt 脚 本 。 

Vision: 用 于 图 形 显示 的 硬件 加 速 。 


0penGL 的 运行 对 设备 要 求 较 高 ， 很 难 被 直接 应 用 在 CPU 和 内 存 资源 
医 乏 、 用 电量 需要 严格 控制 甚至 没有 浮 点 数 硬件 协助 的 家 入 式 设备 上 
于 是 0penGL ES 应 运 而 生 。 





OpenGL ES (OpenGL for Embedded Systems) 是 由 Khronos 推 出 
AW, HARAR AA OpenGL AP1 子 集 。 目 前 已 经 成 功 应 用 于 
PDA、 汽 车 电子 、 手 机 等 一 系列 电子 产品 中 ，Android 系 统 也 是 从 版 本 早 
期 就 开始 支持 这 一 图 形 库 。 它 不 仅 可 以 为 Android 开 发 者 提供 3D 图 形 的 
实现 ， 也 同样 广泛 应 用 于 2D 的 视频 与 图 像 处 理 。 其 强大 的 泻 染 和 特效 处 
理 功 能 ， 可 以 无 限 扩展 应 用 开发 者 的 想象 力 。 


OpenGL ES 相 较 于 0penGL， 在 设计 上 至 少 需 要 考虑 以 下 几 点 。 


。 尺 量 精简 实现 方式 。 比 如 在 OpenGIL 中 可 以 找到 一 种 问题 的 N 个 解 
法 ， 而 在 OpenGL ES 版 本 中 可 能 只 被 允许 使 用 固定 的 一 种 。 

。 保证 兼容 性 。 不 仅 是 OpenGLES 版 本 间 的 兼容 ， 也 要 考虑 OpenGL 
ES 与 OpbenGL 主 版 本 间 的 兼容 。 

。 不 断 改 进 。 特 别 是 根据 硬件 的 升级 来 完善 自身 。 


到 目前 为 止 ，Android 系 统 支持 OpenGL ES 1.0, 1.1 (从 Android 
1. 0 开始 ) , 2.0 (MAndroid 2.2, Level 8 开始 ) ， 以 及 3.0 (Android 
4.3, API level 18 开 始 ) 的 AP1。 那 么 ， 这 几 个 版 本 有 什么 区 别 呢 ? 


根据 Khronos 的 解释 ，1. X 版 本 的 0penGL ES 是 “For fixed 
function hardware”， 而 2.X 则 是 “For programmable hardware” , 
因而 它们 最 大 的 差异 就 是 后 者 属于 “programmable”。 可 编程 的 特性 可 
以 极 大 地 扩展 图 形 硬件 的 功能 以 及 灵活 性 。3. X 版 本 加 入 了 更 多 新 特 
性 ， 如 着 色 语 言 的 完善 、 支 持 更 多 缓冲 区 对 象 、 支 持 几何 体 实例 化 、 统 
一 的 纹理 压缩 格式 等 。 这 些 新 特性 不 但 可 以 让 3D 男 面 更 加 流畅 和 绚丽 ， 


而 且 研 发 者 的 工作 也 相对 简单 了 。 不 过 这 些 新 功能 并 不 影响 我 们 分 析 
Android 的 内 部 原理 ， 有 兴趣 的 读者 可 以 自行 参阅 资料 。 


相对 于 其 他 AP1 而 言 ，Google 针 对 0penGL ES 的 官方 指南 还 不 是 很 
人 一 个 声明 体 而 没有 任何 释义 。 这 对 初学 者 


造成 一 定 的 困难 ， 为 此 我 们 将 先 从 图 形 处 理 的 基础 知识 讲 起 ， 有 再 
过 渡 到 0penGL。 


17.1 3D 图 形 学 基础 
17.1.1 计算 机 3D 图 形 
什么 是 计算 机 3D 图 形 ? 


3D 这 个 词 出 现 的 频率 如 此 之 高 ， 以 至 于 很 多 时 候 我 们 会 对 它 “ 熟 视 
无 睹 ”一 一 但 真正 让 我 们 来 解释 ， 相 信 并 不 是 所 有 人 都 能 答 得 上 来 。 从 
字面 意思 来 看 ， 它 是 指 Three-Dimensional， 即 三 维 的 图 形 。 一 般 情 况 
下 ， 即 指 长 、 宽 和 深度 (GE) 3 个 维度 。 


随 着 计算 机 系统 的 不 断 发 展 ， 计 算 机 输出 结果 的 方式 从 早期 的 纸 质 
打印 到 后 来 的 CRT、 液 晶 等 发 生 了 翻天 覆 地 的 变化 。 但 有 一 点 却 是 始终 
不 变 的 ， 即 它们 实际 上 都 是 平面 二 维 的 。 换 句 话 说 ， 即 便 我 们 所 说 的 计 
算 机 中 的 3D 图 形 ， 也 只 是 在 2D 屏 幕 上 创造 出 来 的 立体 效果 。 


.那么 问题 的 关键 就 在 于 ， 如 何 才能 在 二 维 的 界面 上 制造 出 三 维 


o 


的 


要 解答 这 个 问题 ， 我 们 有 必要 先 分 析 下 人 类 是 如 何 感知 到 3D 物 体 
的 ， 如 图 17-1 所 示 。 





全 图 17-1 人 了 眼 感 知 3D 物 体 


从 简 图 可 以 知道 : 


。 光线 是 感知 物体 的 基础 ， 在 黑暗 的 环境 下 人 了 眼 是 无 法 看 清 东 西 的 。 

。 人体 有 左右 两 个 眼球 ， 并 且 两 者 之 间 有 一 定 间 距 ， 这 样 它们 可 以 从 
不 同 的 角度 来 获取 到 一 个 物体 的 信息 。 这 些 信息 在 传输 到 两 个 眼球 
时 是 有 略微 差别 的 ， 再 经 过 大 脑 的 处 理 后 ， 便 形成 了 物体 的 三 维 效 
果 。 看 到 这 里 有 的 读者 可 能 会 想 ， 如 果 是 这 样 ， 那 么 我 闭 上 一 只 了 眼 
睛 看 到 的 物体 不 是 变 成 了 2D 吗 ? 答案 当然 是 否定 的 。 因 为 虽然 这 
时 只 有 一 只 眼球 在 接收 信息 ， 但 它 还 是 可 以 通过 其 他 信息 来 判断 物 
体 是 否 具 有 深度 〈 第 三 维度 ) 比如 近 的 对 象 看 起 来 会 比较 大 ， 
而 远 的 物体 看 起 来 小 ， 还 有 光影 效果 、 颜 色 变化 等 都 可 以 为 眼球 产 
生 三 维 感 觉 提供 信息 。 这 同时 也 是 我 们 在 计算 机 图 形 中 可 以 创造 人 
工 3D 效 果 的 基础 之 一 。 


还 有 一 点 可 以 肯定 的 是 ， 随 着 人 闭 上 其 中 一 只 眼睛 ， 辨 识 物体 深度 
的 能 力 将 大 大 降低 。 读 者 可 以 做 个 试验 ， 将 两 只 圆珠笔 放 在 眼前 ， 然 后 
闭 上 其 中 一 只 眼 ， 这 时 如 果 想 把 两 只 笔 的 笔头 碰 在 一 起 是 不 是 困难 了 很 
多 ? 这 是 因为 仅 靠 一 只 眼 ， 已 经 很 难 通过 左右 两 眼 的 “图 像 差 ”来 获知 
物体 的 深度 距离 了 。 


对 于 显示 在 计算 机 屏幕 上 的 图 像 来 说 ， 它 没有 办 法 从 不 同 的 角度 为 
两 个 眼球 提供 有 差异 的 图 像 〈 办 法 其 实 是 有 的 ， 如 现在 非常 流行 的 30 电 
影 ， 就 是 通过 把 影片 中 两 幅 欠 加 的 图 像 ， 经 由 3D 眼 镜 分 离 出 来 而 产生 立 
体 特效 。 但 是 这 种 方式 显然 不 适用 于 计算 机 场合 ) ， 因 而 必须 要 有 其 他 
的 人 工 方式 。 除 了 上 述 提 到 的 光影 效果 等 一 系列 方法 外 ， 还 有 一 种 很 简 
单 的 方式 是 我 们 初中 学 习 几 何 时 就 用 过 的 一 一 透视 ， 如 图 17-2 和 图 17-3 
所 示 。 









































全 图 17-2 利用 透视 产生 立体 效果 





全 图 17-3 利用 光影 产生 三 维 效果 


通过 以 上 两 种 效果 ， 读 者 是 否 感知 到 了 立体 图 形 ? 这 样 我 们 的 目的 
就 达到 了 。 


17.1.2 图形 管线 


在 计算 机 图 形 处 理 中 ， 任 何 复杂 的 图 像 都 可 以 由 固定 数量 的 基础 几 
何 元 素 ， 通 过 一 系列 手法 逐步 加 工 出 来 。 以 0penGL ES 为 例 ， 它 只 支持 3 
种 基本 的 几何 元 素 ， 即 : 


e 点 (Point) ; 
e 线段 (Line) ; 
。 三 角形 (Triangle) 。 


图 形 管线 (Graphics Pipeline 或 者 Rendering Pipeline) 通常 是 
指 图 形 硬件 设备 (GPU) 支持 的 演 染 流程 。 简 单 地 说 ， 它 是 以 3D 数 据 为 
输入 “比如 游戏 场景 的 描述 ) ， 并 最 终 输出 2D 光 栅 图 形 的 一 种 流水 线 处 
理 过 程 。 前 面 已 经 说 过 ， 虽 然 从 理论 上 来 说 是 三 维 图 形 ， 但 实际 上 绝 大 
多 数 用 户 都 是 在 二 维 的 终端 显示 屏 上 〈 比 如 PC 的 显示 器 ) 观看 3D 效 果 
的 ， 因 而 就 必然 有 3D2D 的 转化 过 程 。 而 之 所 以 说 是 流水 线 ， 因 为 它 的 处 
理 过 程 符合 工厂 中 产品 的 流水 线 生 产 顺序 。 当 今 最 流行 的 两 种 3D 接 口 ， 
即 0penGL 和 Direct3D 都 有 自己 定义 的 管线 ， 本 小 节 我 们 只 分 析 与 0penGL 
相关 的 实现 。 


图 17-4 展 示 了 1. X 版 本 的 0penGL ES 的 Pipeline。 

2. X 版 本 的 Pipeline 有 一 些 差 异 ， 如 图 17-5 所 示 。 

从 这 两 个 图 的 对 比 中 ， 我 们 可 以 知道 : 

2 又 系列 的 管线 模型 更 加 精简 

因为 它 支 持 可 编程 的 方式 ， 这 样 原本 ES 1. 1 中 一 些 用 Shader 


A REMAS; 同时 降低 了 硬件 的 成 本 以 及 能 量 消 





e 增加 了 OpenGL ES Shading Language 


它 和 0penGL 中 的 Shading 编 程 语言 基本 上 一 致 ， 只 不 过 针对 岁入 式 


系统 做 了 些 优 化 。 


Existing Fixed Function Pipeline 


Triangles/Lines/Potnts 


Primitive Transform and Primitive 
Processing Lighting Assembly 


Texture 
Environment 










Colour 
Buller 
Blend 





全 图 17-4 OpenGL ES 1.X Pipeline (i: 4] Jf)  http://www.khronos.org/opengles/2_X/. ) 





ES2.0 Programmable Pipeline 
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Primitive 
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Primitive 
Processing 





A 17-5 OpenGL ES 1.X Pipeline ( 注 : 4] A) Á http://www.khronos.org/opengles/2_X/. ) 


下 面 的 链接 是 了 解 各 系列 0penGL ES 中 AP1 的 重要 文档 ， 建 议 读者 认 
真 阅读 一 下 。 


OpenGL ES 3.0.2 Specification: 





http://www. khronos. org/registry/gles/specs/3. 0/es_spec_3. 0. 
OpenGL ES 2.0.25 Full Specification: 

http://www. khronos. org/registry/gles/specs/2. 0/es_ful|l_spec 
OpenGL ES 1.1.12 Full Specification: 

http://www. khronos. org/registry/gles/specs/1.1/es_ful|l_ spec 
EGL 1.4 Specification: 

http://www. khronos. org/registry/eg|/specs/eglI spec. 1. 4. 2011( 
EGL 1.4 Header File: 

http://www. khronos. org/registry/eg|/api/EGL/eg|.h 

EGL 1.4 Extension Header File: 


http://www. khronos. org/registry/eg|/api/EGL/eglext. h 


17.2 Android 中 的 0penGL ES 简介 

代码 路 径 : 

e frameworks\base\opengl 
Java 层 SDK。 

e frameworks\base\core\jni 
JN1 层 实现 。 

e frameworks\native\opengl 
C++ 代码 实现 。 

e external\mesa3d 
Mesa 3D5|= =. 


我 们 知道 ，Android 系 统 中 采用 了 0penGL ES。 上 有 具体 实现 中 包括 如 下 
几 个 部 分 


e OpenGL ES 
a 0penGL 本 身 只 是 协议 规范 ， 而 不 是 软件 源码 库 ， 这 一 点 要 特别 注 
e EGL 


读者 EGL 可 全 BE 比较 卫生， ‘x “Khronos Native Platform 
Graphics Interface” AYZ is “ 即 介 于 本 地 窗口 系统 和 Rendering 
API 《这 里 是 指 0penGL ES) 之 间 的 一 层 接 口 。EGL 主 要 负责 图 形 环境 管 
surface/buffer 绑 定 、 演 染 同步 等 。 本 节 接 下 来 还 会 有 详细 的 解 
jil 


下 面 这 个 网 址 有 EGL 官 方 的 一 些 介绍 资料 ， 建 议 读者 先 阅读 下 。 


http://cn. khronos. org/eg|. 
e Mesa 3D 


Mesa 是 兼容 0penGL 协 议 的 30 图 形 处 理 软件 库 ; 同时 还 是 开放 原始 代 
码 的 〈 不 过 是 基于 MIT License) ， 如 图 17-6 所 示 。 


Application 


GLSurfaceView GLES20... 
GLES30... 


Framework 


libag] libhgl 


Lib 


Hardware 
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下 面 打 个 比方 ， 以 帮助 读者 理 清 这 些 模 块 之 间 的 关系 。0penGL ES 
就 像 打印 机 的 标准 一 样 ， 如 它 规定 了 printline (point1，point2) 这 
个 接口 是 用 于 打印 一 条 从 point1 到 point2 的 线段 。 假 设 打 印 机 厂商 
(HP、DELL、EPSON 等 ) 接受 了 这 一 协议 ， 那 么 它们 就 需要 在 自己 的 设 
备 中 引入 这 样 的 实现 。 如 此 一 来 ， 无 论 是 哪 款 遵循 协议 规定 的 打印 机 ， 
只 要 向 它 发 送 printline 命 令 ， 最 终 得 出 的 结果 都 应 该 是 一 样 的 。Mesa 
就 是 “打印 机 厂商 ”， 并 且 它 所 生产 的 “设备 ”是 完全 开源 的 。 


除了 核心 的 0penGL AP1 外 ， 各 厂商 (vendors) 、 厂 商 组 织 
(groups of vendors) 和 ARB (Architecture Review Board) 也 可 以 
扩展 和 定义 额外 的 AP1 一 一 并 需要 加 上 相应 的 标志 。 比 如 
GL_ARB_ multitexture 由 ARB 提 出 ，GL_SG1_color_matrix 来 自 于 SG1， 而 
GL NV _texgen emboss 则 出 自 nVidia 之 手 。 更 多 细节 可 以 参见 : 
http://www. opengl. org/registry/。 


17.3 图 形 浑 染 AP1 一 -一 EGL 
17. 3.1 EGL OpenGL ES 


EGL 5 OpenGLES 


如 图 17-7 所 示 。 


Rendering API 


(OpenGL ES) 





EOL 


Native Window System 


A 417-7 EGL 与 OpenGL 


OpenGL 


前 面 已 经 提 到 过 EGL， 它 是 图 形 泻 染 AP1 (比如 0penGL ES) 和 本 地 
窗口 系统 间 的 一 层 接口 。 主 要 提供 了 如 下 功能 : 


e 创建 frendering surfaces 


Surface 的 字面 意思 是 “表面 ”， 通 俗 地 讲 就 是 能 够 承载 图 形 的 介 


质 ， 如 一 张 “ 男 纸 ”。 只 有 成 功 申 请 到 Surface， 应 用 程序 才能 真 
正 “ 作 图 ”到 屏幕 上 。 


e 创造 图 形 环 境 (graphics context) 


OpenGL ES 说 白 了 就 是 一 个 Pipeline， 因 而 它 需要 状态 管理 一 一 这 
就 是 context 的 主要 工作 : 


同步 应 用 程序 和 本 地 平台 泻 染 API; 
提供 了 对 显示 设备 的 访问 ; 
提供 了 对 泻 染 配置 的 管理 ( 见 下 一 小 节 ) 。 


简 而 言 之 ，EGL 可 以 有 效 保证 0penGL ES 的 平台 独立 性 ， 因 而 接 下 来 
和 详细 讲解 如 何 使 用 EGL 来 为 0penGL ES 提供 服务 。 考 虑 到 如 果 单 纯 从 理 
eee 来 分 析 ， 读 者 可 能 会 感觉 抽象 ， 所 以 我 们 还 是 结合 代码 范例 来 


讲解 。 


17.3.2 egl. cfg 


zie. RAAT EH. RA) 是 在 系统 启动 后 动态 确定 的 
(源码 文件 是 frameworks/ native/open|/|ibs/eg|/Loader. cpp) 一 一 
如 果 是 在 硬件 加 速 的 情况 下 ， 系 统 首先 要 加 载 相应 的 1ibhg1 库 ; 否则 加 
载 1ibagl 来 由 CPU 进行 图 形 处 理 。 


具体 来 说 ， 系 统 是 根据 eg1. cfg 文 件 的 解析 结果 来 选择 图 形 泻 染 方 
式 的 。 流 程 如 下 : 


。 egl.cfg 文 件 是 否 存在 


这 个 文件 通常 保存 在 源码 工程 的 /device/ [Manufacture] 目 录 下 ， 
然后 经 过 编译 被 烧 写 到 设备 中 的 如 下 位 置 : 


/system/lib/egl/egl.cfg 


假如 此 文件 不 存在 ， 说 明 硬 件 不 支持 图 形 泻 染 加 速 ， 因 而 只 能 通过 
加 载 软件 库 1ibag1 来 完成 图 形 处 理工 作 。 


。 cgl.cfg 文 件 存在 的 情况 下 


如 果 eg1. cfg 存 在 ， 我 们 需要 先 解 析 这 个 文件 。 它 的 语法 格式 如 
F: 


#<DisplayNumber><HW/SW><Lib_Name> 
© 1 mali 


_ 其 中 第 一 个 数字 表示 显示 屏 编号 。Android 系 统 理论 上 支持 多 个 显 
示 设 备 ， 但 到 目前 为 止 还 只 能 支持 一 个 ， 所 以 这 个 数值 必须 为 0。 


第 二 个 数字 指明 是 硬件 库 (1) 还 是 软件 库 (0) 。 比 如 上 面 这 个 例 
子 中 采用 的 是 硬件 加 速 ， 因 而 值 为 1。 


第 三 个 参数 是 库 的 名 称 。 我 们 需要 将 对 应 的 实现 库 放 
在 /system/1ib/eg| 或 者 /vendor/1ib/eg1/ 目 录 下 ， 而 且 库 的 名 称 必须 
以 如 下 格式 进行 命名 : 


1ibEGL_<Lib_Name>.so 
1ibGLES_<Lib_Name>.so 
1ibGLESvi_CM_<Lib_Name>.so 
1ibGLESv2_<Lib_Name>.so 


egl. cfg 中 可 以 同时 配置 多 个 库 。 要 特别 注意 优先 级 是 随 着 行 顺序 
而 逐步 递减 的 ， 因 而 开发 者 应 该 把 最 佳 实现 库 放 在 最 上 面 。 比 如 : 


© 1 mali  # 硬 件 加 速 ， 采 用 ARM 的 mal1i 系 列 GPU 
© © android # 默 认 配置 


在 原生 态 的 Android 版 本 中 ， 默 认 情 况 下 的 泻 染 库 有 4 个 ， 如 图 17-8 
所 示 。 


日 @ lib 2013-07-10 21:58 drwxr-xr-x 
国 ertbegin_so. o 1332: 2013-07-10 21:49 -r-r r= 

国 crtend_so. o Ts 

日 & egl 2013-07-10 21:57 drwxr-xr-x 

国 egl. cfg 14° 201370510. 21: -rr 

=) libEGL_emulation. so 54624 2013-07-10 21:57  -rw-r--r-- 

=) 1ibGLES_android. so 83202 2013-0T-10 21:57 -mr r- 

=) 1ibGLESv1_CM_emulation. so 38128 2013-07-10 21:57 9 -rw-r--r-- 

=| LibGLESv2_emulation. so 29932 2013-07-10 (21:57. sxmecrcsrsa 





全 图 17-8 默认 情况 下 的 泻 染 库 


e。 OpenGL 函数 的 执行 


通过 上 一 步 的 选择 后 ， 系 统 已 经 能 确认 出 是 采用 硬件 还 是 软件 来 做 
AREA TS, 并 同步 加 载 正 确 的 实现 库 。 这 样 0penGL 函 数 在 后 续 执 行 过 
程 中 就 知道 应 该 跳 转 到 1ibag1 还 是 1ibhg1 了 。 


Eg1 范 数 的 调用 流程 如 下 : 


egl_ init _drivers@Egl. cop>eg!I_ init drivers locked@Eg|. cpp 
载 egl. cfg) 一 open@Loader. cpp load driver @Loader.cpp 〈 加 载 对 
应 的 open gl 库 ) ， 如 图 17-9 所 示 。 


egl init drivers 


load driver 


硬件 库 软件 库 





全 图 17-9 egl 加 载 库 的 流程 图 
头 文件 eg1. h 提 供 了 一 系列 面向 外 开 的 接口 。 比 如 : 


EGLAPI EGLDisplay EGLAPIENTRY eglGetDisplay(EGLNativeDisplayType 
EGLAPI EGLBoolean EGLAPIENTRY eglInitialize(EGLDisplay dpy, EGLin 
EGLint *minor); 

EGLAPI EGLBoolean EGLAPIENTRY eglTerminate(EGLDisplay dpy); 


当 调 用 其 中 任何 接口 时 ，egl 都 会 自动 加 载 0penGL 的 实现 库 一 一 通 
过 解析 eg1. cfg 文 件 来 判断 是 加 载 软件 还 是 硬件 库 。 


17. 3. 3 EGL 接 口 解 析 


EGL 接 口 是 理解 Android 显 示 系 统 的 关键 ， 因 为 整个 显示 框架 中 都 贯 
穿着 各 种 eg1XXX 和 g1XXX 的 函数 调用 。 如 果 无 法 掌握 这 些 函 数 的 功能 和 
用 法 ， 那 就 好 比 “ 盲 人 摸 象 ”一 般 ， 最 终 很 可 能 会 “事倍功半 ”。 


以 下 接口 的 定义 来 源 于 : 
frameworks/native/opengl/include/egl/Egl.h. 
1. eglGetDisplay 


ce Re : 
EGLAPI EGLDisplay EGLAPIENTRY eglGetDisplay(EGLNativeDisplayType 


因为 0penGL ES 和 0penGL 一 样 都 是 系统 无 关 的 〈System 
Independent) ， 所 以 在 某 一 个 特定 的 平台 上 使 用 它 时 ， 就 涉及 如 何 对 
其 进行 “本 地 化 ”处 理 的 问题 。EGL 为 0penGL ES 与 本 地 的 窗口 系统 提供 
了 一 个 “中 介 ”。 


EQL 面 对 的 是 各 种 各 样 的 平台 ， 而 不 同系 统 间 的 逻辑 语义 又 存在 或 
多 或 少 的 差异 。 可 想 而 知 ， 它 需要 一 个 机 制 来 统一 这 些 差异 。 接 口 
eglGetDisplay 得 到 的 EGLDi splay 就 是 一 个 与 具体 系统 平台 无 关 的 对 象 
(实际 上 是 一 个 void* 类 型 的 变量 ) 。 对 于 任何 使 用 EGL 的 应 用 来 说 ， 首 
先 就 需要 调用 eglGetDisplay 来 取得 设备 的 Display。 


一 般 情 况 下 ， 我 们 为 函数 入 人 参 EGLNativeDisplayType 指 定 的 类 型 是 
EGL_DEFAULT_DISPLAY (0) ， 即 默认 的 显示 屏 ; 并 且 要 注意 检查 函数 的 返 
回 值 是 否 为 有 效 值 ， 例 如 下 面 的 代码 段 : 

EGLDisplay display; 


display = eglGetDisplay(EGL_DEFAULT_DISPLAY) ;// 取 得 默认 显示 屏 
if( display == EGL_NO_DISPLAY || eglGetError() != EGL_SUCCESS ) 





// 错 误 处 理 





Ee 
后 面 我 们 还 会 看 到 EGLDi splay 的 更 多 使 用 场景 。 


2. eglGetError 


顺 数 原型 : 
EGLAPI EGLint EGLAPIENTRY eglGetError(void); 


前 面 的 例子 中 我 们 已 经 用 过 eg1GetError 了 ， 它 用 于 返回 当前 EQL 中 
已 经 发 生 的 错误 。 因 为 大 部 分 EGL 阴 数 只 会 返回 EGL_TRUE 或 者 EGL_FALSE 
来 表示 成 功 和 失败 ， 所 以 开发 人 员 要 主动 调用 eg1GetError 来 获取 具体 
的 失败 原因 (这 个 函数 得 到 的 是 一 个 int 值 ， 代 表 了 失败 原因 的 编 


号 ) 。 
3. eglInitialize 
PR RURE : 
EGLAPI EGLBoolean EGLAPIENTRY eglInitialize(EGLDisplay dpy, EGLin 
成 功 执行 了 eglGetDisplay 后 ， 我 们 还 需要 对 EGL 进 行 初始 化 。 这 个 
函数 将 对 EGL 的 内 部 数据 进行 初始 值 设 定 ， 并 返回 当前 的 版 本 号 〈 即 最 
后 两 个 major 和 minor 人 参数 ) 。 
可 能 的 失败 原因 包括 : 
EGL_BAD_DISPLAY: 指定 的 EGLDi splay 无 效 。 


EGL_NOT_INITIALIZED: 无 法 正常 完成 初始 化 。 


4. eglGetConfigs 


函数 原型 : 


EGLAPI EGLBoolean EGLAPIENTRY eglGetConfigs(EGLDisplay dpy, 
EGLConfig *configs, EGLint config_size, EGLint *num_config); 


初始 化 EGL 完 成 后 ， 下 一 步 要 获取 一 个 最 佳 的 Surface。 方 法 有 两 
种 : 其 一 是 通过 查询 当前 系统 中 所 有 Surface 的 配置 
(Configuration) ， 然 后 手动 选择 一 个 : 其 二 就 是 填写 我 们 的 需求 ， 
然后 由 EGL 推 荐 一 个 最 佳 匹 配 的 Surface。 


这 个 函数 的 使 用 分 为 两 种 情况 。 


。 如 果 将 入 参 configs 设 为 NULL， 则 能 得 到 当前 系统 中 所 有 Surface 配 
置 的 数量 (numConfigs) 。 

。 否则 ， 我 们 需要 指定 maxReturnConfigss ， 然 后 EGL 会 把 结果 填充 到 
configs 中 。 





5. eglGetConfigAttrib 


函数 原型 : 


EGLAPI EGLBoolean EGLAPIENTRY eglGetConfigAttrib(EGLDisplay dpy, 
EGLConfig config, EGLint attribute, EGLint *value); 


EGLConfig 包 含 了 一 个 有 效 Surface 的 所 有 详细 信息 ， 如 颜色 数量 、 
额外 的 缓冲 区 、Surface 类 型 等 重要 属性 。 我 们 可 以 通过 
eglGetConfigAttr ib 来 指定 需要 查看 的 具体 属性 项 ， 表 17-1 列 出 了 部 分 
可 选 的 属性 。 


表 17-1 EGLConf ig 支 持 的 属性 


EGL BUFFER SIZE 颜色 位 数 





ial i ro | 


EGL_GREEN_SIZE 


EGL_BLUE_SIZE 
EGL_LUMINANCE_ SIZE 








6. eglChooseConfig 
函数 原型 : 


EGLAPI EGLBoolean EGLAPIENTRY eglChooseConfig(EGLDisplay dpy, con 
*attrib_list, EGLConfig *configs, EGLint config_size, EGLint *num 


前 面 说 过 ， 除 了 手动 逐个 查阅 EGLConfig， 然 后 选择 一 个 最 佳 配置 
外 ， 我 们 还 可 以 让 EGL 自 动 选择 并 直接 返回 匹配 结果 。 使 用 
eg|ChooseConf iig 需 要 我 们 先 提供 一 系列 需求 清单 一 一 这 就 好 比 去 商城 
配 一 部 组 装 电脑 一 样 ， 先 要 详细 填写 期 望 的 硬件 配置 ， 然 后 商家 才能 依 
据 这 一 需求 来 提供 性 价 比 最 高 的 组 装 方案 。 


7. eglCreateWindowSurface 


函数 原型 : 


EGLAPI EGLSurface EGLAPIENTRY eglCreateWindowSurface(EGLDisplay d 
EGLConfig config, EGLNativeWindowType win, const EGLint *attrib_l 


一 旦 我 们 选择 好 最 佳 的 EGLConf ig， 接 下 来 就 可 以 创建 一 个 window 
了 。 注 意 函 数 egl1cCreateWindowSurface 最 后 的 attrib_1ist 和 前 面 一 个 
表 中 列 出 的 属性 不 太一 样 ， 建 议 读者 参阅 官方 文档 了 解 详情 。 


哨 数 eg1CreateWindowSurface 可 能 发 生 的 错误 如 表 17-2 所 示 。 


3217-2 eglcreateWindowSurface 可 能 发 生 的 错误 


本 地 窗口 (native window) 和 
EGLConfig 不 相符 ， 或 者 我 们 

POLCBAD MA PCH 提供 的 EGLConfig 不 支持 
window 演 染 


EGL_BAD_CONFIG 系统 不 文 持 这 个 EGLConfig 


EGL BAD NATIVE WINDOW| 提 供 的 本 地 窗口 句柄 (native 
window handle) 是 无 效 的 





8. eglCreatePbufferSurface 
ba aM J 


EGLAPI EGLSurface EGLAPIENTRY eglCreatePbufferSurface(EGLDisplay 
EGLConfig config, const EGLint *attrib_list); 


这 个 函数 与 上 面 的 eg1CreateWindowSurface 一 样 都 用 于 创建 一 个 
Surface 一 一 但 Surface 的 用 途 不 同 。 前 者 生成 的 Surface 可 用 于 在 终端 
屏幕 上 显示 ， 而 eg1CreatePbufferSurface 生 成 的 结果 则 是 “ 离 
BR” (off-screen) 的 泻 染 区 。 所 有 适用 于 window surface 的 泻 染 方法 
同样 能 被 pbuffer surface 使 用 ， 只 不 过 执行 的 结果 不 需要 通过 swap 
(ee ee 当然 ， 读 者 可 以 选择 将 数据 保存 到 指定 的 

万 。 


9. eglCreateContext 


函数 原型 : 
EGLAPI EGLContext EGLAPIENTRY eglCreateContext(EGLDisplay dpy, 
EGLConfig config, EGLContext share_context, const EGLint *attrib_ 

我 们 知道 ，0penGL 是 一 个 状态 机 ， 需 要 对 诸多 状态 进行 管理 。EGL 
Context 正 是 基于 这 个 需求 提出 来 的 ， 它 为 OpenGL 的 运行 提供 了 统一 的 
环境 ， 并 让 我 们 可 以 依托 于 这 个 环境 来 更 好 地 控制 OpenGL。 

这 个 函数 可 能 的 错误 结果 包括 。 

EGL_NO CONTEXT: 无 法 创建 context。 

EGL_BAD_CONF IG: 提供 了 无 效 的 EGLConfig。 
10. eglMakeCurrent 


函数 原型 : 


EGLAPI EGLBoolean EGLAPIENTRY eglMakeCurrent(EGLDisplay dpy, EGLS 
draw, EGLSurface read, EGLContext ctx); 


一 个 进程 中 可 能 会 同时 创建 多 个 Context， 所 以 我 们 必须 选择 其 中 
的 一 个 作为 当前 的 处 理 对 象 。 细 心 的 读者 应 该 发 现 了 这 个 函数 的 入 参 中 
有 两 个 EGLSurface， 那 么 哪个 才 是 要 被 设置 的 当前 Surface 呢 ? 答案 就 
是 “两 个 都 是 ”。 所 以 ， 通 常情 况 下 我 们 需要 把 两 者 都 设 为 同一 个 
Surface。 至 于 系统 为 什么 这 样 设 计 ， 这 里 不 过 多 追究 ， 感 兴趣 的 读者 
可 以 查阅 相关 资料 。 

至 此 ， 我 们 按照 一 个 典型 程序 中 使 用 EGL 的 顺序 讲解 了 它 所 提供 的 
几 个 重要 接口 函数 。 只 有 成 功 地 调用 并 执行 这 些 接口 ， 才 能 保证 0penGL 
ES 的 正常 运行 。 


17. 3. 4 EGL 实 例 





这 个 例子 选取 自 Android 显 示 系 统 SurfaceFlinger 通 过 EGL 来 搭 
建 0penGL ES 的 运行 环境 。 其 源码 实现 所 在 目录 为 : 


frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp 


具体 是 在 readyToRun 中 ， 如 下 所 示 : 


status_t SurfaceFlinger: :readyToRun( ) 


Mutex::Autolock _1(mStateLock); 
mEGLDisplay = **eglGetDisplay**(EGL_DEFAULT_DISPLAY); /*Step 
******eqg]Initialize**(mEGLDisplay, NULL, NULL); /*Step 2. 初 始 化 */ 


EGLint format = mHwc->getVisualID(); 
mEGLConfig =** selectEGLConfig**(mEGLDisplay, format); /*Ste 
最 佳 的 conf 
mEGLContext = **createGLContext**(mEGLDisplay, mEGLConfig); / 
******eglGetConfigAttrib**(mEGLDisplay, mEGLConfig, 
EGL_NATIVE_VISUAL_ID, &mEGLNativeVisualId); /*Step 5. 43 


sp<const **DisplayDevice**> hw(getDefaultDisplayDevice());/*S 
DispJayDevice， 其 构造 函数 中 会 调用 eg1Cl 

DisplayDevice: :**makeCurrent**(mEGLDisplay, hw, mEGLContext); 
Co 


return NO_ERROR,; 


可 以 看 到 ， 上 述 代码 段 的 处 理 过 程 和 前 面 小 节 的 讲解 完全 一 致 。 读 
者 还 可 以 在 Android 工 程 中 的 其 他 地 方 找到 类 似 的 例子 ， 如 
BootAnimation，GLSurfaceView 等 。 


17.4 简化 0penGL ES 开发 一 一 GLSurfaceView 


一 直 以 来 我 们 看 到 的 范例 都 是 以 C/C++ 编写 的 ， 那 么 Java 层 能 否 使 
用 EGL 和 0penGL ESE? 答案 是 肯定 的 。 


这 一 小 节 ， 我 们 将 讲解 上 层 应 用 程序 如 何 使 用 0penGL ES。 和 其 他 
常用 功能 一 样 ，Android 系 统 已 经 在 SDK 中 为 开发 人 员 封 装 了 一 整套 
OpenGL ES 的 使 用 和 管理 机 制 。 具 体 而 言 ，Java 层 代码 可 以 通过 以 下 两 
种 方式 来 搭建 OpenGL ES 环境 。 


。 直接 使 用 SDK 提 供 的 EGL，GLES 类 (Java) 


与 EGL 相 关 的 Java 类 包括 EGL10、EGL11、EGL14 和 EGL 等 ;与 GLES 相 
关 的 Java 类 包括 GLES10、GLES11、GLES20、GLES30 等 。 这 些 类 将 间接 通 
过 JN1 调 用 C/C++ 层 的 EGL 和 GLES 实 现 。 


e GLSurfaceView 


虽然 用 户 可 以 直接 通过 EGL 和 GLES 提 供 的 Java 层 接口 来 使 用 0penGL 
ES， 但 这 种 方式 对 开发 人 员 有 一 定 要 求 ， 程 序 编 写 上 也 比较 复杂 。 所 以 
Android 系 统 特别 封装 了 GLSurfaceView， 从 而 大 大 精简 了 应 用 开发 者 的 
TF; 


GLSurfaceView 继 承 自 SurfaceView， 也 就 意味 着 它 具备 View 类 的 所 
有 功能 和 属性 一 一 特别 是 接收 事件 的 能 力 ， 这 弥补 了 0penGL ES 本 身 不 
能 响应 任何 事件 的 缺陷 (准确 地 说 并 不 是 缺陷 ， 因 为 它 的 设计 初衷 就 是 
这 样 的 ) ; 同时 ，GLSurface View 也 拥有 了 0penGL ES 所 提供 的 强大 的 
3D 图 形 处 理 功 能 ， 这 为 我 们 编写 高 质量 的 U1 界面 或 者 游戏 特效 提供 了 坚 
实 的 基础 ， 如 图 17-10 所 示 。 








A 417-10 GLSurfaceView #k& KK AA 
GLSurfaceView 的 主要 特性 : 


e 管理 EGLDisplay， 它 表示 一 个 显示 屏 ; 

e 管理 Surface (AM LR IAW KR) ; 

。GISurpaceView 会 创建 新 的 线程 ， 以 使 整个 泻 染 过 十 程 不 至 于 阻塞 UI 
主线 程 ; 

e 用 户 可 以 自 定义 演 染 方式 ， 如 通过 setRendetet0 设 置 一 个 Rendetet。 


可 以 肯定 地 说 ， 当前 很 多 Andro id 游戏 都 是 直接 或 者 间接 通过 
GLSurfaceView 完 成 的 。 因 而 ， 熟 练 掌握 它 的 使 用 方法 是 游戏 开发 人 员 
的 必修 课 。 基 本 步骤 如 下 : 

Step1. 创建 GLSurfaceView 


这 和 普 普通 的 应 用 程序 训 并 没有 什么 区 别 
一 个 View， 我 们 可 以 通过 布局 文件 的 方式 将 它 加 入 整 棵 View 树 中 。 


Step2. 初始 化 0penGL ES 环境 


GLSurfaceView 默 认 情 况 下 已 经 为 开发 人 员 拱 建 好 0penGL ES 的 运行 
环境 ， 因 而 如 果 没 有 特殊 需求 ， 我 们 并 不 需要 额外 做 什么 工作 。 当 然 ， 
所 有 的 默认 设置 都 是 可 以 被 更 改 的。 比如 通过 以 下 这 些 函 数 : 
setEGLConfigChooser (boolean) 
setGLWrapper (GLWrapper ) 


getHolder().setFormat(PixelFormat . TRANSLUCENT ) 
setDebugFlags(int ) 


具体 细节 可 以 参阅 帮助 文档 。 
Step3. 设置 Renderer 


泻 染 是 0penGL 的 核心 工作 ， 也 是 开发 人 员 花 费时 间 最 多 的 地 方 。 
SetRenderer () 可 以 将 用 户 自 定义 的 一 个 Renderer 加 入 实际 的 泻 染 流程 
中 








Step4. 设置 Rendering Mode 


GLSurfaceView 默 认 情 况 下 采用 的 是 连续 的 泻 染 方式 ， 如 果 需 要 开 
发 人 员 可 以 通过 setRenderMode 来 进行 更 改 。 


Step5. 状态 处 理 


使 用 GLSurfaceView 要 特别 注意 程序 的 生命 周期 。 我 们 知道 
Activity 会 有 暂停 和 恢复 等 状态 ， 为 了 达到 最 优 效 果 ，GLSurfaceView 
也 必须 要 知晓 程序 的 当前 状态 。 比 如 当 Activity 暂 停 时 需要 调用 
GLSurfaceView 的 onPause () ， 恢 复 时 再 调用 onResume () 等 一 一 这 样 才能 
ES 内 部 的 运行 线程 做 出 正确 的 判断 ， 从 而 保证 应 用 程序 的 稳 
Æo 


总 结 以 上 几 个 步骤 可 以 发 现 ， 如 果 开 发 过 程 基于 GLSurfaceView， 
那么 我 们 的 主要 工作 就 只 有 Renderer 的 实现 了 。 而 其 他 诸如 EGL 的 创建 
过 程 、Surface 的 分 配 以 及 0penGL ES 的 一 些 调 用 细节 等 都 被 隐藏 了 起 


GLSurfaceView 是 如 何 做 到 的 呢 ? 接 下 来 我 们 就 要 深入 源码 层 去 探 


个 究竟 了 。 
先 来 看 看 GLSurfaceView 的 创建 过 程 。 


/*frameworks/base/opengl/java/android/opengl/GLSurfaceView. 
public GLSurfaceView(Context context, AttributeSet attrs) { 
super(context, attrs); 
init(); 


GLSurfaceView 的 构造 函数 很 简捷 ， 除 了 调用 其 父 类 《〈 即 
SurfaceView) 的 构造 函数 外 ， 融 直接 进入 init() : 
private void init() { 


SurfaceHolder holder = getHolder(); //SurfaceView 中 的 方法 
holder .addCallback(this); 





i 


| A a 它 先 通过 “ 父 类 ”SurfaceView 的 方法 获取 当 
前 的 SurfaceHolder， 然 后 添加 自身 为 回调 函数 (AA ERIT 


Sur Tacho Ider. Callback) ， 这 样 当 Surface 有 变化 〈 比 如 创建 、 销 
27) 时 就 能 收 到 通知 了 。 


这 个 Cal1back 接 口中 有 3 个 重要 的 方法 。 如 下 所 示 : 


void surfaceCreated(SurfaceHolder holder); 


当成 功 申请 到 一 个 Surface 时 调用 ， 一 般 情 况 下 只 会 发 生 一 


void surfaceChanged(SurfaceHolder holder, int format, int width,i 


当 Surface 改 变 时 调用 ， 如 format，size 的 更 动 : 


void surfaceDestroyed(SurfaceHolder holder); 
当 Surface 销 毁 时 调用 。 
特别 提醒 一 下 ， 读 者 不 要 将 这 里 的 Cal eee 


GLSurfaceView. Renderer 里 的 回调 函数 相 混 淆 。 后 面 这 个 接口 有 如 下 几 
个 回调 方法 : 


void onSurfaceCreated(GL10 gl, EGLConfig config); 
void onSurfaceChanged(GL10 gl, int width, int height); 
void onDrawFrame(GL1i0 gl); 


是 GLSurfaceView 与 APK 应 用 程序 间 的 回调 ， 而 Surface 被 销毁 的 
ed 因而 就 没有 这 个 接口 存在 。 


那么 ，SurfaceHolder 又 是 如 何 创建 的 呢 ? 


/*frameworks/base/core/java/android/view/Sur faceView. java*/ 
private SurfaceHolder mSurfaceHolder = new SurfaceHolder() 4... 
public void addCallback(Callback callback) { 

synchronized (mCallbacks) { 
if (mCallbacks.contains(callback) == false) { 
mCallbacks.add(callback); 
} 


在 SurfaceView 中 ，mSurfaceHolder 是 它 的 一 个 全 局 变量 ， 而 且 一 
开始 就 已 经 创建 了 实例 。 其 中 的 addCal lback () 方法 用 于 将 需要 接收 回 
调 通 知 的 类 (比如 上 面 的 GLSurfaceView) 加 入 其 mcCal1backs 队 列 管 理 
中 。 


接 下 来 看 看 Surface 是 如 何 创建 的 。 我 们 知道 ，SurfaceView 继 承 自 
View， 而 应 用 程序 的 View 树 一 定 会 通过 ViewRoot 申 请 到 一 个 
Surface 《这 个 过 程 可 以 参阅 ViewRoot 章 节 的 讲解 ) . ABA, 
SurfaceView 中 的 这 个 Surface 与 YiewRoot 的 Surface 是 否 属于 同一 个 
Ne ? 


答案 是 否定 的 。SurfaceView 中 的 Surface 是 另外 分 配 得 到 的 一 一 这 
也 是 它 “SurfaceView” 名 称 的 由 来 。 我 们 来 看 看 SurfaceView 对 象 是 如 
何 申请 到 自己 的 Surface 的 ， 如 图 17-11 所 示 。 
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A 17-11 SutfaceView 中 Sutface 的 申请 过 程 


图 17-11 描 述 了 SurfaceView 中 申请 Surface 的 流程 。 包 括 如 下 几 个 
IR, 


ZĘ = 


Sir 


e 当 ViewRoot 成 功 AttachToWindow 后 ， 它 需要 将 这 一 事件 告知 View 树 
中 的 所 有 成 员 (其 中 的 performTraversals 我 们 在 ViewRoot 章 节 中 有 重 
点 分 析 ) 。 要 注意 的 是 ,一般 情况 下 SurfaceView 都 是 布局 在 茶 个 
ViewGroup 中 的 。 比 如 我 们 写 一 个 Media Player， 最 外 围 的 layout 通 常 
是 FrameLayout， 然 后 依次 琶 加 视频 播放 层 (SurfaceView) 、 控 制 层 

(按键 、 菜 单 ) 等 。 因 而 ViewGroup 中 必须 重 载 
dispatchAttachedToWindow 这 个 方法 ， 才 有 可 能 将 这 个 消息 传播 到 
View 树 的 每 个 角落 。 其 他 事件 在 View 树 中 的 递归 传递 也 类 似 。 

o SurfaceView 在 收 到 Attached ToWindow 成 功 的 消息 后 ， 会 通过 
getWindowSession() 向 ViewRoot 获 取 一 个 IWindowSession。 这 是 
ViewRoot 与 WMS 间 的 通信 中 介 ，SurfaceView 没 有 必要 自己 再 新 建 一 
个 ， 直 接 用 现成 的 即 可 。 

e SurfaceView 在 updateWindow(0 时 ， 将 利用 IwindowSession.relayout0 来 
重新 申请 一 个 Surface， 其 中 最 后 一 个 参数 就 是 WMS 生 成 的 新 
Surface « 

e Surface View IX 4 #7 19 Surface jg, Transfer Z| mSurface® BF. jh Kt 
还 需要 把 这 一 事件 通知 到 所 有 注册 了 callback 函 数 的 对 象 ， 如 
GLSurfaceView. ix ##SurfaceView “ 独 享 ”的 一 个 全 新 Sutface 就 申请 
成 功 了 。 


当 获 知 Surface 已 经 申请 成 功 后 ，GLSurfaceView 还 需要 做 些 什么 工 
(EIE? 











/*frameworks/base/opengl/java/android/opengl/GLSurfaceView. 
public void surfaceCreated(SurfaceHolder holder) { 
mGLThread.surfaceCreated(); 
} 


前 面 说 过 ，GLSurfaceView 将 会 启动 一 个 新 线程 来 完成 泻 染 ， 以 防 
止 程 序 阻塞 U1 主 线程 一 一 这 个 新 的 工作 线程 就 是 mGLThread。 它 将 在 应 


用 程序 调用 setRenderer () 时 启动， 然后 不 断 等 待 和 处 理事 件 ， 同 时 还 
负责 开展 Render 工 作 : 


public void surfaceCreated() { 
synchronized(sGLThreadManager) {... 
mHasSurface = true; 
sGLThreadManager ..notifyAll(); 


} 


这 里 又 出 现 了 一 个 新 的 变量 sGLThreadManager ， 从 名 称 上 看 它 和 
Thread 相 关 ， 而 且 是 GLThread 的 “管理 者 ”。 具 体 来 说 ， 它 管理 的 是 不 
同 线程 间 的 互 斥 访问 。 如 果 读 者 对 wait () 、notifyAll () < notify 0, 
synchronized O 这 些 函 数 的 用 法 还 不 太 清 楚 ， 建 议 回 头 看 看 本 书 的 原理 
篇 章节 ， 这 里 不 再 歼 述 。 


有 notify 0 〇 或 者 notifyAl1 0 就 意味 着 肯定 有 其 他 地 方 在 wait()。 
唯一 可 以 找到 的 相关 代码 是 GLThread 中 的 guardedRun 0 方法 (注意 : 上 
面 的 surfaceCreated 函 数 并 不 是 在 GLThread 线 程 中 执行 的 ) ， 我 们 只 截 
取 最 核心 部 分 的 代码 来 分 析 。 如 下 所 示 : 


private void guardedRun() throws InterruptedException { 


******while** (true) {// 死 循环 ， 除 非 主 动 跳出 
synchronized (sGLThreadManager) { 
**while** (true) { /7/ 注 意 肉 套 了 两 个 while 循 环 ， 下 面 我们 统一 称 它 们 内 、 外 循 于 
if (mShouldExit) {// 是 否 需要 结束 循环 
return; 











} 

if (! mEventQueue.isEmpty()) { /*Step1. \EventQueue P43 
event = mEventQueue.remove(0); // 取 得 这 一 消息 
break; /* 注 意 : 只 是 跳出 内 循环 */ 


J 

/*Step2 .下面 的 工作 基于 各 种 全 局 变量 展开 ， 我 们 依次 分 析 ( 同 样 只 保 

if (pausing && mHaveEglSurface) {...// 释 放 Surface。 比 如 Act 
stopEglSurfaceLocked(); 








} 
if ((! mHasSurface) && (! mWaitingForSurface)) {// 判 断 S 
/xx 如果 当前 没有 Surface， 而 且 也 不 在 等 待 Surface 的 创建 ， 说 明 已 经 失 
if (mHaveEglSurface) { 
stopEglSurfaceLocked (); 








mWaitingForSurface = true; 
mSurfaceIsBad = false; 


sGLThreadManager .notifyAll(); 


} 
if (mHasSurface && mWaitingForSurface) {/* 如 果 已 经 成 功用 
设置 相应 的 全 局 变量 








mwaitingForSurface = false; 
sGLThreadManager . notifyAll(); // 并 通知 任何 正在 等 待 的 线 包 


Ja 
if (**readyToDraw**()) { 
./*Step3. GLSurfaceViewR eH) TEW ee NHR HETE 
演 染 处 理 , 后 面 专门 讲解 */ 
Je 


sGLThreadManager.**wait**(); // 如 果 上 述 readyToDraw 中 没 在 

} // 内 循环 (while 循 环 ) 结 束 
} // synchronized(sGLThreadManager ) 到 这 边 结束 
/*Step4 .程序 如 果 执 行 到 这 里 ， 有 两 种 可 能 : QueueEvent 中 有 事件 ， 或 者 要 执行 
if (event != null) {// 有 事件 要 处 理 的 情况 下 ， 调 用 它 的 run 函 数 

event.run(); 

event = null; 

continue; /7 事件 执行 完毕 后 直接 进入 下 一 轮 循环 


} 
if (createEglSurface) {/* 内 围 while 循 环 如 果 设 置 了 这 个 标志 ， 说 明 Eg1l1sl 
…// 代 码 略 

























































































Ja 
if (sizeChanged) 4... 
GLSurfaceView view = mGLSurfaceViewWeakRef.get(); 
if (view != null) { 
view.mRenderer .onSurfaceChanged(gl, w, h); /* 通 知 应 


sizeChanged = false; 


AW 


GLSurfaceView view = mGLSurfaceViewWweakRef.get(); 
if (view != null) { 

view.mRenderer.**onDrawFrame**(gl); // 调 用 应 用 程序 的 
} 


int swapError = mEglHelper.**swap**(); // 通 过 swap 把 泻 染 结果 显示 至 
.，VVSswap 错 误 的 处 理 ， 代 码 略 
}// 外 围 的 while 循 环 


芳 数 guardedRun 很 长 ， 但 核心 工作 总 结 起 来 只 有 以 下 几 点 。 


。 整个 函数 的 逻辑 框架 分 为 内 、 外 两 层 while 循 环 。 
。 ah (mEventQueue) “有 东西 ”， 就 直接 跳出 内 循环 ， 
然后 进入 外 循环 的 处 理 部 分 (Step4) 。 


























。 否则 要 根据 当前 的 状态 看 是 否 适 合 泻 染 、 是 否 有 事件 要 通知 应 用 程 
序 等 。 

。 如 有 果 确 定 需 要 做 泻 染 工作 ， 同 样 跳出 内 循环 。 

。 处 理事 件 或 者 执行 浑 染 工 作 (Step4 以 后 ) o 

。 如 此 循环 往复 。 


详细 分 析 如 下 : 


Step1@guardedRun。 内 循环 中 ， 首 先 判 断 mEventQueue. isEmpty 是 
否 为 空 一 一 如 果 发 现 Queue 中 有 event 需 要 处 理 ， 则 直接 跳出 内 循环 〈 即 
进入 Step4) ; 否则 仍然 运行 在 内 循环 中 。 


Step2@guardedRun。 需 要 判断 的 情况 包括 : 

(1) 是 否 需 要 释放 EGL Surface. 

比如 当前 的 Activity 已 经 处 于 pause 状 态 。 

(2) 是 否 丢 失 了 Surface。 

在 某 些 异常 情况 下 是 有 可 能 丢失 掉 Surface 的 。 因 而 我 们 需要 特别 


防止 这 种 情况 的 发 生 。 变 量 mHasSurface 表 示 当 前 有 没有 可 用 Sur face; 
mWaitingForSurface 表 示 是 否 在 申请 Surface 的 过 程 中 。 





(3) 是 否 需 要 放弃 EGL Context。 


requestReleaseEg1ContextLocked 申 请 释放 Context 
上 时， 变量 mShouldReleaseEg| Context 将 被 置 为 true， 此 时 需要 调用 
Stocks | SurfaceLocked#stopEg | ContextLocked3K # 1EContext. 


Step3@guardedRun 。 经 过 上 述 判 断后 ， 程 序 进 入 图 形 泻 染 前 的 准备 
工作 ， 即 readyToDraw 之 间 的 代码 段 。 如 下 所 示 : 
if (readyToDraw()) { 


if (! mHaveEglContext) {// 没 有 EGL Context 的 情况 下 
. .// 判 断 是 否 要 建立 有 效 的 Context 
} 














if (mHaveEglSurface) { // 保证 我 们 有 EglSurface， 注 意 和 mSur 
mRequestRender = false; 
sGLThreadManager .notifyAll(); 
break; 
i; 
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上 述 这 上 段 代码 执行 的 前 提 是 当前 可 以 泻 染 图 形 (readyToDraw) , 
即 需 要 满足 以 下 几 个 条 件 。 


(1) 程序 当前 不 处 于 暂停 状态 。 

(2) 已 经 成 功 获 得 Surface。 

(3) 有 合适 的 尺寸 。 如 果 长 宽 都 为 0%， 就 没有 显示 的 意义 了 。 

(4) 处 于 持续 自动 泻 染 模式 ， 或 用 户主 动 发 起 了 泻 染 请 求 。 

接着 判断 两 个 关键 因素 ， 即 EGL Context 和 EGL Surface 是 否 存 在 并 
且 有 效 。 如 果 没 有 Context， 就 需要 获取 一 个 ， 如 果 当 前 有 
EglSurface， 但 尺寸 发 生 了 变化 ， 那 么 就 需要 销毁 它 并 重新 申请 


Surface。 


假如 一 切 正常 ， 上 面 代码 段 的 末尾 会 跳出 内 围 的 whi1e 循 环 一 一 否 
则 程序 会 进入 wait () ， 直 到 有 人 唤醒 它 后 才 继 续 执行 循 环 。 


Step4@guardedRun。 一 旦 程序 执行 到 这 里 〈 即 跳出 了 内 循环 ) ， 有 
两 种 可 能 : 


。 EventQueue 中 有 需要 处 理 的 事件 


此 时 event 变 量 不 为 空 ， 所 以 我 们 直接 调用 event. run 来 执行 具体 工 
作 ; 并 且 在 事件 处 理 结 束 后 直接 进入 下 一 轮 循 环 (continue) 。 


。 需 要 执行 泻 染 工作 


如 果 是 后 面 一 种 情况 ， 处 理 流 程 如 下 。 





(1) 是 否 需要 重新 申请 Eg1Surface。 
比如 尺寸 发 生 了 变化 ， 此 时 createEg1Surface 为 true。 
(2) 是 否 需要 申请 GL Object. 
此 时 createG11nterface 为 true。 
(3) 是 否 需 要 生成 EGL Context。 
此 时 createEg1Context 为 true。 
(4) 尺寸 是 否 发 生变 化 。 
此 时 sizeChanged 为 true， 我 们 需要 将 此 事件 通知 给 感 兴趣 的 人 。 
即 调用 : 
view.mRenderer.onSurfaceChanged(gl, w, h); 


(5) 一 切 准备 就 绪 后 ， 我 们 调用 开发 者 提供 的 Render 对 象 执行 真 
正 的 浑 梁 工作 : 


view.mRenderer.onDrawFrame(gl); 


(6) 最 后 ， 我 们 需要 通过 swap 来 把 泻 染 结果 显示 到 屏幕 上 “中间 
的 详细 流程 可 以 参考 显示 系统 章节 的 描述 ) 。 如 果 swap 失 败 ， 还 应 该 做 
好 处 理工 作 。 


在 分 析 guardedRun () 的 过 程 中 ， 读 者 应 该 已 经 注意 到 对 EGL 的 操作 
全 部 是 通过 Eg1He1per 来 进行 的 一 一 这 是 系统 对 EQL 的 一 层 便捷 封装 。 下 
面具 体 来 看 看 Eg1He1per 所 做 的 工作 : 


private class EglHelper {... 
public void start() {.. 
mEgl = (EGL10) EGLContext.getEGL(); // 取 得 一 个 EGL 实 例 
mEglDisplay = mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DI 


/* 接 着 用 上 述 的 Egl1Display 来 初始 化 EGL 实 例 */ 
int[] version = new int[2]; 
if(!mEgl.eglInitialize(mEglDisplay, version)) {// 初 始 人 


throw new RuntimeException("eglInitialize failed" 


GLSurfaceView view = mGLSurfaceViewwWeakRef.get(); 

if (view == null) { 
mEglConfig = null; 
mEglContext = null; 

} else { 
mEglConfig = view.mEGLConfigChooser .chooseConfig( 
/* 选 取 一 个 EGL 配 置 */ 
mEglContext = view.mEGLContextFactory.createConte 
Config);/* 创 建 EG6LContext， 它 是 控制 OopenGL ES 状态 机 运转 





} 
p~ 
完成 start () 后 ， 就 可 以 利用 EGL 结 合用 户 设置 的 Renderer 进 行 
OpenGL ES 的 泻 染 了 。 最 后 通过 EglHelper. swap () 来 将 Surface 中 的 内 容 


显示 到 屏幕 上 Spe beer ee EL ecoute 


mEgl.eglSwapBuffers(mEglDisplay, mEglSurface); 


所 以 抛 开 上 述 分 析 中 的 所 有 封装 和 一 系列 细节 处 理 ， 
GLSurfaceView 中 使 用 EGL 的 步骤 大 致 如 下 。 


。 获取 一 个 EGL 实例 
EGLContext.getEGL(); 
e 获取 一 个 EGL Display 
eglGetDisplay(Object native_display) ; 
。 利 用 Display 来 初始 化 EGL 并 返回 EGL 的 版 本 号 


eglInitialize(EGLDisplay display, int[] major_minor); 





e 选取 EGL 的 一 个 配置 (EGL Config) 
eglChooseConfig(EGLDisplay display, int[] attrib_list, EGLConfig[ 


e 创建 EGL Context 


eglCreateContext(EGLDisplay display, EGLConfig config, EGLContext 


e 创建 EGL Surface 


eglCreateWindowSurface(EGLDisplay display, EGLConfig config, Obje 
int[] attrib_list); 


18 at Swap ACHE RA A ie wm Bl aL 


eglSwapBuffers(EGLDisplay display, EGLSurface surface); 


GLSurfaceView 中 所 涉及 的 EGL 接 口 都 是 Java 层 的 ， 而 且 很 好 地 封装 
在 了 GLSurfaceView 的 框架 中 一 一 这 就 意味 着 GLSurfaceView 的 使 用 者 几 
乎 不 用 添加 任何 代码 便 拥 有 了 0penGL ES 的 运行 环境 ， 可 谓 一 举 多 得 。 





17.5 0penGL 分 析 利 器 一 一 GLTracer 


由 于 0penQL 的 动态 性 ， 对 它 所 生成 的 U1 界面 的 追踪 调试 成 了 一 个 难 
点 。 壁 如 大 部 分 游戏 类 应 用 程序 就 是 基于 Cocos2D/3D、Unity3d、 
Unreal 等 GameEngine 开 发 的 ， 而 后 者 则 又 会 利用 0penQL 来 完成 图 形 界 面 
的 绘制 。 游 戏 画 面 的 变换 相当 频繁 ， 如 何 有 效 地 追踪 图 形 相关 问题 显得 
尤其 重要 。 那 么 Android 有 没有 提供 0penGL 方 面 的 工具 来 辅助 我 们 完成 
上 述 问题 的 分 析 呢 ? 


答案 就 是 GLTracer 。 


GLTracer 可 以 让 开发 者 方便 地 捕 抓 到 0penGL ES 的 接口 调用 信息 ， 
以 及 由 此 产生 的 每 一 帧 图 像 。 不 过 它 对 Android 系 统 版 本 有 一 定 要 求 ， 
Android 4.1 〈AP1 等 级 16) 以 上 才能 正常 使 用 这 一 开发 利器 。 开 发 者 可 
以 从 Android Device Monitor 或 者 各 1DE 中 启动 这 个 工具 。 


开始 一 个 0penGL Trace 的 流程 如 下 所 示 。 


。 通过 USB 线 连接 Android 真 机 设备 ， 同 时 要 保证 设备 开启 了 调试 模 
Pa 

e 4] H Tracer for OpenGL ES # 1 © Tracer for OpenGLES | 

o Bde Tracety AY o 

o 在 打开 的 对 话 框 中 ， 首 先 选 择 需要 调试 的 OpenGL 程 序 所 在 的 设 
备 ， 如 图 17-12 所 示 。 








© x 
OpenGL ES Trace Options 


Provide the application and activity to be traced. 


Device: ii ~ 





Application Package: | org.cocos2dx.FishGame | 











Activity to launch: | org.cocos2dx.FishGame.FishingJoy | 





[l Activity name is fully qualified, do not prefix with package name 


Read back framebuffer 0 on eglSwapBuffers() 
Data Collection Options: [_]Read back currently bound framebuffer On glDraw*() 
C] Collect texture data submitted using glTexImage*() 








Destination File: |C:\Users\xs0\Desktop\trace1 .gltrace Browse... 





Trace Cancel 





全 图 17-12 选择 要 调试 的 设备 


e 在 Application Package 中 ， 输 入 希望 调试 的 OpenGIL 程 序 的 包 名 。 

e “Activity to launch 中 ， 输 入 希望 调试 的 Activity。 当 然 ， 如 果 要 被 调 
试 的 对 象 是 默认 的 Activity， 那 么 可 以 不 必 填 写 。 

e 选择 Trace 的 保存 路 径 。 

e 单 击 Trace 按 钮 开始 捕获 数据 。 

e 如 果 和 希望 调试 Trace 文件 ， 可 以 单 击 Open a saved OpenGL Trace File 
按钮 CS 。 


这 个 工具 还 有 男 一 个 限制 ， 即 被 测试 的 应 用 程序 必须 是 debuggable 
的 。 这 就 要 求 开 发 人 员 在 AndroidManifest. xm| 中 主动 添加 这 一 属性 ， 
如 下 面 范例 所 示 : 


<application 
android: icon="@drawable/ic_launcher" 
android: Llabel="@string/app_name" 
android: theme="@style/AppTheme" 
android: **debuggable**="true"> 


如 果 被 测 程序 不 符合 上 述 要 求 的 话 ， 系 统 将 抛 出 一 个 Secur ity 的 异 
常 。 对 应 的 源码 实现 在 ActivityManagerService. javatp: 


void setOpenGlTraceApp(ApplicationInfo app, String processNam 
synchronized (this) { 
boolean isDebuggable = "1".equals(SystemProperties.get(SY 
if (!isDebuggable) { 
if ((app.flags&ApplicationInfo.FLAG_DEBUGGABLE) = 
throw new SecurityException("Process not debugga 


} 


mOpenGlTraceApp = processName; 


} 


SYSTEM_DEBUGGABLE (这 是 一 个 全 局 静态 字符 串 变量 ， 值 
AA “ro. debuggable”) 这 一 属性 在 不 同 设备 中 的 具体 值 会 存在 一 定 差异 
(主要 取决 于 编译 版 本 的 var iant 设 置 ， 如 user 、userdebug 或 者 是 
eng) 。 这 就 意味 着 如 果 我 们 希望 在 已 量 产 的 Android 设 备 中 调试 第 三 方 
的 应 用 程序 的 话 ， 就 需要 对 设备 本 身 做 一 些 特殊 处 理 。 


下 面 我 们 来 分 析 一 下 GLTracer 的 内 部 实现 原理 。 


GLTracer 的 源码 也 在 Android 工 程 中 ， 具 体 路 径 是 
sdk\eclipse\plugins\com. android. ide. eclipse. gldebugger。 为 了 
让 大 家 可 以 快速 地 理解 整个 流程 ， 我 们 下 面 只 提取 实现 中 最 核心 的 部 
分 ， 如 下 所 示 : 


/*sdk\eclipse\plugins\com.android.ide.eclipse.gldebugger\src\com\ 
private void connectToDevice() { 
Shell shell = Display.getDefault().getActiveShell();//She 
GLTraceOptionsDialog dlg = new **GLTraceOptionsDialog**(s 
/* GLTrace0ptionsDialog 是 前 述 我 们 看 到 的 选项 配置 对 话 框 */ 
if (dlg.open() != Window.OK) { 
return; 
} 


TraceOptions traceOptions = dlg.getTrace0ptions();// 获 取 用 
IDevice device = getDevice(trace0ptions.device);// 目 标 设备 


try { 
**setupForwarding** (device, LOCAL_FORWARDED_PORT) ; 
} catch (Exception e) { 
MessageDialog.openError(shell, "Setup GL Trace", 
"Error while setting up port forwarding: " + 


return; 
} 
try { 
if (!SYSTEM_APP.equals(traceOptions.appToTrace)) { 
**startActivity**(device, traceOptions.appToTrace, 
traceOptions.activityToTrace, 
traceOptions.isActivityNameFullyQualified 


} catch (Exception e) { 
MessageDialog.openError(shell, "Setup GL Trace", 
"Error while launching application: " + e.get 
return; 


// if everything went well, the app should now be waiting 
// to connect 

**startTracing**(shell, traceOptions, LOCAL_FORWARDED_PORT); 
// once tracing is complete, remove port forwarding 
disablePortForwarding(device, LOCAL_FORWARDED_PORT); 
// and finally open the editor to view the file 
openInEditor(shell, traceOptions.traceDestination); 


其 中 最 关键 的 几 个 步骤 是 
Step1. Port Forwarding 


通过 端口 转发 ， 让 运行 于 PC 上 的 程序 部 可 以 与 运行 于 终端 手机 /模拟 
器 上 的 程序 直接 通过 TGP/1P 进 行 通信 。 具 体 实现 函 
createForward@lDevice， 有 兴趣 的 读者 可 以 自行 9 分 析 源码 了 解 详情 。 
在 我 们 这 个 场景 中 ， 需 要 将 Unix Domain Socket Name 为 “gltrace” 的 
服务 转发 到 6039 来 完成 Client/Server 式 的 通信 机 制 |。 


Step2， 显 示 GLTrace0ptionsDialog， 用 于 收集 用 户 针对 GLTracer 
的 各 个 配置 值 


包括 目标 设备 、 需 要 被 追踪 的 包 名 和 Activity 信 息 等 。 
Step3.， 调 用 startActivity 来 启动 需要 被 追踪 的 目标 程序 
这 个 startActivity 显 然 不 是 我 们 在 Android 应 用 程序 开发 中 经 常 使 


用 的 startActivity。 它 的 主要 职责 是 利用 /system/bin/am 来 启动 目标 
程序 ， 具 体 命令 如 下 : 


"am start —-opengl-trace %s -a android. intent. action. MAIN 
-c android. intent. category. LAUNCHER" 


其 中 “%s” 是 由 目标 程序 的 包 名 和 Activity 名 称 组 成 的 字符 
串 ;，“-a” 选 项 表示 需要 为 1ntent 添 加 一 项 Action; “-c” 表 示 添 加 
Category。 至 于 am 对 此 命令 的 处 理 流程 ， 我 们 稍 后 会 做 介绍 。 


Step4， 调 用 startTracing， 开 始 接收 Server 端 发 送 过 来 的 Trace 数 
HE 


Step5， 以 图 形 化 的 方式 显示 上 述 采 集 的 数据 


接 下 来 我 们 从 /system/bin/am 的 角度 来 分 析 ， 它 是 如 何 帮 助 
GLTracer 完 成 对 程序 中 的 0penGL 命 令 流 追踪 的， 相关 帮助 信息 如 图 17- 
13 所 示 。 


at: start an Activity. Options are: 
: enable debugging 
I: wait for launch to complete 
—-start—profiler <FILE>: start profiler and send results to <FILE> 
-P <FILE>: like above. but profiling stops when app goes idle 
-R: repeat the activity launch <COUNT> times. Prior to each repeat. 


the top activity will be finished. 


-§: force stop the target app before starting the activity 

—-opengl-trace: enable tracing of OpenGL functions 

—-user <USER_ID> [| current: Specify which user to run as; if not 
specified then run as the current user. 





全 图 17-13 帮助 信息 


系统 bin 目 录 下 的 am 是 一 个 she11 脚 本 ， 它 在 准备 好 各 种 参数 后 ， 会 
直接 调用 前 面 章节 分 析 过 的 app_process。 我 们 知道 ，app_process 除 了 
承担 在 系统 启动 过 程 中 运行 Zygote 的 重任 外 ， 还 支持 运行 一 个 虚拟 机 来 
承载 外 部 用 户 传递 进来 的 Java 类 。 在 我 们 这 个 场景 中 ， 被 启动 的 主 类 是 
am， 而 后 者 又 继承 于 BaseCommand。am 重 载 了 BaseCommand 的 onRun 消 
数 ， 用 于 解析 外 部 传 入 的 各 种 参数 ， 以 决定 下 一 步 的 计划 。 


am 在 发 现 参 数 中 的 子 命令 是 “start” 后 ， 调 用 runStart 进 行 处 
理 。 如 果 是 需要 跟踪 0penQL 命 令 的 情况 ， 那 么 主要 的 区 别 在 于 
StartActivity 时 传 入 的 Flag 参 数 。 具 体 而 言 ， 我 们 需要 指定 
ActivityManager. START FLAG OPENGL TRACES 来 保证 


ActivityManagerService 在 启动 目标 Activity 时 可 以 正确 按照 开发 者 的 
意图 进行 处 理 。 


服务 端 对 于 这 个 Flag 的 处 理 在 
resolveActivity@ActivityManagerSuperVisor. java 中 ， 核 心 代 码 如 下 
所 示 : 


/**/ 
ActivityInfo resolveActivity(Intent intent, String resolvedTy 
ProfilerInfo profileriInfo, int userId) 4... 
if ((startFlags&ActivityManager .START_FLAG_OPENGL_TRA 
if (!aInfo.processName.equals("system")) { 
mService.setOpenGlTraceApp(aInfo.applicationI 
aInfo.processName ) 


A, 


其 中 mService 对 应 的 是 大 家 熟悉 的 ActivityManagerService， 那 么 
它 在 对 待 这 种 类 型 的 程序 时 会 做 什么 特殊 处 理 呢 ? 函数 
set0penG1TraceApp 在 前 面 分 析 权 限时 大 家 已 经 遇 到 过 了 。 这 里 假设 我 
们 可 以 成 功 通过 权限 的 检测 过 程 ， 这 种 情况 下 AMS 就 会 把 需要 跟踪 的 程 
序 添加 到 全 局 变量 m0penG1TraceApp 中 。 


接着 AMS 会 通过 一 系列 的 startActivity 函 数 来 局 动 目 标 进程 和 
Activity， 上 有 具体 过 程 可 以 参考 本 书 其 他 章节 。 目 标 进程 准备 就 绪 后 ， 将 
Isl BattachApe cationdAo iv ityManacerServices 完成 attach 后 AMS 
同样 会 通知 目标 进程 ， 对 应 的 函数 是 
nd Na te 不 过 程序 并 不 会 立即 处 理 这 个 事 
件 ， 而 是 通过 H. BIND_APPLICATION 来 将 其 加 入 队列 中 。 


ActivityThread 对 这 个 消息 的 处 理 分 支 如 下 : 


case BIND_APPLICATION: 
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, 
AppBindData data = (AppBindData)msg.obj; 
handleBindApplication(data) ; 
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGE 
break; 


Trace. traceBegin 需 要 与 Trace. traceEnd 配 套 使 用 ， 用 于 产生 可 由 
Systrace 工 具 处 理 的 输入 数据 。Systrace 可 以 帮助 开发 者 分 析 应 用 程序 


或 系统 进程 的 执行 时 间 ， 并 最 终 得 出 描述 Android 系 统 运行 情况 的 HTML 
$e. eyhandleBindApp! ication 50penGL Trace 相关 的 代码 如 
下 : 


private void handleBindApplication(AppBindData data) {... 
if (data.enableOpenGlTrace) { 
GLUtils.setTracingLevel(1); 
} 


GLUti1s 是 Android AP1 与 0pengGL ES 之 间 沟 通 的 “桥梁 ”， 其 提供 
的 接口 大 多 需要 本 地 层 洱 数 来 支撑 ， 包 括 setTracingLevel。 这 个 函数 
的 Native 实 现 如 下 : 


/*frameworks/base/core/jni/android/opengl/util.cpp*/ 
extern void setGLDebugLevel(int level); 
void setTracingLevel(JNIEnv *env, jclass clazz, jint level) 


setGLDebugLevel(level); 


函数 setGLDebugLeve1 的 实现 在 eg1 中 : 


/*frameworks/native/opengl/libs/EGL/egl.cpp*/ 

void EGLAPI setGLDebugLevel(int level) { 
setEGLDebugLevel(level); 

上 


这 个 函数 所 提供 的 功能 是 帮助 程序 修改 自身 的 调试 等 级 。 不 过 要 特 
别 注意 的 是 ， 函 数 setEGLDebugLeve1 只 是 改变 了 Debug Level AVA (A 
体 来 说 ， 是 为 sEGLDebugLevel1 这 个 变量 赋 子 新 的 数值 ) ， 真 正 生 效 则 要 
等 到 initEg1DebugLevel 《如 果 程 序 还 没有 完成 初始 化 ) 或 者 
eg1SwapBuffers 被 调用 的 时 候 。 以 后 者 为 例 ，eg1SwapBuffers 在 执行 时 
会 首先 判断 当前 是 否 开启 了 调试 模式 : 


/*frameworks/native/opengl/libs/egl/eglApi.cpp*/ 
EGLBoolean eglSwapBuffers(EGLDisplay dpy, EGLSurface draw) 


ATRACE_CALL(); 


#if EGL_TRACE 
gl_hooks_t const *trace_hooks = getGLTraceThreadSpecific(); 
if (getEGLDebugLevel() > 0) {// 当 前 是 否 将 Debug Level XB W1 
if (trace hooks == NULL) { 


if (**GLTrace_start**() < 0) {// 稍 后 我 们 分 析 这 个 函数 
ALOGE("Disabling Tracer for OpenGL ES"); 
setEGLDebugLeve1(0) ;// 无 法 正常 开启 追踪 ， 需 要 将 其 关闭 
} else { 
// switch over to the trace version of hooks 
EGLContext ctx = egl_tls_t::getContext();/*##Con 
ADEA NE 
egl_context_t * const c = get_context(ctx); 
if (c) { 
setGLHooksThreadSpecific(c->cnx->hooks[c->ver 
GLTrace_eglMakeCurrent(c->version, c->cnx->ho 











} 
} 
GLTrace_eglSwapBuffers(dpy, draw); 
} else if (trace_hooks != NULL) { 


} 
#endif 


return s->cnx->egl.eglSwapBuffers(dp->disp.dpy, s->surface); 


假如 Debug Level 的 值 被 设置 为 1， 那 么 eg1 在 swap buffer 时 会 调用 
GLTrace_start 来 启动 OpenGL 命 令 流 的 跟踪 。 简 单 来 讲 ， 就 是 在 上 述 的 
else 分 支 中 将 用 户 对 eg 1 的 调用 从 以 前 单纯 的 eg 1 接口 ， 转 化 为 带 调 试 信 
息 的 G6LTrace_eg1 接 口 (0penGL 的 接口 也 是 类 似 的 ) 。 举 个 例子 来 说 
明 ， 经 过 GLTrace 的 特别 Hook 处 理 后 的 eglSwapBuffers 接 口 变 为 : 


/*frameworks/native/opengl/libs/gles_trace/src/Gltrace_egl.cpp*/ 
void GLTrace_eglSwapBuffers(void* /*dpy*/, void* /*draw*/) { 
GLMessage glmessage; 
GLTraceContext *glContext = getGLTraceContext(); 
glmessage.set_context_id(glContext->getId()); 
glmessage.set_function(GLMessage: :eglSwapBuffers) ; 
if (glContext->getGlobalTraceState( )->shouldCollectFbOnEg1lSwa 
// read FBO since that is what is displayed on the screen 
fixup_addFBContents(glContext, &glmessage, FBO); 


// set start time and duration 
glmessage.set_start_time(systemTime()); 
glmessage.set_duration(0); 
glContext->traceGLMessage(&glmessage) ; 


其 中 glmessage 用 于 收集 需要 向 PC 客户 端 反馈 的 信息 ， 包 括 了 


context id、 函 数 名 、 开 始 时 间 等 。 当 然 ，eg1 提 供 的 几 个 接口 比较 特 
殊 。 如 果 是 “openg1 ”类 型 的 接口 ， 那 么 它们 在 被 Hook 后 仍 需要 调用 原 
始 的 实现 。 换 名 话说，GLTrace 只 是 在 原 有 内 容 的 “ 头 部 ”和 “ 尾 

部 ”添加 了 自己 需要 的 信息 而 已 ， 并 不 改变 原先 的 运行 属性 。 


后 我 们 再 来 看 下 GLTrace_start 中 具体 是 如 何 启 动 一 个 监听 
Server 的 : 


/*frameworks/native/opengl/libs/GLES_trace/src/gltrace_eglapi.cpp 
int GLTrace_start() { 

int status = 0; 

int clientSocket = -1; 

TCPStream *stream = NULL; 

pthread_mutex_lock(&sGlTraceStateLock) ; 

if (sGlTraceInProgress) { 

goto done; 


} 

char udsName[PROPERTY_VALUE MAX]; 

property_get("debug.egl.debug_portname", udsName, "gltrace"); 
指定 的 debug_ portname， 否 则 采用 默认 值 

clientSocket = gltrace: :acceptClientConnection(udsName) ; //)az 








sGlTraceInProgress = 1;// 进 入 跟踪 状态 
// create communication channel to the host 
stream = new TCPStream(clientSocket ) ; 
// initialize tracing state 
sGLTraceState = new GLTraceState(stream) ; 
pthread_ array ery a NULL, commandReceiveTask, s 
/* 建 立 与 PC 端的 数据 传输 通道 */ 
done: 
pthread mutex_unlock(&sGlTraceStateLock); 
return status; 





我 们 知道 ， 用 户 在 使 用 GLTracer 收 集 数 据 的 过 程 中 是 可 以 动态 更 改 
采集 选项 的 ， 比如 enable/disable “Read back framebuffer 0 on 
eg|SwapBuffers()” “Read back currently bound framebuffer On 
glDrawk ()” 等 。 el eg! A conmandRece i veTask ifisi A r 
传递 过 来 的 命令 ， 并 做 好 实时 的 更 新 和 调整 人 
(Server) 和 位 于 PC 端的 GLTracer 间 的 通 ees 了 ， 后 续 只 需要 在 这 
道上 不 停 地 收发 信息 就 可 以 了 。 


下 面 是 本 小 节 所 阐述 的 各 个 组 件 间 的 交互 流程 图 ， 如 图 17-14 所 


示 。 由 于 整个 实现 过 程 涉及 的 范围 较 广 ， 我 们 特别 将 其 拆 分 为 两 个 部 
分 ， 以 方便 大 家 阅读 。 


Activity 


l ‘system M 
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ActivityThread 在 收 到 bindApplication 请 求 后 的 处 理 ， 如 图 17-15 
所 示 。 
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第 18 章 | 
“系统 的 UI” 一 一 SystemU| 


从 名 称 来 理解 ，SystemUl 是 指 “ 系 统 的 U1”。Android 系 统 的 版 本 
更 新 频率 非常 快 ， 且 每 次 改版 的 力度 也 很 大 。 典 型 的 例子 就 是 
SystemU1， 它 是 直到 后 期 版 本 才 出 现 的 一 个 概念 一 一 SystemUl 以 应 用 程 
序 〈 它 是 一 个 标准 的 APK) 的 形式 提供 了 系统 U1 丙 面 的 统一 管理 方案 。 


那么 ， 属 于 Android 系 统 的 UI 元素 有 了 哪些 ? 

首先 映 入 脑海 的 应 该 是 状态 通知 栏 。 没 错 ， 这 的 确 是 SystemU1 的 重 
点 之 一 ， 不 过 显然 不 是 它 的 全 部 组 成 元 素 。Google 和 希望 能 在 一 套 代 码 中 
同时 支持 Phone 和 Tablet 这 两 种 产品 类 别 一 一 作为 系统 “门面 ”的 
SystemU1 在 设计 时 必然 要 重点 考虑 这 一 点 。 

所 以 ， 本 章 我 们 主要 分 析 以 下 几 个 问题 : 


e SystemUI 包 含 哪些 元 素 ; 
e SystemUI 中 的 元 素 特 点 和 内 部 实现 ; 
。 SystemUI 是 如 何 做 到 兼容 多 种 产品 的 。 


18. 1 SystemUl 的 组 成 元 素 


System Bars: 


我 们 借用 Android 官 网 中 的 一 张 图 片 来 让 读者 有 个 直观 的 印象 ， 如 
图 18-1 所 示 。 





全 图 18-1 System Bars 


可 以 看 到 ，System Bars 为 了 同时 支持 Phone 和 Tablet， 共 分 为 3 
种 。 


e Status Bar 


EARRAS, ECT FAREA, me 
是 一 直 存 在 的 “除非 应 用 程序 主动 设置 了 隐藏 〉。 为 了 万 便 使 用 ， 它 被 
大 致 划分 为 左右 两 部 分 (准确 来 讲 不 止 两 部 分 ， 下 一 小 节 会 有 分 析 ) 。 
其 中 左边 用 于 通知 信息 的 显示 《比如 接收 到 一 条 短信 ， 会 有 相应 的 图 标 
指示 〉; 右边 则 是 全 局 的 设备 状态 ， 如 时 间 、 电 池 电 量 、 信 号 强度 等 。 
为 了 互 不 干扰 ， 左 右 两 边 的 图 标 是 沿 不 同 的 方向 不 断 扩展 的 左 半 部 
分 “从 左 到 右 ” 增 加 图 标 ， 另 一 边 则 恰好 相反 ) 。 当 拖 住 Status Bar 向 
下 拉 时 ， 可 以 显示 出 通知 栏 。 


e Navigation Bar 
这 是 Android 4. 0 以 后 才 加 入 的 元 素 。 目 的 有 两 个 : 
° 为 那些 没有 物理 按键 的 设备 提供 便利 ; 


° 2. 3 和 以 前 版 本 的 应 用 程序 多 半 是 需要 Menu 键 的 ，Navigation 
Bar 可 以 提供 Home、Back、Recents 和 Menu (一 般 是 常 按 Recents 出 
现 Menu) 来 满足 它们 的 要 求 。 


° Comb ined Bar 


这 是 专门 为 Tablet 设 计 的 一 种 系统 栏 形式 。 它 和 Phone 产 品 的 最 大 
区 别 在 于 ，Phone 通 常 是 坚 屏 ， 而 Tablet 是 横 屏 。 这 也 意味 着 手机 设备 
的 高 度 相 比 于 Tablet 比 较 宽 裕 ， 因 此 后 者 不 太 适 合同 时 显示 两 条 Bar 。 
而 又 因 其 宽度 值 较 大 ， 我 们 完全 可 以 利用 这 个 特点 来 兼容 Phone 中 的 所 
有 导航 和 状态 栏 功能 ， 于 是 就 出 现 了 Comb ined Bar 〈 如 图 18-1 标 
注 “3?” 的 部 分 ) 。 


Notifications: 


再 来 看 看 通知 栏 的 样子 ， 如 图 18-2 所 示 的 图 片 也 来 自 于 Android 官 
网 。 左 边 是 通知 栏 显示 若干 条 目 时 的 样式 ， 右 边 则 是 对 条 目 进行 删除 
〈 将 条 目 向 左 或 向 右 滑动 ) 时 的 效果 。 





全 图 18-2 Notifications 


相信 读者 对 通知 栏 也 不 会 陌生 ， 它 一 直 存 在 于 Android 的 各 发 行 版 
本 中 。 不 过 后 期 版 本 中 还 是 加 入 了 不 少 新 特性 。 


。 通知 信息 格式 可 定制 


早期 版 本 是 两 行 显示 ， 即 第 一 行 用 于 标题 ， 第 二 行 则 是 内 容 。 但 这 
并 不 是 必需 的 ， 你 可 以 根据 需求 来 做 更 改 。 


。 RRS FPR 
比如 你 可 以 通过 向 左 或 者 向 右 滑动 条 个 条 目 来 删除 它 。 
© 文 持 更 多 销 用 功能 


如 上 图 所 示 的 第 一 个 条 目 ， 它 表明 屏幕 的 “截图 操作 ”已 经 完成 。 
用 户 可 以 通过 点 击 条 目 来 进行 分 享 等 操作 。 


其 他 : 


除 此 之 外 ，SystemU1 还 实现 了 很 多 实用 的 系统 功能 ， 如 “最 近 运 行 
的 应 用 程序 ”、ScreenShot 截 屏 、 壁 纸 (后 面 小 节 有 专门 介绍 ) 等 。 





18.2 SystemU1 的 实现 


了 解 了 SystemU1 的 组 成 元 素 后 ， 本 节 以 StatusBar 为 例 ， 来 分 析 下 
Android 系 统 具体 是 如 何 实现 它们 的 。 


相关 代码 分 为 两 部 分 ， 即 : 
e Service 部 分 


代码 路 径 : 


frameworks/base/services/ java/com/android/server © 
e 应 用 部 分 
代码 路 径 : frameworks/base/packages/SystemUl. 


从 SystemU1 目 录 中 的 文件 可 以 看 出 ， 它 是 一 个 标准 的 应 用 程序 。 而 
通常 分 析 一 个 应 用 程序 的 入 口 点 有 两 个 。 


入 口 一 : AndroidManifest. xml 


AndroidManifest 文 件 的 功能 有 点 类 似 于 一 本 书 的 目录 ， 可 以 很 清 
楚 地 了 解 到 它 的 章节 架构 、 章 节 标 题 以 及 每 个 章节 的 主要 内 容 。 下 面 来 
看 看 SystemU1 的 “目录 ”， 如 下 所 示 : 


<applicationandroid:persistent="true"android:allowClearUserData=" 
android:allowBackup="false"android:hardwareAccelerated="true"andr 
<service android: name="SystemUIService"android:exported="true"/> 
/*SystemUIService 是 我 们 分 析 的 重点 ， 状 态 栏 等 系统 UI 实现 都 是 在 这 
<service android:name=".screenshot.TakeScreenshotService" 
android:process=":screenshot" android:exported="false" />/* 由 此 
截屏 操作 。 有 兴趣 的 读者 可 以 自己 
<receiver android:name=" .BootReceiver"androidprv:primaryUserOonly 
不 过 这 里 启动 的 是 LoadAverageService， 而 不 大 
<intent-filter> 
<action android:name="android.intent.action.BOOT_COMPLETED" /> 
</intent-filter> 
</receiver> 


从 上 面 的 文件 可 以 看 出 SystemU1 可 谓 “ 包 罗 万 象 ”。 
AOZ: Layout 


第 2 个 分 析 应 用 程序 的 入 口 就 是 布局 文件 。 如 果 说 上 面 的 
AndroidManifest 是 一 本 书 的 “目录 ”， 那 么 布局 文件 则 是 它 的 子 目 录 
揭示 了 每 一 章节 更 详细 的 内 容 。 


通过 AndroidManf iest 我 们 知道 SystemUlService 是 整个 系统 UI 
的 “载体 ”， 所 以 接 下 来 将 根据 这 一 线索 来 把 整个 代码 流程 “ 串 ” 起 
来 。 和 其 他 很 多 系统 服务 一 样 ，SystemUlService 也 是 在 SystemServer 
中 局 动 的 。 具 体 而 言 ，SystemServer 会 在 适当 的 时 机 通知 
ActivityManagerService “RACAT (systemReady) ， 可 以 进 一 
步 运 行 第 三 万 模块 了 这 其 中 就 包括 将 由 startServiceAsUser 局 动 
的 SystemUlService。 








SystemUlService 继 承 了 标准 的 Service 组 件 ， 因 而 必须 重 载 


onCreate 接 口 : 


/*frameworks/base/packages/systemui/src/com/android/systemui/Syst 
public void onCreate() 4.. 
IWindowManager wm = WindowManagerGlobal.getWindowManagerS 
try { 
SERVICES[0] = wm.hasSystemNavBar()? R.string.config_sy 
: R.string.config_statusBarComponent;//StatusBari&eS 
} catch (RemoteException e) { 
Slog.w(TAG, "Failing checking whether status bar can 


} 
final int N = SERVICES.1length; 
mServices = new SystemUI[N]; 
for (int 1=0; i<N; i++) { 
Class cl = chooseClass(SERVICES[i]); 
Slog.d(TAG, "loading: " + cl); 
try { 
mServices[i] = (SystemUI)cl.newInstance(); 


To ae 
mServices[i].mContext = this; 
Slog.d(TAG, "running: " + mServices[i]); 





mServices[i].start();//mServices 中 的 每 个 元 素 都 继承 自 Syste 


} 


SERV1CES 是 一 个 object 数 组 ， 它 的 初始 值 如 下 所 示 : 


final Object[] SERVICES = new Object[] { 
©, // system bar or status bar, filled in below. 
com.android.systemui.power.PowerUI.class, 
com.android.systemui.media.RingtonePlayer.class, 
com.android.systemui.settings.SettingsUI.class, 


}; 


其 中 ，SERV1CES[0] 在 初始 化 时 没有 赋值 。 它 将 根据 
hasSystemNavBar 的 执行 结果 来 决定 是 用 systemBar 还 是 statusBar 。 上 
面 这 段 代 码 首 先 取 出 SERV1CES 数 组 中 的 class 名 ， 然 后 分 别 实 例 化 它 
们 ， 最 后 调用 start 接 口 统 一 局 动 。 因 此， 每 一 个 系统 ui 元素 (BH 
statusBar，PowerUl 等 ) 都 必须 继承 自 SystemU1 这 个 抽象 类 ， 并 重 载 其 
中 的 start 方 法 。 这 是 一 种 比较 灵活 的 编程 方式 ， 它 允许 我 们 在 后 期 对 
系统 U1 元素 进行 轻松 的 扩展 或 者 删除 。 


疯 数 hasSystemNavBar 做 了 哪些 判断 来 对 statusBar 和 systemBar 进 
ITRE? 


根据 前 面 章节 学 习 到 的 知识 ，WindowManager 的 真正 实现 体 是 
WindowManagerService。 所 以 : 


/*frameworks/base/services/java/com/android/server/wm/Window 
public boolean hasSystemNavBar() { 

return mPolicy.hasSystemNavBar (); 
} 


我 们 知道 ，Policy 是 Android 中 定义 U1 行为 的 一 个 “规范 ”。 比 如 
没有 Navigation Bar，WindowLayer 如 何 排 布 等 。 以 
PhoneWindowManager 为 例 ， 它 判断 当前 系统 是 否 需要 导航 条 的 关键 源码 
如 下 《为 了 帮助 大 家 更 好 地 理解 处 理 流程 ， 我 们 假设 设备 的 分 辩 率 是 
800*480， 屏 幕 密度 为 |dpi) : 


/*frameworks/base/policy/src/com/android/internal/policy/impl/Pho 

int shortSizeDp = shortSize*DisplayMetrics.DENSITY_DEFAULT 

/* 在 这 个 场景 中 ，shortSize=480, DENSITY_DEFAULT=160, density 
shortSizeDp = 640*/ 


if (shortSizeDp < 600) {// 在 这 个 场景 中 不 成 立 
mHasSystemNavBar = false; 
mNavigationBarCanMove = true; 

} else if (shortSizeDp < 720) {/* 本 场景 属于 这 一 分 支 */ 
mHasSystemNavBar = false; 











mNavigationBarCanMove = false; 
} 
if (!mHasSystemNavBar) {// 进 一 步 判 断 是 否 有 Navigation Bar 


} else { 
mHasNavigationBar = false; 
} 


由 上 面 的 代码 段 可 知 ， 系 统 将 分 为 3 种 判决 情况 
@ 0-599dp 


说 明 该 设备 是 一 “phone”， 并 且 带 有 单独 的 StatusBar 和 


NavigationBar. 
e 600-719dp 


说 明 该 设备 是 一 一 “phone”， 并 且 可 以 适当 修正 U1 以 适应 大 屏 
幕 。 


° 720dp 以 上 


说 明 该 设备 是 一 一 “tablet”， 并 且 带 有 Combined 
Status&Navigation Bar. 


所 以 在 这 个 场景 中 ， 经 过 上 面 的 判决 后 mHasSystemNavBar 为 
false. 换 句 话说 ， 对 于 分 辨 率 800*480 且 密度 为 1dpi 的 屏幕 ， 它 的 
SERVICES [0] 对 应 的 class 类 名 是 R. string. config statusBar 
Component 
Bl) “com. android. systemui. statusbar. phone. PhoneStatusBar”。 T 


面 以 PhoneStatusBar 为 例 来 看 看 它 的 创建 过 程 及 具体 样式 : 


/*frameworks/base/packages/systemui/src/com/android/systemul 
PhoneStatusBar.java*/ 
public void start() { 
mDisplay = ((WindowManager )mContext.getSystemService(Cont 
.getDefaultDisplay();/*mDisplay 记 录 了 当前 默认 显示 屏 世 


super.start():// 关键 语句 ， 下 面 我 们 会 重点 介绍 
addNavigationBar();/* 不 是 所 有 Phone 祁 需要 Navigation Bar. el 
键 ， 这 种 情况 下 如 果 一 直 在 屏幕 上 显示 导航 条 反 
































t 


PhoneStatusBar 的 “ 父 类 ”是 BaseStatusBar， 很 多 框架 性 的 操作 
都 是 在 这 里 面 完 成 的 《〈 但 U1 珊 面 的 具体 描述 还 是 会 通过 回调 
PhoneStatusBar 中 的 方法 来 确定 ) : 


/*frameworks/base/packages/systemui/src/com/android/systemui/s 
usBar.java*/ 
public void start() {.. 
mBarService = IStatusBarService.Stub.asInterface( 
ServiceManager .getService(Context.STATUS_BAR_SERVIC 
// Connect in to the status bar manager service 
StatusBarIconList iconList = new StatusBarIconList();// 状 态 相 
ArrayList<IBinder> notificationKeys = new ArrayList<IBinder 
ArrayList<StatusBarNotification> notifications = new ArrayL 
mCommandQueue = new CommandQueue(this, iconList); 
int[] switches = new int[7]; 
ArrayList<IBinder> binders = new ArrayList<IBinder>(); 
try { 
mBarService.registerStatusBar (mCommandQueue, iconList,no 
notifications, switches, binders); /* 经 过 一 系列 对 象 
StatusBarService 进 行 注册 。 这 里 涉及 跨 进 
参数 都 是 继承 自 Parcelable 的 */ 
} catch (RemoteException ex) { 
// If the system process isn't there we're doomed anywa 


} 
createAndAddWindows(); /* 这 是 真正 将 Status Bar 显 示 出 来 的 地 方 */ 


} 
好 不 容易 快 到 “水 落石 出 ”的 时 候 了 ， 但 是 上 面 这 段 代码 却 又 杀 出 
一 个 “ 程 咬 金 ”一 一 StatusBarService。 相 信 读 者 会 有 这 样 的 疑问 : BE 


然 SystemU1 这 个 应 用 程序 中 已 经 有 StatusBar 了 ， 为 什么 又 需要 
StatusBarService， 是 否 多 此 一 举 ? 


先 来 看 看 StatusBarService 是 在 哪里 局 动 的 。 直 觉 告 诉 我 们 应 该 是 
在 SystemServer 中 〈 读 者 也 可 以 通过 STATUS_BAR_SERVI1CE 对 应 的 关键 字 
来 查找 是 谁 向 ServiceManager 注 册 了 这 个 名 字 ) : 


/*frameworks/base/services/java/com/android/server/SystemSer 
try { 
Slog.i(TAG, "Status Bar"); 
statusBar = new StatusBarManagerService(context, wm); 
实现 类 叫做 StatusBarManagerService*/ 


ServiceManager .addService(Context.STATUS_BAR_SERVICE, 
} catch (Throwable e) { 
reportwtf("starting StatusBarManagerService", e); 
} 


现在 可 以 进一步 分 析 StatusBarManagerService 的 实现 了 。 针 对 上 
面 BaseStatusBar 中 调用 的 注册 操作 : 


public void registerStatusBar(IStatusBar bar, StatusBarIconList 1 
notificationKkeys, List<StatusBarNotification> 
int switches[], List<IBinde 
enforceStatusBarService(); 
mBar = bar; 
synchronized (mIcons) { 
iconList.copyFrom(mIcons); /* 复 制 Icon 列 表 ， 注 意 方向 是 从 Sta 
BaseStatusBar*/ 





} 
synchronized (mNotifications) { 
for (Map.Entry<IBinder,StatusBarNotification> e: mNoti 
notificationKeys.add(e.getKey()); 


notifications.add(e.getValue());/*#lIconw*#AW, JI 
到 BaseStatusBar*/ 


} 
由 上 面 这 段 代 码 可 以 看 出 ，registerStatusBar 有 两 个 作用 : 
为 新 启动 的 SystemU1 应 用 中 的 StatusBar 赋 子 当 前 系统 的 真 
ty (Les ORES 。 其 二 ， 通 过 成 员 变量 mBar 记 录 下 
1StatusBar 对 象 一 一 它 在 SystemU1 中 对 应 的 是 CommandQueue。 


那么 ， 人 ee 台 存 储 和 管理 数 
te CAASE AMES) 的 作用 呢 ? 稍 后 揭晓 


我 们 再 回 到 BaseStatusBar 。 向 StatusBarManagerService 注 册 完 成 
后 ， 它 会 执行 如 下 语句 。 


createAndAddWindows(); 


BaseStatusBar 中 的 这 个 方法 是 抽象 的 ， 因 而 其 子 类 


PhoneStatusBar 必 须要 重 载 它 


/*frameworks/base/packages/systemui/src/com/android/systemul 
oneStatusBar.java*/ 
public void createAndAddwWindows() { 

addStatusBarWindow(); 


private void addStatusBarWindow() { 
final int height = getStatusBarHeight();/* 首 先 获取 StatusBai 
过 com.android.internal.R.dimen.status_bai 
开发 人 员 如 果 需 要 更 改 StatusBar 高 度 的 话 ， 可 以 考 所 
final WindowManager.LayoutParams lp = new WindowManager.L 
ViewGroup.LayoutParams.MATCH_PARENT, /* %&2£4:MATCH 
height, // 高 度 值 是 可 定制 的 
WindowManager.LayoutParams.TYPE_STATUS_BAR, /* 指 定 
WindowManager .LayoutParams.FLAG_NOT_FOCUSABLE | 
WindowManager .LayoutParams .FLAG_TOUCHABLE_WHEN_ 
| WindowManager .LayoutParams.FLAG_SPLIT_TOUCH, 
/* 设 置 flag， 下 面 还 会 加 上 硬件 加 速 属性 */ 
PixelFormat . TRANSLUCENT /* 243% HH fy * ae 














—= 





lp.flags |=windowManager .LayoutParams.FLAG_HARDWARE_ACCEL 

lp.gravity = getStatusBarGravity();/* 设 置 Gravity 属 性 ， 默 认 值 

|Gravity.FILL_HORIZONTAL, 所 以 StatusBar 是 在 屏幕 上 方 */ 

lp.setTitle("StatusBar"); // 标 题 

lp.packageName = mContext.getPackageName(); 

makeStatusBarView(); // 下 面 会 详细 介绍 

mWindowManager .addView(mStatusBarWindow, lp); /将 一 切 就 绪 晶 
WindowManager 中 。 请 参见 本 书 显 示 系 统 章节 1 











从 makeStatusBarView 这 个 函数 名 可 以 推 疡 出 ，StatusBarView 会 被 
创建 并 且 初 始 化 。 先 来 了 解 下 两 个 重要 的 变量 。 


e mStatusBarWindow 


这 是 一 个 StatusBarWindowView 类 对 和 象 ， 同时 我 们 通过 addView 传 给 
WindowManager 的 也 是 这 个 变量 一 一 说 明 它 很 可 能 包含 了 
StatusBarView。 


e mStatusBarView 


这 就 是 makeStatusBarView 需 要 操作 的 对 象 。 


接着 来 具体 看 看 代码 ， 只 节选 重点 部 分 


/*frameworks/base/packages/systemui/src/com/android/systemui/stat 
StatusBar.java*/ 
protected PhoneStatusBarView makeStatusBarView() {... 
mStatusBarWindow = (StatusBarWindowView) View.inflate(con 
status_bar, null); 
mStatusBarWindow.mService = this; //mService 其 实 指 的 是 Phone 
mStatusBarwindow.setOnTouchListener(new View.OnTouchListe 
@Override 
public boolean onTouch(View v, MotionEvent event) { 
if (event.getAction() == MotionEvent.ACTION_DOWN ) 
if (mExpandedVisible) { 
animateCollapsePanels ();// 通 知 栏 的 “下 拉 展 开 ” 
} 
} 


return mStatusBarWindow. onTouchEvent(event ); 
}}); 
mStatusBarView =(PhoneStatusBarView)mStatusBarWindow. find 
mStatusBarView.setBar(this); /* 状 态 栏 出 场 了 */ 


mNotificationPanel = (NotificationPanelView) mStatusBarwi 
findViewById(R.id. notification 
mNotificationPanel.setStatusBar(this); /* 通 知 栏 也 很 关键 ， 只 不 过 
/* 从 下 面 开 始 将 利用 mStatusBarView 为 PhoneStatusBar 中 的 众多 内 部 变 ; 





try { 
boolean showNav = mWindowManagerService.hasNavigation 
if (showNav) { 
mNavigationBarView = (NavigationBarView) View. inf 
R.layout. navigation_ bar, n 
/*Navigation Bar 对 应 的 layout。 


} catch (RemoteException ex) 


/*Android 中 的 不 少 代 码 在 捕捉 异常 时 ， 很 常见 的 一 种 处 理 就 是 “ 听 天 1 


/* 接 下 来 通过 fijndViewById 从 mStatusBarView 中 获取 StatusIcons、N( 
ClearButton 等 一 系列 按键 。 我 们 将 会 在 StatusBar 布 局 文件 中 做 统一 4 


/* 最 后 动态 注册 需要 接收 的 广播 ， 比 如 系统 设置 改变 ， 屏 幕 关 闭 等 */ 
IntentFilter filter = new IntentFilter(); 

filter .addAction(Intent .ACTION_CONFIGURATION_CHANGED) ; 
filter .addAction(Intent.ACTION_CLOSE_SYSTEM_DIALOGS) ; 





















































context. ee ee filter)... 
return mStatusBarView;// 注 意 最 终 返回 值 是 mStatusBarWindow 的 子 \ 





} 


恋 量 mStatuBarWindow 来 源 于 super_status bar 布 局 。 它 本 质 上 还 
是 一 个 FrameLayout， 包 含 的 元 素 也 很 简单 ， 就 是 status_bar 和 
status bar expanded 两 个 布局 (SystemU1 的 资源 目录 下 有 多 种 带 不 同 
资源 标签 的 Layout， 系 统 会 根据 设备 的 具体 属性 来 做 出 合理 的 选择 ) 。 
关于 资源 的 最 佳 匹 配 过 程 ， 可 以 参见 前 面 资源 适 配 章节 。 


水 数 hasNavigationBar 用 于 决定 是 否 需 要 导航 条 。 
(1) 如 果 是 Tablet， 就 肯定 不 需 要。 


(2) 如 果 是 Phone， 那 么 还 要 根据 屏幕 属性 、 是 否 有 按键 值 以 及 用 
”是否 有 特别 配置 等 一 系列 因素 ， 来 最 终 确定 NavigationBar 存 在 与 
Bo 


最 后 来 总 结 一 下 makeStatusBarView 的 工作 。 


(1) 通过 inflate， 得 到 mStatusBarWindow， 对 应 的 是 
super_status bar 布 局 。 


super_status_bar¥& J status barylstatus_ bar expande 
(2) bar 包 含 了 bar 和 b ded 
两 个 子 布局 。 前 者 对 应 的 是 状态 栏 mStatusBarView， 后 者 其 实 就 是 通知 


栏 mNotificationPanel。 


(3) 为 status_bar 中 的 众多 元 素 〈 按 键 、 背 景 等 ) 进行 初始 化 。 


(4) 最 终 的 返回 值 是 mStatusBarView。 然 后 利用 WindowManager 的 
addView 接 口 将 mStatus- BarWindow (注意 : 不 是 mStatusBarView) A 
加 进 窗口 系统 中 。 接 下 来 的 主动 权 就 转交 给 WindowManager， 详 见 本 书 
显示 系统 章节 对 WindowManager 的 分 析 。 


由 此 可 见 ， 这 个 函数 如 果 称 之 为 makeStatusBarWindow 可 能 会 更 贴 
切 些 。 


这 样 我 们 就 把 StatusBar，Notification 和 NavigationBar 的 调用 流 
程 “ 串 ”起 来 了 。 图 18-3 是 整个 调用 流程 图 ， 读 者 可 以 参考 一 下 。 


SystemUIService 
| 






PhoneStatusBar 
| | 


mStatusBarView: status barxml 


mNotificationPancl: status bar_expanded.xml 


makeStatusBarView 





WindowManager 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


全 图 18-3 SystemUI (StatusBar) 的 显示 流程 图 


最 后 我 们 来 分 析 下 StatusBar 的 1ayout 布 局 样式 
的 显示 条 可 谓 “ 麻 八 虽 小， 五 脏 俱全 ”。 


我 们 知道 ，StatusBarWindow 的 默认 高 度 是 
com. android. internal.R. dimen. status bar_height, BJ: 





这 个 占 位 不 大 


<dimen name="status_bar_height">25dip</dimen> 


所 以 StatusBar 的 高 度 默认 情况 下 不 超过 25dip， 当 然 开 发 者 可 以 根 
据 需求 自行 更 改 。 


StatusBar 对 应 的 layout 文 件 是 status_bar. xm|， 具 体 如 下 所 示 : 


/*frameworks/base/packages/SystemUI/res/layout/status_bar .xml*/ 

<com.android.systemui.statusbar .phone.PhoneStatusBarView 

/* 对 应 PhoneStatusBarView 类 (继承 自 FrameLayout )， 也 就 是 上 面 代码 中 的 mStat 
android: id="@+id/status_bar"android: background="@drawable/sta 
android: focusable="true"android:descendantFocusability="after 
android: fitsSystemwindows="true"> 

<ImageViewandroid: id="@t+id/notification_lights_out"..android:visib 

<LinearLayout android:id="@+id/icons"android: layout_width="match_ 

android: Llayout_height="match_parent"android:orientation="h 


<LinearLayoutandroid: id="@+id/notification_icon_area" 
android: Layout_width="O0dip"android: layout_height="match_ 
android: layout_weight="1" /*4 种 icon 中 只 有 notification 设 置 J 
多 的 剩余 空间 */ 
android:orientation="horizontal">/V* 通 知 栏 图 标 在 最 左面 。 初 始 中 
任何 图 标 */ 
<com.android.systemui.statusbar.StatusBarIconView android:id="@+i 
/* 当 notificationIcons 满 了 以 后 
android: Layout_width="@dimen/status_bar_icon_size" / 
android: Llayout_height="match_parent"android:src="@dr 
android:visibility="gone"/* 正 常情 况 下 是 不 需要 显示 的 */ 
/> 
<com.android.systemui.statusbar.phone.IconMerger android:id="@+id 


























android: Layout_width="match_parent"android: Layout_he 
android: layout_alignParentLeft="true" /* 从 左 到 右 */ 
android:gravity="center_vertical" /*icon 按 垂直 方向 中 间 ; 
android:orientation="horizontal"/> 

</LinearLayout> 





<LinearLayout android:id="@+id/statusIcons" /* 状 态 图 标 */ 
android: layout_width="wrap_content" /* 注 意 和 notifica 
android:layout_height="match_parent"android:gravity 


android:orientation="horizontal"/> 
<LinearLayout 
android:id="@+id/signal_battery_cluster" /* 用 于 信和 号 和 
android: Layout_width="wrap_content"android: layout_h 
android: paddingLeft="2dp"android:orientation="horiz 
android: gravity="center"> 
<include layout="@layout/signal_cluster_view" 
/* 信 号 指示 图 标的 集合 。 称 为 cluster， 是 因为 包括 26/36 网 络 信 号 ，L 
BlueTooth 等 图 标 都 在 这 里 集中 显示 */ 
android:id="@+id/signal cluster" 
android: Llayout_width="wrap_content"android: layout_h 
<ImageViewandroid:id="@+id/battery" /* 电 池 图 标 区 域 。 比 较 单一 ， 通 常 就 是 I 
android:layout_height="wrap_content"android:layout_ 
android:paddingLeft="4dip"/> 
</LinearLayout> 
<com.android.systemui.statusbar.policy.Clockandroid:id="@+id/cloc 
/ fey Fe A) PD. MRA I A EAT RE, UR NY Ta] Sk. * / 
android: textAppearance="@style/TextAppearance.StatusBar 
android: Layout_width="wrap_content"android: Layout_heigh 
android:singleLine="true"android:paddingLeft="6dip"andr 
center_vertical|left"/> 
</LinearLayout> 
<LinearLayout android: id="@+id/ticker"/ *j}£f#3*/ 


























</com.android.systemui.statusbar .phone.PhoneStatusBarView> 


注解 1: icons 其 实 是 水 平方 向 的 LinearLayout， 是 下 面 4 种 icon 


的 “容器 ”。 
e notification icons: 通知 图 标 。 


e status icons: 状态 图 标 。 
e signal_battery cluster: 信号 /电池 指示 。 
e clock: 时 钟 。 


注解 2: a B ERT 个 扩展 了 的 LinearLayout， 
其 中 加 入 了 不 少 额 算 通 知 栏 的 空间 是 否 已 满 ， 从 而 控 
制 morelcon 的 显示 。 











注解 3: Ticker 用 于 “提示 信息 ”的 临时 显示 。 它 在 显示 时 占 满 整 


个 状态 栏 ， 并 在 一 定时 间 后 自动 消失 (会 有 “出 现 和 消失 ”的 动画 效 
R) 。 比 如 我 们 插入 SD 卡 时 ，Ticker 上 会 提示 “SD 卡 设备 已 插入 ”。 这 
部 分 的 布局 样式 和 icons 类 似 ， 请 读者 自行 分 析 。 


图 18-4 概 括 了 status_bar 中 icons 部 分 的 布局 ， 供 读者 参考 理解 。 


imoreleon signal battery cluster 





notification icon area 





全 图 18-4 icons 部 分 的 layout 布 局 








18.3 Android 壁纸 资源 

除了 前 面 讲 解 的 状态 栏 、 通 知 栏 外 ， 壁 纸 也 属于 SystemUl 管 理 的 一 
个 重点 。 在 Android 系 统 中 ， 用 户 可 以 从 设备 内 部 或 者 外 存储 器 〈 比 如 
SD 卡 中 ) 中 选取 图 片 资 源 作 为 壁纸 。 另 外 ， 系 统 还 支持 动态 壁纸 的 显 
示 。 动 态 壁纸 的 基本 原理 是 随 着 时 间 的 迁移 而 切换 显示 不 同 的 图 片 资 
源 ， 属 于 Android 的 特色 功能 之 一 。 

从 实现 角度 来 讲 ， 可 以 把 壁纸 资源 分 为 两 类 。 

。 静态 图 片 


比如 jpg、png 等 类 型 的 图 片 。 用 户 可 以 直接 把 它们 设置 为 壁纸 。 


WallpaperService 


e APK 应 用 程序 


还 有 的 壁纸 下 载 后 是 APK 形 式 ， 用 户 需 要 安装 以 后 才能 正常 使 用 
(动态 壁纸 通常 就 是 通过 这 种 方式 提供 的 ) 。 不 过 这 并 不 是 说 静态 的 图 
卢 不 需要 APK 的 支持 一 一 事实 上 不 论 静态 、 动 态 壁纸 的 显示 都 是 由 APK 完 
成 的 ， 只 不 过 前 者 借助 于 系统 内 部 提供 的 APK 即 可 ， 而 后 者 的 “动态 多 
样 性 ”决定 了 其 需要 借助 于 额外 的 APK 来 实现 。 


不 管 是 哪 种 方式 ， 都 要 遵循 Android 系 统 的 壁纸 机 制 才 能 正常 工 
作 。 壁 纸 管理 系统 主要 包括 以 下 几 个 方面 。 


e WallpaperManagerService (WPMS) 


它 是 壁纸 机 制 的 “大 总 管 ”， 静 态 、 动 态 壁纸 都 是 在 这 里 统一 调度 


e WallpaperService (WPS) 


WPS 继 承 了 标准 的 Servi ce 组 件 ， 因 而 它 一 定 会 实现 onCreate、 
onDestroy、onBind 等 一 系列 方法 。 此 外 它 还 包含 了 一 个 重要 的 能 套 类 
engine， 我 们 在 后 面 会 做 详细 讲解 。WPS 是 静态 、 动 态 壁纸 的 基 类 ， 代 
表 了 作为 “壁纸 ”所 应 该 具有 的 一 切 属 性 。 


e ImageWallpaper (IWP) 


从 名 称 可 以 看 出 ， 它 是 静态 壁纸 的 实现 类 ， 而 且 一 定 是 继承 自 上 面 
的 WPS， 如 图 18-5 所 示 。 本 市 接 下 来 主要 以 静态 壁纸 的 分 析 为 主 。 


WallpaperService 


+onCreateEngine () 
\ N 人 


ImageWallpaper 动态 壁纸 实现 


全 图 18-5 各 壁纸 类 的 继承 关系 图 


18.3.1 WallPaperManagerService 
WPMS 既 然 是 基于 A1DL 实 现 的 ， 我 们 来 看 看 它 的 接口 描述 : 


/*frameworks/base/core/java/android/app/IWallpaperManager .aidl*/ 
interface IWallpaperManager { 
ParcelFileDescriptor setWallpaper(String name); /* 设 置 壁纸 */ 
void setwallpaperComponent(in ComponentName name); /* 设 置 动态 壁 
ParcelFileDescriptor getwallpaper (IwallpaperManagerCallback c 
wallpaperIinfo getWallpaperInfo(); 





从 上 面 的 接口 定义 可 以 看 出 ，WPMS 的 工作 并 不 复杂 一 一 它 提 供 了 全 
局 的 壁纸 注册 、 取 消 和 查询 功能 ， 并 在 接收 到 事件 时 进行 合理 分 配 。 


和 其 他 系统 服务 一 样 ，WPMS 是 在 SystemServer. java 中 局 动 并 注册 
进 ServiceManager 中 的 ， 如 下 所 示 : 


/*frameworks/base/services/java/com/android/server/SystemSer 


try { 
Slog.i(TAG, "Wallpaper Service"); 


if (!headless) { 
wallpaper = new WallpaperManagerService(context ) 
ServiceManager .addService(Context .wALLPAPER_SERV 


} 
} catch (Throwable e) { 
reportwtf("starting Wallpaper Service", e); 


接 下 来 的 一 个 问题 是 ;既然 系统 同时 支持 静态 壁纸 和 动态 壁纸 ， 而 
且 每 种 类 型 中 还 包含 了 N 个 实例 (比如 原生 态 系统 就 自 带 多 个 动态 壁纸 
供用 户 选择 ) ， 那 么 系统 在 显示 时 是 如 何 选择 的 呢 ? 我 们 很 自然 地 会 想 
到 ， 在 WPMS 启 动 时 它 应 该 会 去 读 取 某 个 “配置 文件 ”， 这 个 文件 记录 了 
用 户 最 近 一 次 的 选择 ， 


public WallpaperManagerService(Context context) { 


loadSet tingsLocked(UserHandle.USER_OWNER) ; /7 加载 配置 


当 WPMS 构 造 时 ， 它 调用 了 loadSettingsLocked: 
private void loadSettingsLocked(int userId) {// 这 里 传 进来 的 user 


try { 
stream = new FileInputStream(file); 
XmlPullParser parser = Xml.newPullParser(); 
parser.setInput(stream, null); 
int type; 
do { 
type = parser.next(); 
if (type == XmlPullParser.START_TAG) { 
String tag = parser.getName(); 
if ("wp".equals(tag)) {... 
wallpaper.name = parser.getAttributeValue 
String comp = parser.getAttributeValue(nu 


J 


} 
} while (type != XmlPullParser.END_DOCUMENT); 
success = true; 


3 


上 面 这 段 代 码 会 按照 写 入 时 的 格式 将 wal 1paper 的 配置 信息 读 出 
来 ， 并 保存 在 WallpaperData 结 构 中 一 一 专门 用 于 摘 述 壁纸 信息 的 通用 
数据 结构 。 不 过 这 时 壁纸 还 没有 真正 显示 出 来 ， 而 是 要 等 到 系统 进入 
Ready 状 态 《此 时 系统 会 回调 SystemReady 接 口 ) 后 才 会 通知 具体 的 壁纸 
程序 进行 绘制 | : 


public void systemReady() { 
WallpaperData wallpaper = mWallpaperMap.get(UserHandle.US 
switchWallpaper(wallpaper, null); 


} 
接着 进入 Wal1paper 的 具体 处 理 中 : 


void switchwallpaper (wallpaperData wallpaper, IRemoteCallback 
synchronized (mLock) {... 
try { 
ComponentName cname = wallpaper .wallpaperComponen 
wallpaper.wallpaperComponent : wallpaper.next 
if (bindWallpaperComponentLocked(cname, true, fal 


return; 


} 


系统 开机 后 ，wallpaper. wal1paperComponent 为 空 〈 除 非 上 一 次 用 
户 选 择 了 其 他 方式 ) ;而 wallpaper. nextWal lpaperComponent 则 在 
loadSett ingsLocked 中 被 设置 为 wal lpaper. imageWal | paper 
Component， 即 我 们 前 面 提 到 的 ImageWal lpaper 这 个 Service。 所 以 当 调 
用 bindWal lpaperComponent Locked 时 ， 传 入 的 cname 就 代表 了 
ImageWal lpaper。 从 bindWallpaperComponentLocked 的 函数 名 称 可 以 看 
出 ， 它 将 会 以 bindService 的 方式 来 后 动 目标 壁纸 Service 〈 所 以 后 期 如 
果 确 认 已 经 不 再 使 用 这 个 Service， 还 要 主动 执行 unbind， 然 后 这 个 壁 
纸 服务 就 会 自动 销毁 ) 。 


WPMS 局 动 后 就 可 以 接收 客户 端的 请 求 了 ， 因 为 它 属于 实名 的 
BinderServer， 意 味 着 所 有 人 都 可 以 自由 地 使 用 它 所 提供 的 服务 。 比 如 
我 们 既 可 以 在 系统 自 带 的 Launcher 应 用 程序 中 选择 壁纸 ， 也 完全 可 以 自 
己 编写 一 个 更 改 壁纸 的 应 用 程序 。 


下 面 我 们 以 设置 壁纸 这 一 场景 为 例 来 分 析 WPMS 的 内 部 实现 : 


/*frameworks/base/services/java/com/android/server/Wallpaper 
public ParcelFileDescriptor setWallpaper(String name) { 
checkPermission(android.Manifest.permission.SET_WALLPAPER 
synchronized (mLock) { 
int userId = UserHandle.getCallingUserId(); 
WallpaperData wallpaper = mWallpaperMap.get(userId); 


final long ident = Binder.clearCallingIdentity(); 
try { 
ParcelFileDescriptor pfd = updateWallpaperBitmapL 


return pfd; 


} finally { 
Binder .restoreCallingIdentity(ident); 
} 


} 


首先 系统 会 做 下 权限 检查 ， 所 以 提供 壁纸 设置 功能 的 应 用 程序 一 定 
要 在 AndroidManifest. xml 中 显 式 写 上 如 下 权限 声明 : 


<uses-permission android:name="android. permission. SET_WALLPAPER" 


变量 wal lpaper 是 从 mWallpaperMap 取 出 来 的 ， 代 表 User1d 为 0 时 的 
壁纸 一 一 如 果 不 为 空 就 进入 以 下 函数 : 


ParcelFileDescriptor updateWallpaperBitmapLocked(String name, 
if (name == null) name = ""; 
try { 
File dir = getWallpaperDir (wallpaper .useriId);//wallpa 
if (!dir.exists()) {// 指 定 的 路 径 不 存在 ， 需 要 创建 
dir.mkdir(); 
FileUtils.setPermissions(dir.getPath(), 
FileUtils.S IRWXU|FileUtils.S_ IRWXG|FileuU 


出 





File file = new File(dir, WALLPAPER); 
ParcelFileDescriptor=ParcelFileDescriptor.open(file, 


MODE_CREAT 
if (!SELinux.restorecon(file)) { 
return null; 


wallpaper.name = name; 
return fd; 

} catch (FileNotFoundException e) { 
Slog.w(TAG, "Error setting wallpaper", e); 


return null; 


Í 


上 面 getWal1paperDir 将 得 到 一 个 WALLPAPER BASE DIR+"/"+userld 
的 路 径 ， 其 中 WALLPAPER BASE_D1R 默 认 值 是 "/data/system/users"。 


图 18-6 是 user 1d 为 0 时 的 情况 。 


= (= users 2010-01-01 08:04 
= 0 1970-01-02 11:30 

=| accounts. db 57344 2010-01-01 08:04 

=| accounts. db—-journel 8720 2010-01-01 08:04 

|=) appwidgets. xml 483 1970-01-02 11:30 

=| packagerestrictions. xm] 2286 1970-01-02 11:30 


B wallpaper 310909 1970-01-02 





>) wallpeper_info, xml 150 1970-01-02 10:48 


A 418-6 UserId 为 O 时 的 情况 


假如 这 个 目录 不 存在 ， 要 首先 mkdir 出 来 ， 然 后 在 下 面 新 建 一 个 名 


为 WALLPAPER 即 “wal lpaper” 的 文件 ， 最 后 打开 这 个 文件 ， 并 将 描述 符 
返回 给 调用 者 。 


18.3.2 ImageWal | paper 


前 面 讲 过 ， 当 WPMS 开 机 启动 时 ， 默 认 情 况 下 会 选择 ImageWal | paper 
这 个 壁纸 实现 ， 并 且 以 bindService 的 方式 来 启动 它 。 在 bindService 
中 ，WPMS 同 时 传 入 名 为 newConn 的 Binder 对 象 (Wal |lpaperConnection) 
来 使 ImageWallpaper (其 他 WallpaperService 也 是 一 样 的 ) 可 以 访问 到 
WPMS。 而 ImageWal 1paper 则 响应 onBind 返 回 一 个 
IWallpaperServiceWrapper 的 Binder 对 象 ， 如 图 18-7 所 示 。 


WallpaperComnection 


WallpaperService 


[WallpaperService Wrapper 





全 图 18-7 WPMS 与 WPS 间 的 IPC 通 信 


我 们 来 看 看 当 绑 定 成 功 后 WPMS 中 的 操作 : 
public void onServiceConnected(ComponentName name, IBinder 
synchronized (mLock) { 
if (mWallpaper.connection == this) {.. 
attachServiceLocked(this, mWallpaper); 


saveSet tingsLocked(mWallpaper); 


} 


WPMS 除 了 要 保存 当前 所 选 的 壁纸 外 ， 还 要 调用 
attachServiceLocked (间接 调用 1wal1paper 


ServiceWrapper. attach) 来 执行 实际 的 工作 。 这 部 分 逻辑 比较 简单 ， 
我 们 就 不 细 化 分 析 了 。 


WPS 这 边 的 attach 国 数 将 生成 一 个 IWal lpaperEngineWrapper 对 象 并 
给 它 发 送 一 个 D0_ATTACH， 这 个 消息 最 终 由 1IWal |paperEngineWrapper. 
executeMessage 来 处 理 : 


public void executeMessage(Message message) { 
Switch (message.what) { 
case DO_ATTACH: { 

try { 
mConnection.attachEngine(this); 

} catch (RemoteException e) { 
Log.w(TAG, "Wallpaper host disappeared", 
return; 


Engine engine = onCreateEngine(); 
mEngine = engine; 
mActiveEngines.add(engine) ; 
engine.attach(this); 

return; 


} 


上 述 代 码 段 通过 onCreateEngine 生 成 了 一 个 壁纸 引擎 一 一 这 也 是 各 
壁纸 应 用 间 最 核心 的 差异 。 所 以 系统 要 求 每 一 个 Wal lpaperServi ce 实例 
人 在 ImageWallpaper 
, Cae 这 个 engine 随 后 会 被 加 入 
mAct iveEngines 的 全 局 1ist 中 ， 然后 调用 它 提供 的 attach 接 口 。 如 下 所 
示 : 











/*frameworks/base/core/java/android/service/wallpaper/Wallpa 
public class Engine 4... 
void attach(IWallpaperEngineWrapper wrapper) 4.. 
mSession = WindowManagerGlobal.getwWindowSession(); 
mWindow.setSession(mSession); 


IntentFilter filter = new IntentFilter(); 
filter .addAction(Intent.ACTION_SCREEN_ON); 
filter .addAction(Intent .ACTION_SCREEN_OFF); 
registerReceiver(mReceiver, filter); 


updateSurface(false, false, false);//##Surface 


Engine 内 部 首先 需要 进行 各 重要 变量 的 初始 化 ， 然 后 注册 监听 屏幕 
的 开 / 关 事件 ， 最 后 调用 updateSurface。 

我 们 知道 ，Wal1lpaperService 作 为 一 个 壁纸 服务 的 基 类 ， 它 的 工作 
就 是 为 具体 的 壁纸 类 创建 “共有 的 属性 ”。 比 如 所 有 的 壁纸 应 用 都 需要 
Surface 来 输出 图 像 ， 并 针对 系统 中 产生 的 实时 事件 做 出 正确 处 理 。 
WallpaperService 一 方面 会 为 这 些 事件 的 处 理 提 供 统一 的 解决 方案 ， 另 
一 方面 需要 考虑 各 engine 子 类 的 特性 。 换 句 话说 ， 一 个 扩展 的 engine 类 
可 以 有 选择 地 实现 如 下 方法 。 


e onCreate 


E E 用 于 初始 化 engine。 访 方法 返回 后 程序 就 开始 创建 
这 个 壁纸 实例 的 Surface。 


e onDestroy 


一 个 engine 即 将 被 销毁 前 会 调用 。 该 方法 返回 后 上 述 创建 的 
Surface 就 会 被 destroyed， 因 此 engine 也 就 无 效 了 。 


e onVisibilityChanged 


通知 该 壁纸 当前 是 可 见 或 者 隐藏 状态 。WallpaperService 要 求 壁纸 
实例 只 有 在 visible 时 才能 占用 CPU 资源 ， 这 点 要 特别 注意 。 


e onTouchEvent 
用 户 触 发 了 触摸 屏 事件 。 


e onCommand 


接收 到 WallpaperManager 发 过 来 的 command。 


onSurfaceChanged 
Surface 发 生 改 变 。 


e onSurfaceRedrawNeeded 


需要 重 绘 Surface。 
e onSurfaceCreated 
Surface 创 建成 功 。 


e onSurfaceDestroyed 


Surface 被 销毁 。 
9 注意 


后 面 几 个 关于 Surface 的 方法 和 SurfaceHolder. Callback 类 是 
一 致 的 。 


了 解 了 这 些 接口 后 ， 我 们 回头 看 updateSurface 束 清楚 多 了 。 这 个 
滑 数 会 根据 当前 的 具体 情况 来 回调 壁纸 实例 提供 的 engine 相 应 接口 ， 以 
实现 壁纸 的 各 种 功能 。 也 数 首先 判断 forceRelayout || creating || 
surfaceCreating || formatChanged || sizeChanged || typeChanged 
|| flagsChanged || redrawNeeded 等 条 件 是 否 有 变动 一 一 是 的 话 内 部 
再 进行 细 化 处 理 ， 否 则 直接 返回 。 


如 果 mCreated 为 空 ， 说 明 还 没有 在 WMS 中 做 过 注册 。 此 时 需要 通过 
mSession. addToDi splay 来 执行 注册 操作 。 如 果 Surface 还 没有 创建 ， 也 
需要 先生 成 一 个 可 用 的 Surface 一 一 这 些 操作 流程 和 我 们 在 显示 系统 中 
的 分 析 完 全 一 致 ， 读 者 可 以 回头 参考 下 。 


经 过 updateSurface 取 得 有 效 的 Surface 和 U1 绘制 环境 后 ， 
ImageWal1paper 就 能 进一步 将 “壁纸 界面 ”经 由 SurfaceFlinger 显 示 到 
终端 屏幕 上 了 。 这 部 分 内 容 比较 简单 ， 读 者 可 以 作为 练习 自行 阅读 分 
析 。 


Android 钊 用 的 工具 “小 插件 ”一 一 Widget 机 制 


Widget 俗 称 “ 小 插件 ”， 是 Android 系 统 中 一 个 很 常用 的 工具 。 比 
如 我 们 可 以 在 Launcher 中 添加 一 个 音乐 播放 器 的 Wi dget， 以 快速 控制 歌 
曲 的 下 一 曲 / 上 一 曲 、 音 量 等 ; 也 可 以 使 用 “天 气 ” 或 者 “时 钟 ” 小 插 
件 来 获得 当地 的 气温 和 时 间 信 息 。Wi dget 给 Android 系 统 带 来 了 更 便捷 
的 用 户 体验 ， 因 此 受到 广泛 的 欢迎 ， 如 图 19-1 所 示 。 


A L'orée Des Bois T pb 


Plants And Animals 





全 图 19-1 一 个 音乐 播放 器 Widget 示 例 


大 家 都 知道 ， 在 Launcher 上 可 以 添加 插件 ， 那 么 是 不 是 说 只 
Launcher 才 具备 这 个 功能 呢 ? 我 们 可 以 换个 角度 来 思考 一 下 ，Launcher 
本 质 上 只 是 一 个 APK 应 用 程序 ， 所 以 它 能 做 到 的 事情 理论 上 在 其 他 任何 
应 用 程序 中 也 都 能 做 到 。 


所 以 可 以 很 肯定 地 说 : 不 是 。Android 系 统 并 没有 具体 规定 谁 才能 
充当 “Widget 容 器 ”这 个 角色 。 它 定义 了 一 套 完 整 的 Wi dget 添 加 / 移 除 
和 显示 机 制 ， 使 得 人 人 都 能 当 “Widget 提 供 者 ”， 人 人 也 都 有 资格 
做 “Widget 容 器 ”。Widget 哩 然 名 为 小 插件 ， 它 的 实现 原理 却 是 “内 有 
乾坤 ”， 比 普通 的 应 用 程序 要 稍微 难 一 些 。 本 章 将 为 读者 全 面 剖析 
Android 系 统 中 的 Widget 体 系 一 一 相信 读者 在 深入 了 解 了 其 内 部 原理 





后 ， 有 再 来 开发 Widget 应 用 就 会 容易 得 多 。 


上 面 我 们 提 到 了 “Widget 提 供 者 ”和 “Widget 容 器 ”这 样 的 概念 ， 
前 者 如 一 个 天 气 插件 ， 后 者 则 如 Launcher 。 在 Widget 机 制 中 ， 它 们 都 有 
各 自 的 专 有 名词 (同时 也 是 类 名 ) ， 分 别 是 AppWidgetProvider 和 
AppWidgetHost。 除 此 之 外 ， 我 们 能 猜想 到 系统 中 还 需要 一 个 全 局 的 
Widget 管 理 器 。 类 似 于 WindowManagerService、 
WallpaperManagerService 的 命名 方式 ， 它 叫 作 AppWidgetService。 在 
接 下 来 的 小 节 中 我 们 将 逐个 介绍 它们 ， 如 图 19-2 所 示 。 


AppWidgetService 
AppWidgetProvider AppWidgetHost 


AppWidgetProvider AppWidgetHost 
AppWidgetProvider AppWidgetHost 












全 图 19-2 ”Widget 架构 中 的 重要 组 成 元 素 





19.1 “功能 的 提供 者 ”一 一 AppWi dgetProvider 


对 于 大 部 分 开发 人 员 来 说 ，AppWi dgetProvider 是 他 们 最 熟悉 的 。 
既然 叫 作 Provider， 言 下 之 意 就 是 “功能 的 提供 者 ”。 从 Host 的 角度 来 
说 ， 它 没有 办 法 预先 知晓 用 户 会 添加 多 少 个 Wi dget， 也 没有 办 法 知晓 这 
些 添加 的 Widget 都 实现 了 哪些 功能 。 所 以 在 Host 的 “ 世 弄 ”里 ， 一 个 
Widget 只 是 一 一 个 View 一 一 它 已 只 需要 按照 要 求 进行 正确 显示 即 可 ， 具体 的 
功能 实现 则 由 AppWidgetProvider 来 完成 。 


希望 读者 可 以 谨 记 并 在 后 续 分 析 中 验证 这 个 结论 : 
Host 把 Widget 看 成 View 的 一 个 “变种 ”。 
一 个 有 效 的 Provider 要 提供 至 少 以 下 几 方 面 的 内 容 。 
e AppWidgetProviderInfo 


也 就 是 用 于 描述 这 个 Widget 的 各 种 信息 ， 包括 ERS layout 7h i, 刷 
新 频率 以 及 下 面 要 提 到 的 AppWidgetProvider 等 。 这 些 信 息 以 XML 格式 的 
文件 表示 ，Tag 标 志 为 Cappwidget-provider>。 


e AppWidgetProvider 


既然 Widget 最 终 是 要 被 显示 在 Host 中 的 ， 那 么 它 的 功能 实现 和 普通 
应 用 程序 就 一 定 会 有 差异 。AppWidgetProvider 主 要 借助 于 Broadcast 事 
件 来 对 Widget 进 行 “远程 更 新 ”， 后 面 我 们 会 详细 分 析 。 


e View 布 局 


AppllidgetProviderinfo 用 于 描述 这 个 Widget 的 整体 信息 ， 而 这 里 
的 Layout 则 是 专门 用 于 描述 Widget 的 “显示 部 分 ”确切 地 说 ， 是 初始 
化 时 的 显示 ) 。 


基于 上 面 的 分 析 ， 不 难 推测 出 Provider 就 是 一 
BroadcastReceiver。 比 如 我 们 可 以 在 AndroidManifest. xm| 中 声明 以 下 
内 容 来 定义 一 个 AppWidgetProvider : 


<receiver android:name="ExampleAppWidgetProvider" > 


<intent-filter> 
<action android:name="android.appwidget .action.APPWIDGET_UPDATE 
</intent-filter> 
<meta-data android:name="android.appwidget.provider" 
android: resource="@xml/example_appwidget_info" /> 
</receiver> 


这 个 receiver 要 接收 的 了 唯一 消息 ， 就 是 APPWIDGET_UPDATE; 并 且 它 
还 需要 带 有 <meta-data>》 信 息 明 确 指明 自己 是 一 
个 "android. appwidget. provider"， 最 后 的 android:resource 即 前 面 说 
到 的 AppWidgetProviderlnfo。 比 如 ; 


<appwidget-provider xmlns:android="http://schemas.android.com/apk 
android: minwWidth="294dp" 
android:minHeight="72dp" 
android: updatePeriodMillis="86400000" 
android: previewImage="@drawable/preview" 
android: initialLayout="@layout/example_appwidget" 
</appwidget -provider> 


这 个 XML 文件 的 最 后 一 项 属性 (android:initialLayout) 指定 了 初 
始 的 View 布 局 为 example_appwidget， 它 和 我 们 编写 普通 应 用 程序 的 布 
局 语法 一 样 。 不 过 要 特别 注意 的 是 : 


Widget 中 的 Layout 布 局 是 基于 RemoteViews 的 ， 因 而 并 不 是 所 有 的 
View 组 件 都 可 以 使 用 ， 具 体 细节 可 以 参考 官方 文档 的 说 明 。 


当 我 们 编写 一 个 自己 的 Widget Provider 时 ， 首 先 要 继承 自 
AppWidgetProvider。 后 者 的 内 部 实现 并 不 复杂 ， 它 继承 自 
BroadcastReceiver， 并 在 onReceive 中 将 具体 事件 通过 重 载 印 数 通知 我 
们 的 AppWidgetProvider 实 例 : 


/*frameworks/base/core/java/android/appwidget/AppWidgetProvider . j 
public class AppWidgetProvider extends BroadcastReceiver { 


public void onReceive(Context context, Intent intent) { 
String action = intent.getAction(); 
if (AppWidgetManager .ACTION_APPWIDGET_UPDATE.equals(actio 
Bundle extras = intent.getExtras(); 
if (extras != null) { 
int[] appWidgetIds = extras.getIntArray(AppWidgetMa 
if (appWidgetIds != null && appWidgetIds.length > © 
this.onUpdate(context, AppWidgetManager.getInst 


fa 

可 以 看 到 当 action 为 ACTION_APPWIDGET_UPDATE， 具 体 的 处 理 者 是 
onUpdate。 而 其 他 情况 下 分 别 是 : 

ACTION _APPWIDGET DELETED onDeleted 

ACTION APPWIDGET OPTIONS CHANGED onAppW i dgetOpt i onsChangec 

ACTION _APPWIDGET ENABLED onEnab | ed 

ACTION _APPWIDGET DISABLED onDisabled 


也 就 是 说 ， 编 写 一 个 Wi dget 应 该 根据 需求 来 重 载 onReceiver 〈 如 果 
需要 的 话 ) , onUpdate, onAppWidgetOptionsChanged, onDeleted, 
onEnabled 以 及 onDisabled。 它 们 分 别 会 在 此 Widget 被 更 新 、0ption 改 
变 、 被 删除 等 情况 下 被 调用 。 


e onUpdate 


apn 4 AppWidgetProvider Info FupdatePeriodMillis, A 
统 就 会 根据 这 个 时 间 间 隔 来 周期 性 地 产生 ACTION_APPWIDGET_UPDATE。 
另外 ， 当 用 户 添加 了 Widget 时 也 会 产生 这 一 事件 。 


e onAppWidgetOptionsChanged 


这 个 万 法 主要 用 于 处 理 Widget 的 尺寸 变化 ， 因 而 可 以 猜 到 在 第 一 次 
添加 时 也 会 被 调用 。 以 后 当 用 户 改变 Widget 的 大 小 后 才 会 产生 这 一 事 


o 


。 其 他 


其 他 几 个 方法 比较 好 理解 ， 我 们 就 不 一 一 介绍 了 。 不 过 要 特别 注意 
的 是 ， 一 个 Widget 是 可 以 有 多 个 具体 实例 的 。 比 如 我 们 写 了 一 个 “天 
气 ” 插 件 供用 户 使 用 ， 那 么 理论 上 并 不 限制 用 户 会 在 Launcher 中 添加 多 


少 个 “天 气 ” 实 例 。 因 而 需要 有 相应 的 Wi dget1d 来 唯一 标识 每 一 个 实 


例 ， 如 图 19-3 所 示 。 
AppWidgetProvider 


instance! instance2 instance? 四 


app Widgelld=,. appWidgetld= app Widgetld=. 


全 图 19-3 AppWidgetProvider 可 以 有 多 个 实例 


19.2 AppWidgetHost 


上 一 小 节 我 们 了 解 了 AppWidgetProvider 所 要 做 的 工作 ， 接 下 来 再 
看 看 Host 又 是 如 何 配合 Provider 的 。 简 而 言 之 ，Host 这 个 “东道 主 ” 需 
要 提供 相应 的 空间 供 Widget 来 展现 自己 的 UI 界面 。 打 个 比方 ， 
AppWidgetHost 就 好 比 一 个 展厅 ， 而 至 于 陈列 的 汽车 是 大 众 还 是 奔驰 品 
牌 都 是 没 问题 的 一 一 取决 于 Widget 本 身 的 意愿 。 


成 为 一 个 AppWidgetHost， 它 需要 解决 以 下 问题 。 
o 如 何 显示 Widget 的 UI 界面 


也 就 是 说 ， 展 厅 本 身 需 要 为 每 一 个 参展 的 Widget 做 好 规划 ， 如 展 出 
的 了 时间、 具体 的 展 出 位 置 、 占 地 大 小 、 以 什么 样 的 方式 展 出 等 。 


。 如 何 与 AppWidgetProvider 通 信 


某 个 客户 看 中 了 展厅 上 摆 放 的 某 辆 参展 车 ， 那 么 作为 Host 就 要 及 时 
通知 参展 商 这 一 事件 。 受 Widget 特 性 的 限制 ， 我 们 在 普通 应 用 程序 中 能 
实现 的 事件 在 Widget 机 制 中 未 必 可 以 正常 工作 。 比 如 APK 应 用 程序 中 的 
View 组 件 响 应 左右 滑动 这 一 Gesture 是 很 简单 的 事 一 一 但 是 “寡居 ”于 
Launcher 中 的 Widget 就 需要 特别 注意 ， 因 为 左右 滑动 这 个 手势 在 
Launcher 中 代表 了 翻 页 。 换 句 话说 ，Widget 将 得 不 到 左右 滑动 的 事件 。 
即便 开发 人 员 可 以 通过 修改 Launcher 源 码 来 达到 相同 的 效果 ， 这 种 方法 
对 于 后 期 添加 的 Widget 显 然 也 是 无 能 为 力 的 。 


前 一 小 节 我 们 分 析 过 ， 一 个 AppWidgetProvider 与 外 办 的 接口 就 是 
onReceive， 然 后 再 细 化 为 onUpdate，onEnable 等 事件 处 理 。 而 产生 这 
些 事件 的 根源 ， 除 了 AppWi dgetService 这 一 系统 元 素 外 ， 就 是 
AppWidgetHost 了 。 只 不 过 后 者 也 是 要 通过 前 者 来 发 送 事 件 的 ， 如 图 19- 
4 所 示 。 







AppWidgetService 







startListening | Callback 
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Host Application 


全 图 19-4 AppWidgetHost 与 Widget 系 统 间 的 接口 


简 图 中 的 Host_App1ication 是 指 扮 演 Host 角 色 的 应 用 程序 ， 如 
Launcher 。 它 在 整个 Widget 机 制 中 只 会 与 AppWidgetManager 进 行 交 互 而 
不 会 直接 调用 AppWidgetService 的 接口 (这 有 点 类 似 于 
ServiceManager. java 的 作用 ) 。 可 想 而 知 ，AppWi dgetManager 内 部 还 
是 要 通过 间接 调用 AppWidgetService 来 实现 的 。 另 外 每 个 
Host_Application 还 要 持 有 一 个 AppWidgetHost， 我 们 可 以 认为 它 是 
Host 的 代理 。 


当 一 个 Host_Application 创 建 后 ， 它 需要 器 AppWidgetService 注 册 
监听 Widget 事 件 ， 并 提供 一 个 cal lback 实 现 。 这 个 cal 1back 实 际 上 继承 


自 1AppWidgetHost. Stub， 即 一 个 基于 AI1DL 的 BinderServer， 这 就 保证 
了 AppWidgetService 在 事件 发 生 时 可 以 回调 到 Host。 需 要 接收 的 回调 事 
件 包 括 : 


e updateAppWidget updateAppWidgetView @AppWidegetHost 
e providerChangedonProviderChanged @AppWidgetHost 
e viewDataChangedviewDataChanged @AppWidgetHost 


我 们 以 updateAppWidget 为 例 来 分 析 其 内 部 实现 : 


/*frameworks/base/core/java/android/appwidget/AppWidgetHost. 
void updateAppWidgetView(int appwidgetId, RemoteViews views, 
AppWidgetHostView v; 
synchronized (mViews) { 
v = mViews.get(appWidgetId); 


J 
if (v != null) { 
v.updateAppWidget(views); 


} 
} 
当 Wi pene ider 和 希望 更 新 Host 中 的 View 显 示 时 〈 比 如 天 气 插件 更 
新 气温 ) ， 它 会 通过 AppWidgetManager. updateAppWidget (int 


aN deeld. RemoteViews views) 来 指定 新 的 View 样 式 
(RemoteViews) 。 这 个 请 求 最 终 由 AppWi dgetService 发 送 给 相应 的 
Host 来 实现 ， 即 updateApp WidgetView。 上 面 代码 中 的 mViews 定 义 如 

下 : 


HashMap<Integer,AppWidgetHostView> mViews = new HashMap<Integer, 
AppWidgetH 


它 是 一 个 AppWidgetHostView 的 集合 。 换 句 话 说 ， 是 当前 这 个 Host 
所 包含 的 所 有 Widget 的 View 对 象 。 比 如 在 Launcher 中 用 户 每 添加 一 个 
Widget 〈 或 者 设备 刚 开 机 时 Launcher 自己 从 保存 的 配置 中 读 取 需要 加 载 
显示 的 Widgets) ， 就 会 用 AppWidgetHost. createView 把 它 加 入 这 个 集 
合 中 。 另 外 因为 Wi dget 数 量 众 多 ， 必 须 为 它们 分 配 一 个 全 局 唯一 的 
Widgetld. 


1. Launchet 中 添加 widget 的 操作 过 程 


在 Launcher 中 添加 一 个 Widget， 操 作 流 程 是 : 


首先 ， 在 主客 面 屏幕 的 空白 处 长 按 会 弹出 对 话 框 ， 供 用 
添加 到 屏幕 上 的 item 类 型 ， 如 图 19- 5 所 示 。 


当选 择 了 “Widgets” 后 ， 程 序 通过 责 有 lntent. action 为 
AppWidgetManager. ACT | i APPWI DGET_PICK 的 


StartActivityForResult 来 启动 系统 的 如 图 19-6 所 示 界 面 。 


Add to Home screen 


P Shortcuts 


i} Widgets 


hm Folders 





全 图 19-5 空白 处 长 按 会 弹出 对 话 框 


户 选择 需 


要 





全 图 19-06 界面 


用 户 对 widget 的 选择 结果 将 通过 Activity. onActivityResult 返 回 
给 Host Application。 后 者 在 做 了 相应 处 理 后 ， 还 要 发 起 第 二 次 
StartActivityForResult， 这 次 的 lntent. action 为 AppWidgetManager. 
ACTION_APPWIDGET_CONF1GURE 一 一 意 在 对 该 Wi dget 进 行 初始 化 
(configuration) 。 比 如 天 和 气 插件 需要 指定 用 户 所 在 城市 、 设 置 更 新 
频率 等 。 如 果 该 插件 对 应 的 AppWidgetProvider 提 供 了 
ConfigurationActivity， 此 时 就 会 被 调用 。 


当 配 置 结束 后 ， 通 常 Host_Appl1ication 还 会 询问 用 户 希 望 给 Widget 
分 配 多 大 的 显示 空间 ， 如 2 行 2 列 或 者 2 行 3 列 等 。 做 好 这 些 准 备 后 ， 
Host_Application 才 能 真正 把 这 个 Widget 添 加 到 自己 的 显示 表面 中 。 


2. widget 在 host 中 的 显示 流程 
首先 Host 通 过 AppWidgetManager. getAppWidgetlnfo 来 得 到 相应 


Widget1d 的 Info 信 息 ， 即 我 们 前 一 小 节 中 讲 到 的 
AppWidgetProvider 1nfo。 接 着 Host 会 通过 AppWi dgetHost. createView 





产生 一 个 AppWi dgetHostView 一 一 这 个 View 对 应 的 布局 是 由 前 面 的 
initialLayout 指 定 的 。 后 续 AppWidget Provider 根 据 实 际 情况 还 会 通 
过 RemoteViews 来 实时 更 新 它 的 Widget 显 示 。 


那么 ，createView 都 做 了 哪些 工作 呢 ? 


/*frameworks/base/core/java/android/appwidget/AppwWidgetHost. 
public final AppWidgetHostView createView(Context context, in 
AppWidgetProvideriInfo appWidge 
final int userId = mContext.getUserId(); 
AppWidgetHostView view = onCreateView(mContext, appWidget 
// 本 地 的 View 对 象 
view.setUserId(userId); 
view.setOnClickHandler (mOnClickHandler ) ; 
view.setAppWidget(appWidgetId, appWidget); 
synchronized (mViews) { 
mViews.put(appWidgetId, view); 
} 


RemoteViews views; 
try { 
views = sService.getAppWidgetViews(appWidgetId, userI 
if (views != null) { 
views.setUser(new UserHandle(mContext.getUserId( ) 


} catch (RemoteException e) { 
throw new RuntimeException("system server dead?", e); 
} 


view. updateAppWidget (views);// 通 过 RemoteViews“ 搭 建 ” 本 地 的 Vit 
return view; 





} 


第 一 步 是 要 产生 一 个 AppWidgetHostView， 默 认 情 况 下 
onCreateView 内 部 只 是 new 了 一 个 AppWidgetHostView 对 象 然后 就 直接 返 
回 。 如 果 读 者 有 特殊 需求 ， 可 以 重 载 这 个 函数 : 


/*frameworks/base/core/java/android/appwidget/AppWidgetHostView. j 
public class AppWidgetHostView extends FrameLayout { 


可 见 ，AppWidgetHostView 实 际 上 是 FrameLayout 的 扩展 子 类 。 而 
setAppWidget 一 方面 将 widget1d 与 此 AppWidgetHostView 联 系 起 来 ， 另 
一 方面 设置 了 将 要 显示 的 widget 的 padding 值 ， 我 们 同样 可 以 重 载 这 一 
实现 。 


接 下 来 就 是 widget 显示 的 重点 ， 即 我 们 如 何 把 Widget Provider 
义 的 界面 显示 到 Host Application#. 


在 分 析 源 码 前 ， 我 们 先 来 打 个 比方 。 张 三 在 北京 建 了 一 栋 别 墅 ， 李 
四 看 了 后 很 喜欢 ， 于 是 也 想 自 己 在 上 海 建 一 栋 一 模 一 样 的 。 怎 么 办 ? 显 
然 不 可 能 将 张 三 的 别墅 直接 挪 到 上 海 ， 因 为 它们 是 异地 的 ， 属 于 两 个 不 
同 的 “进程 空间 ”。 一 个 可 行 的 办 法 就 是 将 张 三 的 建筑 图 纸 完 完 本 本 地 
递交 给 李 四 ， 然 后 李 四 就 可 以 在 他 自己 的 “进程 空间 ”中 兴建 一 栋 一 模 
一 样 的 别墅 了 。 虽 然 砖 瓦 、 水 泥 可 能 用 的 不 是 一 个 品牌 但 这 丝毫 不 会 
影响 大 家 认为 “这 两 栋 别墅 的 样式 风格 是 完全 一 样 的 ”。 


Widget 的 显示 也 类 似 。 我 们 需要 在 另 一 个 进程 空间 (B 
Host_Application) 中 显示 自己 的 View， 那 么 也 完全 可 以 把 View 的 “图 
纸 ” 交 给 对 方 一 一 这 样 对 方 只 要 “ 依 葫芦 画 标 ”， 也 就 不 难 “ 还 原 ” 出 
Widget 的 “真实 面目 ”了 。 而 这 张 “图 纸 ”， 就 是 RemoteViews: 


/*RemoteViews. java*/ 
public class RemoteViews implements Parcelable, Filter {... 





虽然 它 的 名 称 中 也 市 有 “Views”， 但 实际 上 没有 任何 View 的 影 
ts oe 自 可 以 跨 进 程 传 递 的 Parcelable 类 以 及 对 数据 进行 约束 的 
Filter. 


有 了 这 些 基 础 ， 我 们 再 回头 接着 看 前 面 的 createView: 


views = sService.getAppwidgetViews(appWidgetId); 


上 面 这 句 代 码 根据 Widget1d 来 得 到 一 个 RemoteViews， 它 借助 于 
sService 即 AppWidgetService 提 供 的 接口 来 实现 。 实 际 上 它 只 是 简单 填 
写 了 Widget 的 Layout1d 和 PackageName 等 ， 后 面 真正 构造 Widget 的 U1 界 
面 时 才 会 去 取 “ 图 纸 ”。 


最 后 调用 的 updateAppWidget 是 真正 构建 widget 表面 的 地 方 (DES 
阅读 ) : 


public void updateAppWidget(RemoteViews remoteViews) {... 
boolean recycled = false; 
View content = null; 
Exception exception = null; 


if (remoteViews == null) 4.. 
} else { 
mRemoteContext = getRemoteContext(remoteViews ) ; 
int layoutId = remoteViews.getLayoutId();/*Step1. 描述 


if (content == null) { 


try { 
content = remoteViews.apply(mContext, this, mO 
创建 Widget 的 View*/ 





} catch (RuntimeException e) { 
exception = e; 


} 
mLayoutId = layoutId; 
mViewMode = VIEW_MODE_CONTENT; 


} 


if (!recycled) { 
prepareView(content); 
addView(content ) ;/* 添 加 Widget 的 View 到 全 局 管理 中 */ 


























} 
} 
Step1@ updateAppWidget。 得 到 Widget 所 属 的 Context 以 及 


layout1d。 做 过 主题 换 肤 功能 的 开发 者 应 该 会 觉得 和 这 里 所 采用 的 思想 
基本 一 致 。 


Step2@ updateAppWidget。 正 常情 况 下 程序 需要 调用 
RemoteViews. apply， 其 返回 值 content 是 一 个 View 对 象 。 一 个 合理 的 猜 
测 即 它 应 该 就 是 根据 Widget 的 “图 纸 ” 所 创建 出 来 的 View， 后 面 再 详细 


分 析 这 个 函数 。 

Step3@ updateAppWidget。 前 面 我 们 说 过 AppWidgetHostView 是 一 
个 FrameLayout， 因 而 作为 ViewGroup 它 可 以 通过 addVview 来 添加 子 
View (〈 即 content 变 量 ) 。 

小 结 一 下 这 个 函数 ， 简 单 来 讲 它 做 了 两 件 事 。 


e 生成 一 个 View (content® =) 


这 个 View 根 据 推测 就 是 由 Wi dget 的 “图 纸 ” 生 成 的 ， 因 而 代表 了 
Widget 的 U1 界面 。 


e 14 Lik Views F| AppWidgetHostView + 


AppWidgetHostView 是 一 个 FrameLayout， 它 将 content 作 为 子 View 
添加 进来 。 这 样 当 整个 View 重 绘 时 ，Widget 的 表面 自然 也 就 呈现 出 来 
“ees 


RAs FAKE Papp! ye aye: 


/*frameworks/base/core/java/android/widget/RemoteViews. java* 
public View apply(Context context, ViewGroup parent, OnClickH 
RemoteViews rvToApply = getRemoteViewsToApply(context); 
View result; 
Context c = prepareContext(context); 
LayoutInflater inflater = (LayoutInflater)c. 
getSystemService(Context.LAYOU 


result=inflater.inflate(rvToApply.getLayoutId(), parent, 


return result; 


J 


读者 可 以 先 思 考 下 : 如 果 已 知 一 个 xm| 描 述 的 1ayout 布 局 ， 要 怎么 
才能 把 它 变 成 代码 中 的 ViewTree 呢 ? 答案 就 是 通过 层 层 解析 这 个 xm|l 文 
件 ， 然 后 按照 递归 顺序 来 逐步 生成 文件 中 描述 的 每 个 View 对 象 ， 并 把 它 
们 有 机 地 组 织 起 来 〈 树 的 形式 ) 。 


明白 这 些 道 理 后 ，apply 函 数 就 容易 理解 了 。 它 就 是 通过 inflater 
来 完成 工作 的 。 具 体 的 实现 过 程 我 们 就 不 深究 了 ， 有 兴趣 的 读者 可 以 自 
行 分 析 。 

这 样 程序 就 按照 Wi dget 提 供 的 “图 纸 ” 成 功 地 在 host 进 程 中 构造 出 
本 地 的 View 对 象 了 它 会 和 Host_Application 中 其 他 View 一 起 ， 经 过 
SurfaceFlinger 的 处 理 后 最 终 显示 到 屏幕 上 。 


Widget 机 制 的 设计 很 有 技巧 ， 希 望 读 者 可 以 再 深入 “品味 ”。 





EMEA 
Android 应 用 程序 的 编译 和 打包 


Android 系 统 的 APK 应 用 程序 可 以 有 如 下 几 种 编译 方式 。 
。 借助 系统 编译 


本 书 曾 对 Android 系 统 的 编译 框架 进行 过 完整 分 析 。 它 利用 
Android. mk 文件 将 众多 小 项 目 组 织 起 来 ， 并 且 提 供 了 非常 方便 的 函数 以 
编译 出 各 种 可 执行 文件 、 库 和 应 用 程序 等 。 理 论 上 应 用 开发 人 员 可 以 将 
APK 源 码 添加 到 整个 Android 工 程 中 ， ay 于 系统 编译 来 间接 完成 应 
用 程序 的 编译 一 一 只 不 过 这 种 方式 并 不 多 见 。 一 方面 ， 这 要 求 开 发 工程 
师 对 整个 系统 的 编译 框架 有 一 定 的 认识 ; = 方面 ， 这 意味 着 开发 应 用 
程序 还 需要 下 载 整个 Android 工 程 ， 而 且 每 次 编译 的 时 间 也 会 很 长 。 


e 借助 于 IDE 工 具 


所 以 一 般 情 况 下 ，APK 应 用 程序 〈 非 系统 级 应 用 ) 的 开发 都 会 借助 
于 1DE 工 具 一 一 比如 适 配 于 Eclipse 的 ADT 就 是 使 用 最 广泛 的 一 种 。 
Android 提 供 的 ADT 组 件 不 仅 可 以 用 于 快速 建立 应 用 程序 的 原型 ， 其 集成 
的 各 种 辅助 功能 也 可 帮助 开发 人 员 便 捷 地 编写 、 编 译 和 调试 应 用 程序 。 


。 命令 行 编译 
工程 师 在 ADT 的 帮助 下 ， 可 以 “不 费 吹 灰 之 力 ” 地 完成 编译 。 但 是 


这 种 “傻瓜 式 ”的 操作 方式 造成 的 一 个 副作用 ， 就 是 很 多 人 对 应 用 程序 
的 编译 、 打 包 、 签 名 等 基础 过 程 都 “一 知 半 解 ”。 


本 章 我 们 将 向 读者 系统 地 讲解 隐藏 在 “ADT” 背 后 的 这 些 细节 





20.1 “ 另 尽 蹊 径 ”采用 第 三 方 工具 
软件 编译 需要 用 到 哪些 工具 呢 ? 


编译 器 是 毋庸 置疑 的 ， 如 GCC 一 一 而 且 理 论 上 这 就 足够 了 。 但 随 着 
软件 工程 的 发 展 ， 很 多 项 目的 源码 数量 不 断 膨胀 ， 因 而 单纯 地 使 用 GCC 
已 经 无 法 满足 要 求 了 。 举 一 个 例子 ，Android 工 程 有 成 干 上 万 个 文件 ， 
开发 人 员 不 可 能 手工 逐个 执行 GCC 命令。 所 以 必须 有 其 他 工具 来 管理 这 
些 零碎 的 文件 ， 并 有 目的 地 把 它们 组 织 成 最 终 的 系统 image 一 一 这 就 是 
make 的 意义 所 在 。 


那么 我 们 编译 一 个 APK， 是 不 是 也 要 用 到 make? 


理论 上 当然 可 以 这 样 做 ， 但 Google 没 有 选择 这 种 方式 ， 而 是 “ 另 辟 
蹊 径 ”采用 了 第 三 方 工具 一 一 Ant。 


Ant 





Ant 是 “Another Neat Tool” 的 缩写 ， 由 Apache 开 发 。 
从 “Another” 可 以 看 出 一 点 端倪 ，Ant 很 可 能 是 以 某 个 经 典 工 具 为 原型 
改进 而 来 的 ， 并 且 相 对 于 原 有 工具 更 加 “Neat” 一 一 事实 也 的 确 如 此 。 
Ant 的 开发 者 原先 供职 于 Sun 公 司 ， 他 在 开发 著名 的 JSP/Servlet (BA 
来 的 Tomcat) 时 ， 发 现 传统 的 make 方 法 太 依 赖 于 操作 系统 环境 ， 由 此 对 
研发 人 员 的 工作 造成 了 不 少 的 影响 。 


因此 Ant 被 设计 采用 Java 语 言 来 开发 ， 并 且 以 XML 文件 〈 默 认为 
build. xml) 来 描述 编译 过 程 和 依赖 关系 。 这 相对 于 Makef i le 来 说 更 为 
简洁 易 懂 ， 也 更 富有 扩展 性 ， 所 以 在 Java 工 程 中 逐渐 得 到 了 广泛 的 应 
用 。 


下 面 我 们 介绍 Ant 的 几 个 常见 命令 。 其 他 命令 的 用 法 也 类 似 ， 有 兴 
趣 的 读者 请 自行 参阅 它 的 官方 网 站 : http://ant. apache. org. 


ant release 


编译 一 个 release 版 本 的 项 目 。 


ant debug 


编译 一 个 debug 版 本 的 项 目 。 


ant installd 

安装 一 个 已 经 comp iled 过 的 debug 包 。 
ant installr 

安装 一 个 已 经 comp iled 过 的 release 包 。 


ant installt 


安装 一 个 已 经 compiled 过 的 测试 包 ， 同 时 安装 被 测试 应 用 的 . apk 37 
件 。 


ant <build target> install 

编译 并 安装 一 个 程序 包 。 
ant clean 

清理 一 个 项 目 ， 或 者 如 果 使 用 了 ant all clean， 则 所 有 相关 项 目 
都 会 被 清理 。 


特别 提醒 ， 如 果 你 是 在 Wi ndows 操 作 系 统 环境 下 开发 Apk 应 用 程序 ， 
那么 要 注意 JDK 的 安装 路 径 。 因 为 默认 情况 下 ，JDK 安 装 在 “Program 
ae 目录 中 ， 而 这 中 间 的 空格 将 导致 Ant 无 法 正常 运行 。 解 决 的 办 法 
AT: 


e set JAVA_HOME= "c:\Progra~1\Java\<jdkdir> "; 
© 或 者 将 JDK 安 装 到 名 称 不 带 空格 的 路 径 中 。 
20.2 通过 命令 行 编译 和 打包 APK 
简单 来 说 ，Ant 可 以 提供 两 种 编译 方式 ， 即 debug 和 release; MA 
不 论 何 种 方式 生成 的 应 用 程序 ， 都 需要 经 过 签名 和 zipalign 的 优化 一 一 
只 不 过 debug 版 本 默认 就 会 帮助 开发 者 自动 完成 这 些 工作 。 关 于 签名 过 
程 的 详细 描述 ， 请 参阅 下 一 小 节 。 
Debug 模 式 


编译 debug 版 本 的 项 目 ， 步 骤 如 下 。 


。 命令 行 模式 下 ， 进 入 你 的 工程 目录 。 
o 使 用 ant debug 命 令 进行 编译 。 


这 样 就 会 在 项 目的 bin 目 录 下 生成 一 个 后 缀 为 “-debug. apk” 的 文 
件 ， 而 且 它 已 经 用 debug key 签 过 名 ， 也 经 过 了 zipalign 的 优化 。 


Release 模 式 


虽然 上 面 的 debug 模 式 非常 方便 ， 但 并 不 适用 于 正式 发 布 的 应 用 程 
序 。 其 中 一 个 重要 原因 就 是 它 采 用 的 是 系统 默认 的 签名 文件 ， 没 有 起 到 
很 好 的 安全 保护 作用 。 


在 release 模 式 下 ， 签 名 和 zipalign 优 化 都 需要 开发 者 手工 完成 。 


。 命令 行 模 式 下 ， 进 入 你 的 工程 目录 ; 

。 使 用 ant release 命 令 进 行 编译 ; 

e 在 bin 目 录 下 会 生成 以 “-unsigned.apk” 为 后 缀 的 APK 文 件 ; 
e 利用 Jarsignet 或 者 其 他 类 似 工 具 为 apk 签 名 (HAAR) ; 
。 利用 zipalign 优 化 应 用 程序 。 


可 能 有 读者 认为 这 个 过 程 比较 烦琐 ， 这 里 有 一 个 简化 的 方法 可 以 在 
release 模 式 下 自动 为 APK 签 名 和 优化 。 


。 找 到 项 目 根 目录 下 的 ant.properties 文 件 。 
。 加 入 如 下 两 条 信息 : 


key.store=path/to/my.keystore 
key.alias=mykeystore 


这 样 ant release 命 令 在 生成 APK 的 过 程 中 会 主动 要 求 用 户 输入 密 
码 ， 而 编译 完成 后 的 应 用 程序 就 已 经 用 你 提供 的 my. keystore 签 过 名 


Ta 


编译 生成 的 APK 还 需要 安装 到 模拟 器 或 设备 上 以 供用 户 使 用 。 在 
Eclipse 上 ， 我 们 只 要 上 点击“Run->Run/Debug” 就 可 以 将 程序 安装 到 目 
标 上 “目标 可 以 是 模拟 器 或 设备 。 具 体 选 择 哪个 一 方面 取决 于 当前 设备 
的 连接 情况 ， 另 一 方面 与 Run/Debug Configurations 里 Target 页 中 的 设 


SAX) 。 实 际 上 这 一 过 程 借 助 了 adb 的 instal1 功 能 ， 因 而 命令 行 模式 
下 ， 我 们 也 同样 可 以 使 用 adb instal | 来 达到 相同 的 目的 。 关 于 adb 
instal1 的 更 多 描述 ， 可 以 参见 本 书 工具 篇 对 adb 的 专门 讲解 ， 这 里 不 再 


PR. 


20.3 APK 编 译 过 程 详解 


前 面 我 们 对 Ant 的 两 种 编译 模式 进行 了 概述 ， 并 从 使 用 者 的 角度 向 
读者 介绍 了 命令 行 模式 下 的 编译 方法 。 接 下 来 我 们 将 进一步 解析 编译 过 
程 的 每 一 个 环节 ， 即 Android 是 如 何 将 项 目 源 码 编 译 、 打 包 成 最 终 
的 . apk 文 件 的 。 


以 APK 为 后 缀 的 文件 是 Android 应 用 程序 的 标准 格式 。 它 其 实 是 一 个 
zip 压 缩 包 ， 所 以 可 用 WinRar 等 工具 将 其 解压 出 来 。 可 以 看 到 ， 一 个 典 
型 的 APK 应 用 程序 包含 了 以 下 几 部 分 内 容 : 


|-- AndroidManifest. xml 
|-- classes.dex 
|-- resources.arsc 
|-- res 

| |-- drawable 
| | `-- icon.png 
| |-- layout 
| | `-- main. xml 
| |-- xml 

|-- META-INF 

| |-- CERT.RSA 

| |-- CERT.SF] 

| |-- MANIFEST .MF 


e AndroidManifest.xml 


这 个 文件 相信 读者 都 不 会 陌生 。 如 果 应 用 程序 是 一 本 书 ， 那 么 这 个 
文件 就 是 它 的 “封面 ”和 “目录 ”， 记 载 了 应 用 程序 的 名 称 、 权 限 声 
明 、 所 包含 的 组 件 等 一 系列 信息 。 不 过 直接 从 APK 解 压 出 来 的 
AndroidManfiest 是 无 法 打开 的 ， 因 为 发 布 时 它 已 经 被 做 了 加 密 保护 处 
理 。 


e classes.dex 


APK 应 用 程序 的 核心 。 它 是 由 项 目 源 码 生 成 的 . class 文 件 ， 经 进 一 
步 转化 而 成 Android 系 统 可 识别 的 Dalvik Byte Code。 如 果 APK 引 用 了 第 
三 方 jar 包 的 话 ， 那 么 通常 情况 下 它 也 会 被 包含 在 classes. dex 中 (AA 
Android 系 统 中 的 字 节 人 码 和 标准 JVM 中 的 字 节 码 是 有 区 别 的 ， 人 参考 本 书 的 


Android 虚 拟 机 章节 ) 
e resources.atsc 
编译 过 后 的 资源 文件 。 
e res BK 
未 编译 的 资源 文件 。 
。META-INE 目 录 
用 于 保存 应 用 程序 的 签名 和 校 验 Ale, 以 保证 程序 的 完整 性 。 生 成 
APK 包 时 ， 系 统 会 对 包 中 的 所 有 内 容 做 一 次 校 验 ， 然 后 将 结果 保存 在 这 
里 。 而 设备 在 安装 这 一 应 用 程序 时 还 会 对 内 容 再 做 一 次 校 验 ， 并 和 
META-1INF 中 的 值 进行 比较 ， 以 避免 程序 包 被 恶意 we 
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Java 


Akar 


Ca ) 第 三 方 库 和 
其 他 文件 








apkbuilder 


签名 后 的 apk 


签名 并 优化 过 的 最 终 APK 


全 图 20-1 APK 编 译 全 过 程 图 解 


可 以 清楚 地 看 到 ， 整 个 编译 过 程 涉及 了 多 种 工具 。 下 面 对 其 中 的 几 
个 重要 步 又 进行 讲解 。 


e 首先 aidl (Android Interface Description Language) 文件 需要 通过 aid] 
工具 转换 成 编译 器 能 处 理 的 Java 接 口 文件 。 

同时 资源 文件 将 被 aapt (Asset Packaging Tool) 处 理 为 最 终 的 
resources.arsc， 并 生成 R.java 文 件 以 保证 源码 编写 时 可 以 方便 地 访问 
Java 的 编译 器 将 R.java，Java 源 码 文件 以 及 上 述 生 成 的 接口 文件 统一 
编译 成 .class 文 件 。 

因为 .class 并 不 是 Android 系 统 所 能 识别 的 格式 ， 所 以 还 要 利用 dex 工 
具 将 它们 转化 为 Dalv 站 字 节 码 。 这 个 过 程 中 还 会 加 入 程序 依赖 的 所 
CBE IE a 

接 下 来 系统 将 上 面 生成 的 dex、 资 源 包 以 及 其 他 资源 通过 apkbuilder 
生成 初始 的 APK 文 件 包 。 注 意 : 此 时 这 个 APK 还 没有 经 过 签名 和 优 
the 

签名 可 以 采用 的 工具 很 多 ， 如 Jarsigner 或 者 其 他 类 似 的 工具 。 如 果 
是 在 Debug 模 式 下 ， 签 名 所 用 的 keystote 是 系统 自 带 的 默认 值 ; 否则 
开发 者 需要 提供 自己 的 私 钥 以 完成 签名 过 程 。 

最 后 将 上 述 签 名 后 的 APK 通 过 zipalign 进 行 优化 。 优 化 的 目的 是 提高 
程序 的 加 载 和 运行 速度 一 一 基本 原理 是 对 APK 包 中 的 数据 进行 边界 
对 齐 ， 从 而 加 快 读 取 和 处理 过 程 。 这 也 同时 解释 了 其 名 

称 zip + “align” 的 由 来 。 


至 此 ， 我 们 已 经 熟悉 整个 APK 编 译 的 流程 ， 为 下 一 节 重 点 分 析 应 用 
程序 的 签名 打下 了 基础 。 
































20.4 ”信息 安全 基础 概述 


在 讲解 Android 应 用 程序 的 签名 前 ， 我 们 有 必要 补充 了 解 信息 安全 
与 密码 学 (information security and cryptography) 的 一 些 基 础 知 
识 ， 这 样 读者 对 后 面 的 学 习 就 能 “轻车熟路 ”了 。 


相信 读者 在 生活 中 多 多 少 少 都 已 经 接触 过 密码 学 的 知识 。 比 如 我 们 
在 浏览 网 页 ， 特 别 是 一 些 银行 官方 网 站 时 ， 经 常会 看 到 “http” 协 议 已 
经 悄然 变 成 了 “https”。 再 如 个 人 电子 签名 ， 它 的 权威 性 已 经 得 到 了 
广泛 的 认可 ， 并 慢 慢 取代 传统 的 签名 方式 而 具有 法 律 效力 了 。 这 些 技术 
的 迅速 发 展 ， 都 得 益 于 密码 和 安全 学 的 不 断 突破 和 创新 。 


安全 是 一 个 抽象 的 概念 。 换 名 话说， 什么 样 的 环境 才 是 “安全 ”的 
Ne? 我 们 先 来 看 看 Cryptography 的 一 个 经 典 解释 ， 引 用 自 《Handbook 
of Applied Cryptography》 一 书 : 


Cryptography is the study of mathematical techniques 
related to aspects of information security such as 
confidentiality, data integrity, entity authentication, and 
data origin authentication. 


从 中 可 以 看 出 ， 密 码 与 安全 学 的 几 个 基础 目标 是 : 


Confidentiality ; 
Data Integrity; 
Authentication; 


Non-repudiationo 


这 样 说 读者 可 能 会 觉得 艰 涩 难 懂 ， 下 面 举 个 例子 以 帮助 大 家 理解 。 
假设 有 3 个 人 人， 分别 是 小 白 (WHITE) 、 小 红 (RED) 和 小 黑 (BLACK) 。 
从 名 称 上 不 难看 出 我 们 给 它们 赋予 的 角色 : 小 白 和 小 红 是 “善良 ”的 通 
ERA; 而 小 器 则 是 “坏人 ” (Bad Guy, Adversary) ， 如 图 20-2 所 
7JNo 


lam a Bad Guy 
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全 图 20-2 信息 安全 中 的 典型 场景 


我 们 的 目的 就 是 保证 小 白 和 小 红 的 对 话 能 顺利 而 安全 地 进行 。 按 照 
景 的 开展 顺序 ， 读 者 可 以 来 推测 下 将 会 发 生 哪些 安全 隐患 。 


1. Authentication 


假设 是 小 日 发 起 的 对 话 请 求 ， 那 么 首要 的 一 个 问题 就 是 : 小 日 怎么 
知道 和 它 建 立 连接 的 是 小 红 。 或 者 反 过 来 说 ， 小 红 又 如 何 确 定 对 方 是 小 


白 呢 ? 


这 是 安全 学 中 一 个 非常 重要 的 研究 课题 ， 即 Authentication。 如 果 
场景 中 的 小 红 不 是 人 类 ， 而 是 银行 服务 器 ， 那 么 可 以 想象 一 下 如 果 小 黑 
冒充 Bank Server 而 和 小 白 建 立 连 接 ， 后 果 将 是 非常 严重 的 。 小 黑 可 以 
模仿 银行 的 登录 界面 来 轻松 骗取 小 白 的 账户 密码 ， 然 后 实施 各 种 侵害 小 
白 权 荔 的 行为 。 

因而 在 通信 双方 建立 连接 时 ， 必 须 做 相应 的 身份 认证 ， 以 保证 两 端 
的 会 话 者 都 是 合法 的 《注意 : 日 常生 活 中 用 户 登录 银行 的 网 上 银行 ， 大 
多 数 情 况 下 只 是 银行 服务 器 方 提供 了 身份 认证 ) 。 

2. Confidentiality 


现在 小 白 和 小 红 已 经 建立 连接 并 且 可 以 正常 通信 了 了。 那么 ， 这 样 就 
高 枕 无 忧 了 吗 ? 显然 不 是 。 小 黑 能 做 的 破坏 还 很 多 ， 比 如 它 可 以 在 小 白 
家 的 网 络 线 上 前 开 ， 安 装 上 监听 器 以 截取 双方 来 往 的 信息 。 这 时 小 白 和 
小 红 间 的 通信 实际 上 就 是 图 20-3 所 示 的 情况 。 


人 图 20-3 监听 通信 双方 的 往来 信息 
如 果 小 白 和 小 红 在 交流 中 泄露 了 一 些 机 密 信息 ， 如 银行 卡号 、 密 码 
等 ， 那么 小 黑 同 样 可 以 达到 非法 目的 。 解 决 的 办 法 就 是 将 通信 双方 的 内 
容 进行 加 密 处 理 ， 这 就 是 Confidentiality 所 要 解决 的 问题 。 


3. Data Integrity 


至 此 ， 小 白 和 小 红 的 安全 性 又 得 到 了 进一步 保障 一 一 它们 现在 已 经 
建立 了 和 连接， 确认 了 双方 的 身份 ， 并 且 通 信 数 据 也 已 经 得 到 加 密 ， 保 证 
小 黑 无 法 破解 其 中 的 内 容 。 不 过 这 并 不 代表 小 黑 就 无 技 可 施 了 。 虽 然 小 
黑 没 有 办 法 破解 监听 到 的 内 容 ， 但 它 仍然 可 以 算 改 这 些 信息 ， 如 图 20-4 
所 示 。 






BANANA 


“APPLE” 


“ON” “OK AY” 


全 图 20-4 签 改 通信 双方 的 信息 


7 


te 
9 Em 


ERIK SEGA ZR MBLAKA MASTER, HT 
是 它 真 的 可 以 获悉 通信 内 容 中 有 “APPLE” BÆ “OKAY” EFIR 
(因为 这 些 数据 已 经 被 做 了 加 密 处 理 ) 。 


HA, WRENS REE? TAS Ewin, WE, RAE 
很 多 场合 下 做 不 到 。 比 如 小 白 是 在 家 里 通过 有 线 宽带 上 网 ， 如 果 没有 办 
en i ae li E 
更 改 。 


我 们 所 能 做 的 ， 就 是 当 数 据 被 算 改 时 双方 可 以 察觉 到 这 种 变化 。 也 
就 是 说 ， 保 证 通信 的 发 送 端 和 接收 端 数 据 的 “完整 性 ”， 这 就 是 
Integr ity 要 解决 的 问题 。 


4. Non-repudiation 


通过 上 面 的 努力 ， 小 白 和 小 红 终于 可 以 将 小 墨 的 破坏 抛 之 脑 后 了 。 
个 过 “ 扩 外 ”以 后 ，“ 安 内 ”的 问题 融 出 现 了 。 假 设 有 这 样 一 个 场景 : 


小 白 和 小 红 在 通信 时 约定 了 茶 项 工程 的 金额 ， 但 是 没 过 几 天 ， 小 红 束 个 
认 账 了 ， 并 否认 曾经 做 出 的 承 话 。 传 统 的 解决 方法 里 ， 双 方 在 荣 项 协商 
达成 一 致 时 必须 “ 白 纸 黑 字 ”签订 合同 。 那 么 在 网 络 信息 通信 中 ， 是 否 
也 有 类 似 的 实现 手段 呢 ? 


这 就 是 “Non-repudiation” 所 要 达到 的 目的 。 它 将 保证 任何 一 方 
的 承诺 都 是 “无 可 抵赖 和 自 改 ”的 ， 以 保证 对 方 的 权益 。 


上 面 我 们 以 实例 的 形式 分 析 了 信息 安全 中 所 面临 的 4 类 基础 问题 
(实际 上 还 有 第 五 类 问题 ， 即 “Avai labi lity”， 用 以 衡量 有 某 项 服务 的 
可 用 性 和 可 访问 性 。 比 如 网 站 在 大 流量 访问 下 是 否 可 以 正常 运转 。 顺 便 
提 一 下 ， 在 密码 学 领域 发 表 论文 时 ， 一 个 惯例 就 是 要 明确 指明 你 的 
Paper 解 决 了 上 述 问题 中 的 哪 一 类 或 几 类 ) ， 接 下 来 就 需要 从 数学 原理 
的 角度 来 思考 如 何 具体 解决 这 些 问 题 。 


言 息 安全 学 的 基础 是 数学 ， 而 其 中 的 关键 点 总 结 起 来 有 3 个 ， 即 : 


e Encryption (加 密 ) ; 
e Decryption (解密 ) 。 


加 解密 算法 发 展 到 今天 种 类 已 经 相当 繁多 ， 大 的 方向 可 以 分 为 对 称 
和 非 对 称 两 种 。 


e Hash ( 哈 希 散 列 ) 。 
简单 来 讲 ，Hash 就 是 将 不 定 长 度 的 输入 变 成 定 长 输出 的 一 个 过 程 。 
我 们 先 来 看 看 加 密 、 解 密 和 哈 希 的 一 些 基础 知识 。 
5， 对 称 算 法 (Symmetric Algorithm) 


如 果 加 密 和 人 解密 过 程 所 用 的 密 钥 完全 一 样 〈 单 钥 密 码 体系 ) ， 融 是 
对 称 算 法 。 这 是 一 种 传统 的 加 密 方式 ， 从 密码 学 发 展 早期 就 已 经 存在 
当然 ， 随 着 科技 的 发 展 ， 其 算法 的 具体 实现 方式 仍 在 不 断 演 进 中 ) 。 
另外 ， 我 们 在 日 常生 活 中 其 实 也 随处 可 见 对 称 加 密 的 方式 ， 如 大 家 家 里 
的 门 锁 就 是 单 钥 系统 一 一 因为 外 出 锁 门 时 和 回 家 开门 时 所 用 的 是 完全 一 
样 的 同一 把 钥匙 。 对 称 加 密 算 法 通常 速度 很 快 ， 可 以 应 用 于 大 数据 量 加 


密 的 场合 。 


当前 密码 学 中 常用 的 对 称 算 法 包括 DES，AES 等 。 
传统 对 称 算 法 的 一 个 缺点 是 不 利于 传输 ， 如 图 20-5 所 示 。 
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全 图 20-5 对 称 算法 的 密 钥 传输 问题 
我 们 来 设想 这 样 一 个 场景 : 小 白 想 邮寄 一 封 密 信 给 小 红 ， 为 了 


防止 被 小 黑 窃 取信 件 内 容 ， 它 首先 将 信 放 入 盒子 中 ， 然 后 加 上 了 一 
把 锁 后 再 邮寄 出 去 。 这 样 确实 能 保证 小 黑 无 法 浏览 到 信 的 内 容 ， 去 


也 引出 了 一 个 致命 的 问题 ， 即 小 红 也 同样 没有 办 法 阅读 信件 的 内 
容 ， 因 为 它 和 小 墨 一样 没有 锁 的 钥匙 。 


那么 将 钥匙 和 盒子 一 起 寡 过 去 ?显然 这 样 的 方式 是 很 思春 的 ， 并 没 
有 起 到 任何 保护 密 信 的 作用 。 直 接 寄 送 密 钥 是 行 不 通 的 ， 于 是 科学 家 们 
开始 思考 ， 是 否 能 两 边 协 商 出 一 个 共同 的 密 钥 ? 这 确实 是 一 个 好 主意 ， 
不 过 小 黑 对 于 这 个 “协商 ”过 程 ， 也 肯定 是 知晓 的 《在 没有 加 密 前 ， 所 
有 信息 都 是 明文 传送 ， 小 黑 可 以 轻易 获取 两 方正 在 进行 的 任何 沟通 ) 。 
因而 这 个 方案 成 功 的 前 提 是 ， 如 何 绕 过 小 黑 来 完成 协商 过 程 。 


网 络 传输 过 程 中 的 信息 小 黑 是 能 获知 的 。 换 个 角度 来 思考 这 句 话 ， 
就 是 通信 双方 的 本 地 数据 (比如 小 白 和 小 红 的 本 地 计算 机 里 内 存 的 数 
据 ) ， 它 是 没有 办 法 得 到 的 。 整 个 协商 过 程 的 突破 口 就 在 这 里 ， 下 面 以 
著名 的 DH (Diffie-Hellman) 算法 为 例 来 解释 这 个 实现 过 程 。 


。 小 白 和 小 红 首 先 需要 有 两 个 公共 的 值 g 和 bp。 因为 是 公开 的 ， 小 黑 也 
可 以 得 到 这 两 个 数值 。 

小 白 在 本 地 产生 一 个 私密 数值 a， 小 红 也 同样 产生 一 个 私密 数值 b。 
小 白 通 过 公式 Y1=8g'a modp 计 算出 自己 的 Y 值 ， 小 红 也 根据 同样 的 
公式 算出 它 的 Y2=g^b mod po 

然后 小 白 和 小 红 互 换 它 们 的 Y 值 。 

小 白 计算 出 通信 所 需要 采用 的 密 钥 Key1l=(Y2)^a=( g^b mod 
p)^a=g^(ab)mod p， 而 小 红 这 沈 计算 出 的 密 钥 Key2=(Y1)^b=(g^a mod 
p) b= g (ab)mod p=Key1. 


这 样 一 来 ， 它 们 就 协商 出 共同 的 Key 值 了 。 那 么 这 一 过 程 中 ， 小 黑 
都 获取 了 哪些 数据 呢 ? 很 明显 ， 在 网 络 中 传输 的 值 是 g，p，Y1 和 Y2， 这 
其 中 并 没有 Key1 或 者 Key2， 而 计算 密 钥 Key 所 需 的 关键 数值 a 或 者 b， 也 
没有 被 直接 传送 。 因 为 Y 值 计算 公式 的 不 可 逆 性 ， 小 黑 绝 不 可 能 从 中 推 
导出 a 或 者 b 值 。 


因此 我 们 可 以 得 出 一 个 完美 的 结论 一 一 整个 密 钥 协商 过 程 是 安全 可 
靠 的 。 


6. 公 钥 算法 /不 对 称 算 法 (Public-key Algorithm) 


公 钥 算法 的 核心 是 加 密 和 解密 所 用 的 密 钥 不 是 同一 个 ， 我 们 分 别称 


之 为 公 钥 和 私 钥 的 Key。 一 般 情 况 下 ， 数 据 用 私 钥 / 公 铀 进行 加 密 ， 然 后 
通过 匹配 的 公 钥 / 私 钥 解 密 〈 其 中 的 数学 推导 过 程 我 们 不 做 深入 分 析 ， 
有 兴趣 的 读者 可 以 自行 查阅 相关 资料 ) 。 公 钥 是 所 有 人 都 可 以 获知 的 ， 
私 钥 则 由 个 人 自己 保存 ， 如 图 20-6 所 示 。 





AKW20-6 公 钥 算法 应 用 (1/2) 


人 通过 图 20-6 所 示 的 方法 ， 小 白 成 功 地 将 数据 安全 地 传送 给 小 红 。 因 
为 小 黑 并 没有 小 红 的 私 钥 ， 所 以 它 无 论 如 何 也 无 法 破解 数据 的 内 容 。 而 
另外 ， 因 为 公 钥 是 所 有 人 都 可 见 的 ， 就 避免 了 对 称 算 法 中 密 钥 传输 的 难 
am 
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图 20-6 我 们 使 用 的 是 接收 方 的 公 钥 来 加 密 数据 ， 如 果 反 其 道 而 行 
之 ， 用 发 送 方 的 私 钥 进 行 加 密 ， 又 会 是 什么 样 的 情况 呢 ? 如 图 20-7 所 
/小 。 





AKW20-7 公 钥 算法 应 用 (2/2) 


读者 可 能 会 觉得 有 点 奇怪 ， 既 然 公 钥 是 大 家 都 能 获取 到 的 ， 而 且 可 
以 解密 ， 那 么 数据 还 有 什么 安全 性 可 言 。 请 耐心 接着 往 下 阅读 ， 答 案 很 
快 就 会 揭晓 了 。 


常用 的 公 钥 算法 包括 RSA 和 DSA 等 。 
7. 哈 希 算法 (Hash Algorithm) 


学 习 过 数据 结构 的 读者 一 定 对 哈 希 不 陌生 ， 因 为 利用 哈 希 表 进行 信 
息 查 找 也 是 常用 的 算法 之 一 。Hash 的 作用 就 是 将 任意 长 度 的 二 进 制 值 映 
射 为 固定 长 度 的 最 终 值 。 从 概率 学 的 角度 而 言 ， 两 个 不 同 的 输入 值 经 过 
Hash 算 法 后 绝对 是 有 可 能 发 生 碰撞 的 。 因 而 算法 的 好 坏 很 大 程度 上 取决 
于 它 能 否 最 大 限度 地 降低 这 种 冲突 。 另 外 ， 哈 希 算法 要 求 整个 转换 过 程 
具有 随机 性 一 一 即 就 算 两 个 输入 值 仅 有 非常 小 的 差异 ， 其 输出 值 也 应 该 
有 “天 壤 之 别 ”。 这 样 的 设计 在 信息 安全 中 有 重要 意义 ， 可 以 有 效 防止 
非法 人 员 通 过 不 断 推测 来 获知 明文 信息 。 

Hash 算 法 除了 用 于 查找 外 ， 还 有 很 多 其 他 方面 的 应 用 ， 如 消息 摘 
要 、 数 字 签名 等 。 常 见 的 哈 希 算法 有 MD5、SHA、SHA-1、SHA-256、 
SHA384 和 SHA-512 等 。 


加 解密 和 哈 希 算法 是 解决 信息 安全 领域 众多 问题 的 基础 。 下 面 再 回 
头 来 看 看 小 白 、 小 红 之 前 磁 到 的 4 个 安全 隐患 。 


e Authentication 
我 们 知道 在 公 钥 算法 中 ， 私 钥 由 个 人 自己 保存 ， 并 且 其 他 所 有 人 都 
是 无 法 获知 的 。 这 就 给 Authentication 提 供 了 理论 依据 。 比 如 在 这 个 场 
景 中 ， 小 白 确 认 对 万 是 不 是 小 红 的 依据 ， 就 在 于 对 方 有 没有 拥有 小 红 的 
私 钥 。 具 体 如 何 操作 呢 ? 典型 的 做 法 如 下 : 
° 小 白 用 小 红 的 公 钥 去 加 密 一 段 数据 ， 然 后 传 给 对 方 ; 
° 对 方 用 私 钥 解 出 明文 数据 ， 并 返还 给 小 白 ; 


° 小 白 比 较 对 方 提供 的 明文 是 否 和 自己 本 地 保存 的 数据 匹配 。 


因为 公 钥 加 密 过 的 数据 只 能 由 私 钥 解密 ， 所 以 只 要 对 方 能 正确 解密 
出 原始 数据 ， 就 可 以 认定 它 是 小 红 。 


不 过 实际 的 过 程 要 复杂 些 。 想 象 一 下 ， 如 果 小 黑 是 等 到 小 白 和 小 红 
做 完了 认证 后 再 介入 昵 ” 因 为 此 时 小 自已 经 完全 相信 对 方 是 小 红 了 ， 很 
有 可 能 会 造成 安全 问题 。 所 以 认证 的 同时 ， 也 要 综合 考虑 双方 的 数据 加 
密 ， 这 样 才 不 会 让 非法 人 员 有 机 可 乘 。 


Confidentiality 


加 密 协商 通常 和 上 述 的 认证 过 程 综合 进行 。 如 果 是 大 数据 量 的 传 
送 ， 一 般 情 况 下 需要 使 用 DH 算法 协商 出 对 称 密 钥 ; 而 对 于 一 些小 量 的 数 
据 ， 可 以 使 用 双方 的 公 铀 进行 加 密 。 


Data Integrity 


单纯 的 加 解密 算法 无 法 解决 完整 性 认证 ， 所 以 我 们 还 需要 引入 Hash 
算法 ， 流 程 如 图 20-8 所 示 。 


上 图 的 主要 步骤 如 下 : 
° 发 送 方 首先 对 数据 进行 险 希 处 理 ， 得 到 一 个 Hash 值 ; 
° 发 送 方 将 数据 和 哈 希 值 进行 加 密 ， 并 传送 到 接收 方 ; 


° 接收 方 解 密 后 ， 先 对 数据 进行 同样 的 哈 希 处 理 ， 得 到 另 一 个 
Hash 值 ; 


° 接收 方 将 收 到 的 哈 希 值 和 上 一 步 中 得 到 的 Hash 值 进行 比较 ， 判 
断 数 据 传递 过 程 中 是 否 被 算 改 。 


e Non-repudiation 


Non-repudiation 直 译 过 来 就 是 “无 法 否认 ”。 在 认证 过 程 中 ， 我 
们 采用 的 原理 是 “只 有 拥有 私 钥 的 人 才能 解密 用 公 钥 加 密 过 的 数据 ”。 
与 此 类 似 ，“ 只 有 用 私 钥 加 密 的 数据 才能 用 公 钥 解 开 ”一 一 这 就 是 数字 
签名 所 依据 的 理论 基础 。 


假设 小 白 认 可 了 一 份 合同 ， 并 使 用 自己 的 私 钥 对 其 进行 了 加 密 ， 那 
么 如 果 后 期 发 生 纠纷 ， 就 可 以 使 用 小 白 的 公 钥 对 这 份 文件 进行 解密 。 由 
于 私 钥 的 唯一 性 ， 小 白 就 没有 办 法 抵赖 经 它 签 过 名 的 内 容 。 
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Result 


全 图 20-8 数据 完整 性 的 验证 过 程 


不 过 在 实际 应 用 中 ， 情 况 通常 不 会 这 么 简单 。 比 如 谁 能 知道 小 白 的 
公 钥 是 哪 一 个 ? 为 了 解决 这 个 问题 ， 就 需要 有 一 个 公共 的 服务 中 心 来 保 
管 和 提供 权威 的 公 钥 查询 功能 一 一 这 就 是 CA (Certificate 

Authority) 的 职责 所 在 。 


目前 市 面 上 已 有 不 少 CA 机 构 能 提供 数字 证 书 的 颁发 和 查询 ， 而 且 其 
中 一 部 分 是 免费 的 。 当 用 户 需 要 验证 茶 份 公 钥 是 否 属于 它 所 要 建立 连接 
的 机 构 或 个 人 时 ， 就 可 以 向 CA 发 起 请 求 。 在 浏览 网 页 的 过 程 中 ， 这 一 过 
程 通 常 由 浏览 器 自动 帮 你 完成 。 比 如 你 在 访问 Https 开 头 的 网 站 时 ， 通 
常服 务 器 会 发 送 一 份 经 过 CA 签名 过 的 证 书 来 证 明 自 己 就 是 你 所 要 找 的 目 
标 ， 这 时 浏览 器 就 需要 自动 去 认证 这 一 证 书 的 真 伪 。 假 如 浏览 器 已 经 有 
该 CA 的 证 书 ， 表 示 它 信任 这 个 组 织 ， 那 么 它 就 可 以 使 用 CA 的 公 钥 去 解密 
服务 器 的 证 书 并 做 完整 性 测试 。 如 果 一 切 顺利 ， 浏 览 器 就 可 以 相信 服务 
器 里 所 提供 的 公 钥 和 身份 信息 ， 而 后 使 用 这 一 公 钥 与 服务 器 进行 对 话 。 


本 小 节 我 们 从 一 个 典型 的 信息 对 话 场 景 入 手 ， 逐 步 引 出 所 有 可 能 发 
生 的 安全 隐患 。 然 后 结合 密码 学 的 基础 理论 〈 加 解密 算法 、 哈 希 算 
法 ) ， 详 细 讲 解 了 这 些 安全 问题 的 应 对 之 策 一 一 其 中 提 到 的 多 种 解决 方 
案 都 是 应 用 密码 学 中 的 典型 应 用 。 


下 一 小 节 我 们 将 向 续 者 讲述 Android 系 统 又 是 如 何 保证 应 用 程序 的 
安全 的 。 


女 


20.5 应 用 程序 签名 
Android 系 统 中 的 应 用 程序 签名 有 如 下 几 个 特点 。 


所 有 的 Android 应 用 程序 都 需要 被 签名 ， 不 论 它 是 debug 还 是 release 
版 本 。 可 以 参看 本 章 的 开头 几 个 小 节 。 

可 以 采用 自 签名 的 形式 。 也 就 是 说 ， 可 以 不 需要 上 一 小 节 提 到 的 
CA 认证 。 

系统 只 在 安装 过 程 中 检查 证 书 的 有 效 性 。 如 果 应 用 程序 安装 以 后 证 
书 才 过 期 ， 并 不 会 影响 它 的 使 用 。 

可 以 使 用 Keytool 和 Jarsigner 来 完成 签名 过 程 ， 然 后 还 需要 使 用 
zipalign 对 apk 文 件 进行 优化 。 可 以 参阅 本 章 开头 几 个 小 节 。 

建议 开发 者 对 自己 研发 的 所 有 应 用 程序 采用 统一 的 证 书 。 

当 应 用 程序 升级 时 ， 系 统 会 比较 新 旧版 本 的 证 书 是 否 一 致 。 如 果 证 
书 一 致 、 升 级 才能 顺利 进行 ; 否则 安装 将 和 失败。 当然， 你 也 可 以 更 
痪 新 版 本 的 包 名 ， 这 时 系统 会 把 它 当 成 另外 一 个 应 用 程序 进行 实 
壮 








采用 相同 签名 的 应 用 程序 允许 被 安排 在 同一 个 进程 中 运行 。 
采用 相同 签名 的 应 用 程序 间 可 以 根据 特殊 权限 进行 代码 和 数据 的 共 


=] 


F o 


接 下 来 我 们 分 别 介绍 Debug 和 Re lease 模 式 下 的 签名 过 程 。 其 中 ， 
Debug 模 式 比 较 简 单 ， 因 此 只 是 做 简单 介绍 。 


Debug Mode 


这 个 模式 下 的 签名 过 程 是 由 系统 自动 完成 的 。 因 为 采用 的 是 默认 的 
keystore， 用 户 不 需要 特地 输入 密码 等 信息 。 签 名 所 需 用 到 的 工具 
Keytoo1 和 Jarsinger 都 是 由 JDK 提 供 的 ， 因 此 需要 保证 JAVA_HOME 环 境 变 
量 的 正确 性 。 


默认 的 签名 信息 如 下 : 


e Keystore name: "debug.keystore" ; 


Keystore password: "android"; 
e Key alias: "androiddebugkey" ; 


e Key password: "android" ; 
CN: "CN=Android Debug,O=Android,C=US". 


需要 注意 的 是 ，Debug 下 所 使 用 的 证 书 也 是 会 过 期 的 ， 它 从 生成 之 
日 算 起 只 有 365 天 的 有 效 期 。 一 旦 超过 期 限 ， 系 统 会 有 类 似 下 面 的 提 
7K: 
Debug Certificate expired on 8/4/08 3:43 PM 


解决 的 万 法 就 是 将 debug. keystore 文 件 删除 ， 那 么 下 一 次 编译 时 就 
会 再 自动 生成 新 的 keystore 了 。 存 放 debug. keystore 文 件 的 路 径 依据 不 
同 的 操作 系统 会 有 所 差异 。 


e Linux 和 OS X 
~/. android/ 
© Windows XP 
C:\Documents and Settings\<user>. android\ 
e Windows 7 
>C: \Users\<user>. android\ 
Release Mode 
Release 模 式 的 签名 过 程 相对 麻烦 一 些 ， 如 下 所 示 。 
。 获取 一 个 私人 密 铀 
可 以 选择 使 用 Keytoo1 工 具 生成 一 个 新 的 密 钥 。 需 要 特别 注意 的 
是 ， 如 果 发 布 的 应 用 程序 是 针对 Google Play， 那 么 证 书 的 过 期 时 间 必 


须 在 2333 年 10 月 22 日 以 后 。Keytool 的 使 用 方法 我 们 这 里 不 做 详细 介 
绍 ， 读 者 可 以 自行 查阅 资料 了 解 。 


o 编译 telease 版 本 的 应 用 程序 
我 们 在 第 一 小 节 已 经 做 过 详细 介绍 ， 这 里 不 再 玲 述 。 
。 利用 相关 工具 对 应 用 程序 进行 签名 


JDK 已 经 提供 了 Jarsigner 来 完成 签名 过 程 。 当 然 ， 读 者 也 可 以 选择 
其 他 合适 的 工具 来 替代 Jarsigner。 关 于 这 个 工具 的 详细 使 用 方法 ， 可 
以 参见 0racle 官 方 文 档 


。 最 后 对 签名 后 的 应 用 程序 进行 对 齐 优化 


前 面 小 节 我 们 对 Zipal ign 进 行 过 简单 介绍 ， 它 保证 所 有 数据 能 按照 
特定 标准 来 相对 文件 开头 进行 字 节 对 齐 。 这 将 在 一 定 程度 上 提高 应 用 程 
序 的 运行 速度 ， 如 系统 可 以 使 用 mmap 0 来 读 取 文 件 ， 而 不 是 复制 包 中 的 
所 有 数据 。Zipalign 的 语法 很 简单 ， 范 例如 下 所 示 : 


Zipalign -v 4 App_name-unaligned.apkApp_name.apk 


其 中 ，-v 开 启 verbose 输 出 ; 数值 4 代表 要 对 齐 的 字 节 数 (当前 只 人 允 
许 填写 4) 。 


后 两 个 APK 分 别 代 表 了 输入 和 输出 。 如 果 需 要 履 盖 原 有 的 APK， 还 需 
要 加 上 -f 标 志 。 


如 果 你 觉得 使 用 命令 行 模式 效率 太 低 ， 而 且 是 在 Eclipse 环境 下 开 
发 ， 那 么 还 可 以 使 用 ADT 提 供 的 Export Wizard 来 逐步 导出 有 效 的 APK 应 
用 程序 〈 图 20-9 左 半 部 分 ) 。 这 种 方式 可 以 让 你 使 用 已 有 的 keystore 进 
行 签 名 ， 也 允许 新 创建 一 个 keystore 〈 图 20-9? 右 边 部 分 ) 。 


Frotile As F: 
Team 上 
Compare With 上 
Restore from Local History... 

4a New Test Project... 


cj New Resource File... Source 
Configure 








Export Signed Application Package 





Properties AlttEnter 


Export Unsigned Application Package... 





Display dex bytecode 
Rename Application Package 
(>) Add Support Library... 


Fix Project Properties 


V] Run Lint: Check for Common Errors 
Clear Lint Markers 


Crepes tadeehd online == 


Key Creation 
四 Enter key alias. 





Alias: 





Password: 





Confirm: 


Validity (years): 











First and Last Name: 





Organizational Unit: 





Organization: 





City or Locality: 
State or Province: | 
Country Code (XX): | 





D < Back | Hext > | Cancel | 





全 图 20-9 使 用 ADT 的 Export 功 能 导出 合法 的 APK 


这 时 编译 系统 会 对 APK 应 用 程序 展开 更 加 详细 的 检查 ， 包 括 安 全 
eour ity . MÆ (Performance) 、 可 用 性 (Usability) 等 多 个 方 
。 默 认 情 况 下 如 果 检 查 过 寺 程 中 发 现 有 错误 ， 程序 就 会 停止 APK 的 导出 


操作 。 你 也 可 以 在 Preferences->Lint Error Checking 中 关闭 这 个 检查 
功能 ， 如 图 20-10 所 示 。 


Beete ox 





type filter text 


F General 
E Android 
v Build 
DINS 
Editors 
Launch 
Lint Error Checkin 
: Loglat 
| Vsage Stats 
Ant 
Data Management 
Help 
Install /Update 
E Java 
: Appearance 
Build Path 
7 Classpath Varie 
lser Libraries 
: 由 Code Style 
Compiler 
由 Debug 
Editor 
Installed JREs 
Jnit 
Properties Files 了 
Java EE 
Java Persistence 
JavaScript 
llylyn 
Plug-in Devel opment 
Remote Systems 
Run/Debug 
Server 





Lint Error Checking 


区 When saving files, check for errors 


WY Run full error check when exporting app and abort if fatal errors are found 


Issues: 





type filter text (use to filter by severity, e.g. ignore) 





日 Correctness 
SdCardPath 


Â Looks for hardcoded references to /sdeard 

NewApi Q Finds API accesses to APIs that are not supported in all targeted API versions 
Duplicatelncluded] À Checks for duplicate ids across layouts that are combined with include tags 
Duplicatelds À Checks for duplicate ids within a single layout 

Vnknownd d Q Checks for id references in RelativeLayouts that are not defined elsewhere 
VnlmownIdInLayout (i Makes sure that Gtid references refer to views in the sane layout 
StateListReachable A Looks for unreachable states in a <selector> 


StyleCycle j Looks for cycles in style definitions 

ScrollViewSize  @) Checks that Scroll¥iews use wrap_content in scrolling dimension 
Deprecated Ô Looks for usages of deprecated layouts, attributes, and so on. 
NestedScrolling 4) Checks whether a scrolling widget has any nested scrolling widgets within 
ScrollViewCount Æ Checks that ScrollViews have exactly one child widget 


AdapterViewChildre A Checks that AdapterViews do not define their children in XML 


Gri dLayout Q Checks for potential GridLayout errors like declaring rows and columns outside the declared gri... 
OnClick Q Ensures that onClick attribute values refer to real methods 
Registered À Ensures that Activities, Services and Content Providers are registered in the manifest xl 


Severity: 


larning gi 


Looks for memory allocations within drawing code 





You should avoid allocating objects during a drawing or layout operation. These are called frequently, so a 
smooth UI can be interrupted by garbage collection pauses caused by the object allocations. 


The way this is generally handled is to allocate the needed objects up front and to reuse them for each x 


Include m| Igore 如 | Restore Detaats| Apply | 








Cancel | 


全 图 20-10 Lint Error Checking 


由 此 可 见 ，Android 系 统 提 供 了 多 种 开发 方式 。 而 具体 选择 哪 一 
种 ， 则 取决 于 开发 者 的 习惯 以 及 项 目的 实际 需求 。 当 然 ， 无 论 是 命令 行 
还 是 图 形 开 面 操作 ， 应 用 程序 的 编译 、 打 包 、 签 名 、 对 齐 这 些 操作 的 原 
理 都 是 不 变 的 。 


20.6 应 用 程序 签名 源码 简 析 
这 一 小 节 我 们 来 简要 分 析 下 应 用 程序 签名 相关 的 关键 源码 。 


首先 来 比较 下 签名 前 和 签名 后 APK 的 区 别 。 图 20-11 和 图 20-12 分 别 
显示 了 用 Eclipse 的 “Export Unsigned Application 


Package” 和 “Export Singed Application Package” 导 出 来 的 同一 个 
APK 的 目录 结构 。 


ij resources. arsc 


21, 232 
加 classes. dex 372, 952 
|S] Androi dlani fest. xml 1,892 

全 图 20-11 未 签名 的 AP 区 目录 结构 
©. S E een 
(res 
(O) META-INF 
(resources. arse 21, 232 
加 classes. dex 372, 952 
|) Androi dlani fest. xml 1, 892 


全 图 20-12 ”签名 后 的 AP 区 目录 结构 


如 果 直 接 安装 未 签名 的 APK、adb 将 会 报错 ， 如 图 20-13 所 示 。 


| 6 - 





Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES ] 
全 图 20-13 报错 


可 以 看 到 ， 两 者 间 的 唯一 差别 就 是 META-1NF 文 件 夹 ， 其 他 部 分 的 数 
据 无 论 大 小 或 者 内 容 都 是 一 样 的 。 关 于 META-1NF 我 们 前 几 个 小 节 做 过 简 
单 的 介绍 ， 它 是 专门 用 来 保存 应 用 程序 签名 和 校 验 等 安全 信息 的 目录 ， 
通常 情况 下 包括 MANIFEST. MF, CERT. SF 和 CERT. RSA 3 个 文件 。 签 名 和 校 
aaa 可 以 用 图 20-14 概 括 它 们 之 间 






Compile 


Verifier 


全 图 20-14 签名 与 校 验 简 图 


接 下 来 我 们 将 通过 分 析 ver ifier 源 码 来 了 解 META-1NF 下 各 文件 的 用 
途 以 及 整个 签名 校 验 的 大 致 流程 。 


当 一 个 应 用 程序 需要 安装 时 ， 首 先 Package Manager 会 对 其 进行 初 
始 化 处 理 。 这 其 中 就 包含 了 对 签名 和 文件 哈 希 值 的 检查 ， 孔 数 流程 如 图 
20-15 所 示 。 


这 其 中 的 逻辑 关系 比较 复杂 ， 主 要 涉及 以 下 几 个 类 。 


PackageManagerService] |PackageParser VeritierEntry | | JarFilelnputSiream 
| 


| 
installPackageL] ! 
parsePackage | 


| 
| 
| 
| 
| 
| 
collectCertificates | 





ew 


| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| | 

k | | 
gellnpulStream initl ntry | new | 
| 


new 
| 
ae a iene a sl SERS 
| 
| 
| 
| 


read 





| WII 
\ 
MANIFEST.MI | 
CERTSF 
verify 


全 图 20-15 安装 应 用 程序 时 的 安全 检查 
1. PackageParser 


负责 解析 应 用 程序 包 ， 并 完成 安全 校 验 ; 而 且 整 个 校 验 过 程 是 针对 
APK 包 中 的 所 有 文件 逐个 进行 的 ， 这 也 同时 解释 了 为 什么 MANIFEST. MF 中 
为 每 个 文件 都 提供 了 hash 值 。 一 个 典型 的 MANIFEST. MF 文件 格式 如 下 所 
7K: 
/*MANIFEST.MF*/ 
Manifest-Version: 1.0 
Created-By: 1.0 (Android) 


Name: res/drawable-ldpi/pty.png 
SHA1-Digest: JfxEcu/NKzCCaCsgirwnOxUBK7U= 


Name: res/drawable-ldpi/fm3_down.png 
SHA1-Digest: LvoLkSkySbbH79GbuCc+qg311do= 


Name: res/drawable-ldpi/signal2.png 
SHA1-Digest: yVjMqmIUQ5cKNi/dgyq3502d3gQ= 


Name: res/drawable-ldpi/fm2.png 
SHA1-Digest: 9M3S7wzBvE2bJn/ffalIF+546sk= 


Name: res/drawable/key4_select.xml 
SHA1-Digest: jj3NmAj]UMeqfAQvn10ijUNHQN9Q= 


Name: res/drawable-ldpi/ta_indicate.png 
SHA1-Digest: kcqTpfODE7dhiQTsYOmiCCZP61I= 


安装 过 程 中 只 要 有 任何 文件 的 Hash 匹 配 无 法 通过 ， 整 个 安装 就 会 终 
止 ， 并 有 类 似 如 下 的 提示 : 


Package *** has no certificates at entry ** ; ignoring! 
其 中 的 entry 即 指 程序 包 中 发 生 错误 的 文件 。 


我 们 这 里 再 补充 一 些 密码 学 的 基础 知识 ， 这 样 读 者 在 学 习 源 码 时 就 
更 容易 理解 了 。 以 上 面 MANIFEST. MF 中 的 第 一 个 文件 为 例 ， 即 : 


Name: res/drawable-ldpi/pty.png 


SHA1-Digest: JfxEcu/NKzCCaCsgirwnOxUBK7U= 
计算 这 个 pty. png 文 件 的 SHA-1 摘 要 值 的 步骤 如 下 。 


。 根据 SHA-1 算 法 得 到 这 个 文件 的 摘要 。 标 准 SHA-1 的 输出 位 数 为 
160bit。 

。 有 读者 可 能 会 觉得 奇怪 ， 既 然 SHA-1 的 输出 为 160 位 ， 即 20 个 字 节 ， 
那么 为 什么 下 面 的 字符 串 有 28 个 呢 ? 这 是 因为 上 述 得 出 的 20 字 节 的 
数据 还 需要 经 过 BASE64 编 码 。 

BASE64 的 基本 规则 是 将 原始 数据 的 3 个 字符 变 为 4 个 字符 ， 每 6 位 前 
加 上 2 位 0， 所 以 最 终 得 到 的 每 字 节 最 大 值 都 不 会 超过 64。 因 为 0 一 63 的 
ASC11 码 有 不 可 见 字符 ， 为 了 方便 起 见 ， 算 法 还 会 将 这 64 个 数值 分 别 对 
应 为 固定 的 可 见 ASC11 字 符 。 

比如 经 过 SHA-1 运 算 后 ， 我 们 得 到 如 下 值 : 


25FC4472EFCD2B3082682B20D6BC273B15012BB5， 一 共 20 个 字 节 。 





前 3 个 字 节 的 二 进 制 码 为 00100101(25) 11111100(FO) 
01000100 (44) 


我 们 在 每 6 位 前 都 加 上 两 位 0， 这 样 就 变 成 : 
00 001001 00 011111 00 110001 00 000100 
| | | | 
十 进 制 9 31 49 4 
根据 BASE64 表 ， 数 值 ?、31、49 和 4 分 别 对 应 可 见 ASC11 字 条 中 的 J、 
f、x 和 E， 这 和 我 们 上 面 看 到 的 MANIFEST. MF 中 的 结果 完全 一 致 ， 因 而 说 
明 这 个 pty. png 文 件 没 有 被 算 改 过 。 读 者 可 以 依照 上 面 的 算法 自行 计算 
剩余 的 几 个 字符 。 
28 JarFile 


继承 自 ZipFi le， 每 一 个 Apk 包 只 对 应 唯一 的 JarFile， 这 也 进一步 


验证 了 应 用 程序 包 实 际 上 是 一 个 Zip 压 缩 包 。 它 代表 了 检验 过 程 中 的 一 
真正 的 匹配 工作 则 由 JarVver ifier 完 成 ， 可 以 参见 后 面 的 类 图 
关系 。 


3. JarVerifier 


JarVerifier 是 各 种 校 验 数据 的 储存 仓库 ， 同 时 它 包 含 了 
ral ifierEntryREX, BASWS—-—TPMAF MEADS LAL 


4. VerifierEntry 


真正 的 匹配 是 在 这 里 完成 的 。Jaryver ifier 在 生成 一 个 
verifierEntry 时 ， 会 进行 一 定 的 初始 化 ， 然 后 JarFilelnputStream 还 
会 进一步 完善 其 中 的 数据 ， 然 后 进行 核验。 成功 后 它 的 Entry 将 提交 
JarVerifier 进 行 存储 ， 以 备 后 期 查询 。 


5. JarFilelnputStream 
继承 自 1nputStream， 同 时 也 是 JarFi le PAVRER. 
我 们 再 提供 一 个 类 图 来 帮助 读者 理解 ， 如 图 20-16 所 示 。 


PackageParser 





+collectCertificates() 
tloadCertificates() 


JarFile 


—JarVeritier verifier 
+ge(InputStream()} 


Fr 一 一 一 一 一 一 一 一 一 一 


I | ee 


-Hashtable signatures 


-Hashtable certificates 
-J lashtable verifiedFntries 


+initEntry() 





InputStream 


adí 


+read() 
+write() 
N 


JatFilelnputStream 


-long count 
~ZipEntry zipEntry | 


-VerifierEntry entry 





VerilierEntry 


-String name 
-MessageDigest digest 
-byte|| hash 
~Certilicate[] certificates 
twrile() 


wet) 





从 图 20-16 安全 校 验 相关 类 的 关系 图 
接 下 来 我 们 分 析 部 分 重点 代码 : 


/*frameworks/base/core/java/android/content/pm/PackageParser. java 
public boolean collectCertificates(Package pkg, int flags) 4.. 

JarFile jarFile = new JarFile(mArchiveSourcePath); /* 创 建 一 个 、 

以 APK 包 的 





if ((flags&PARSE_IS_SYSTEM) != 0) {/* 如 果 这 个 包 来 源 于 system ime 
因而 只 检查 AndroidManifest .xml 文 件 ， 不 用 逐个 椒 


selse{ 

Enumeration<JarEntry> entries = jarFile.entries(); // 程 | 

while (entries.hasMoreElements()) {// 对 包 中 的 所 有 文件 逐一 进 

final JarEntry je = entries.nextElement(); 

if (je.isDirectory()) continue; // 忽 略 目录 

final String name = je.getName(); // 文 件 名 

if (name.startsWith("META-INF/") ) 

continue; 

if (ANDROID_MANIFEST_FILENAME.equals(name)) {/* 如 果 文 件 是 
pkg.manifestDigest =ManifestDigest.fromInputStream 
ream(je)); 





final Certificate[] localCerts = loadCertificates(jarFi 


/* 这 是 整个 安全 检查 的 关键 ， 下 面 我 





PackageParser 通 过 col lectCertificates () 来 检验 程序 包 中 的 所 有 
文件 是 否 都 符合 要 求 ， 然 后 才能 返回 PackageManager 继 续 执行 安装 过 
程 。 这 个 函数 分 为 两 个 部 分 : 


e 解析 package 包 ， 得 到 所 有 文件 ; 
o 对 这 些 文件 进行 逐一 检验 。 


安全 检查 的 关键 在 于 loadCertificates， 如 下 所 示 。 


/*frameworks/base/core/java/android/content/pm/PackageParser 
private Certificate[] loadCertificates(JarFile jarFile, JarEn 
try { 
InputStream is = new BufferedInputStream(jarFile.getInp 
Stream( ) 返 回 一 个 JarFileInputStream 实 例 ， 后 者 又 包含 了 一 个 已 经 
Entry 实 例 */ 





while (is.read(readBuffer, ©, readBuffer.length) != -1) 
Stream 中 包含 了 JarFileInputStream， 所 以 最 终 是 


is.close(); 

return je != null ? je.getCertificates() : null; 
} catch (IOException e) 4.. 
} catch (RuntimeException e) {.. 


return null; 


I 
ae Side WHEE RI RAP ILA 
e CERT.RSA 


这 是 应 用 程序 开发 者 提供 的 证 书 ， 包 含 了 该 开发 者 的 公 钥 和 一 系列 
身份 信息 。 因 为 是 自 签 名 的 ， 就 不 需要 CA 的 认证 。 


e CERT.SF 


BS. SF 应 该 是 Signature File 的 缩写 ， 所 以 这 就 是 我 们 所 说 的 
签名 文件 。 根 据 前 面 学 习 的 密码 学 基础 ， 它 是 对 “ 某 个 文件 ”的 Hash 值 
进行 私 钥 加密 产 生 的 。 那 么 针对 这 里 的 情况 ， 有 具体 是 指 哪个 文件 呢 ? E 
论 上 当然 可 以 对 每 个 文件 的 摘要 分 别 进行 签名 ， 但 Android 选 择 了 一 个 
聪明 点 的 办 法 ， 即 它 只 对 整个 WANIFEST. MF 进 行 了 加 密 一 一 因为 它 包 含 
了 应 用 包 中 所 有 文件 的 Hash 值 。 这 样 既 可 以 检查 此 文件 是 否 完整 可 靠 ， 
也 可 以 验证 程序 提供 的 私 钥 和 公 钥 是 否 匹 配 。 


e MANIFEST.MF 


只 要 确认 了 MANIFEST. MF 文 件 的 可 靠 性 ， 就 可 以 通过 读 取 其 中 的 信 
息 来 为 APK 包 中 的 所 有 文件 做 一 一 校 验 。 接 下 来 的 代码 中 我 们 侧重 于 对 


这 一 校 验 过 程 的 分 析 。 
先 来 看 看 Read 函 数 的 内 部 实现 : 


public int read() throws IOException 4... 
if (count > 0) {/x* 如 果 count 大 于 0， 说 明 还 有 数据 需要 写 入 Veri 
initEntry() 时 已 经 做 过 初始 化 */ 
int r = super.read(); 
if (r != -1) { 





entry .write(r);// 写 入 entry 中 ， 为 校 验 做 准备 
count--; 

} else { 
count = 0; 


} 
if (count == 0) { 
done = true; 
entry.verify();/* 所 有 数据 都 已 经 保存 完毕 ， 进 入 校 验 阶 





return r; 

} else { 
done = true; 
entry.verify(); 
return -1; 


} 


后 我 们 再 来 看 看 VerifierEntry (在 JarVerifier. java 文 件 中 ) 里 
verify 函 数 的 实现 : 


class JarVerifier 4.. 

class VerifierEntry extends OutputStream { // 实 际 上 是 一 个 OutputStre 
void verify() {/* 这 个 verify() 函 数 的 作用 是 将 CERF .SF 解密 后 的 数据 
以 此 来 证 明证 书 的 有 效 性 。 因 而 它 并 不 是 用 来 验证 应 用 程序 

byte[] d = digest.digest(); 
if (!MessageDigest.isEqual(d, Base64.decode(hash))) {/ 
MANIFEST .MF 中 的 SHA-1 值 经 过 了 BASE64 编 码 ， 因 此 这 里 还 需要 : 
throw invalidDigest(JarFile.MANIFEST_NAME, name, ja 























verifiedEntries.put(name, certificates); 


J 
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效 地 保护 了 开发 者 的 权益 。 另 外 ， 它 也 为 用 户 选择 和 安装 合法 来 源 的 应 
用 程序 提供 了 有 力 的 保障 。 


20.7 APK 重 签名 实例 

前 面 几 个 小 节 我 们 分 析 了 Android 应 用 程序 的 签名 机 制 ， 从 中 可 见 
整个 过 程 是 相对 续 密 的 。 但 是 ， 这 并 不 代表 我 们 可 以 “高 枕 无 忧 ”， 无 
视 APK 的 安全 问题 了 。 事 实 上 ， 由 于 Android 系 统 是 自 签名 的 ， 我 们 完全 
可 以 对 第 三 方 应 用 程序 进行 重新 签名 ， 然 后 做 二 次 发 布 一 一 这 样 得 到 的 
APK 通 常情 况 下 也 可 以 在 Android 系 统 中 正常 运行 。 

本 小 节 我 们 将 讲解 如 何 对 第 三 方 的 应 用 程序 进行 重新 签名 。 

。Step1. 解压 APK 文 件 


因为 APK 实 际 上 是 一 个 zip 包 ， 所 以 你 可 以 通过 很 多 常用 的 工具 来 把 
其 中 的 内 容 解 压 出 来 。 


e Step2. 删除 其 中 的 META-INF 文 件 夹 
我 们 知道 ， 这 个 文件 夹 保 存 了 开发 者 的 公 钥 、 签名 以 及 APK 中 各 文 
件 的 Hash 值 等 重要 信息 。 重 新 签名 意味 着 这 些 资料 将 被 全 部 更 新 ， 因 而 
我 们 可 以 删除 它们 
e Step3. 将 上 述 的 文件 夹 重新 打包 为 zip 文 件 


打包 后 可 以 将 后 缀 名 由 “zip” 改 为 “apk”。 我 们 假设 完成 这 一 步 
操作 后 的 文件 名 称 为 “Your Unsigned. apk” 


。 Step4. 利用 jarsigner 工 具 进 行 重新 签名 打包 
这 一 步 是 真正 执行 重 签名 的 地 方 ， 所 以 尤其 关键 。 


如 果 你 安装 的 JDK 是 7 或 者 以 上 版 本 ， 那 么 建议 你 通过 以 下 命令 行 来 





> jarsigner -keystore ~/. android/debug. keystore -storepass 
android -keypass android sigalg MD5withRSA digestalg SHA1 
YourUnsigned. apk androiddebugkey 


否则 ， 采 用 下 面 的 命令 : 


> jarsigner -keystore “/. android/debug. keystore -storepass 
android -keypass android YourUnsigned. apk androiddebugkey 


接着 对 重 签名 后 的 文件 进行 优化 处 理 : 
>zipalign 4 YourUnsigned. apk Aligned. apk 


如 果 你 的 操作 系统 环境 是 Windows， 可 以 根据 实际 情况 对 上 述 命令 
行进 行 微 调 ， 但 基本 上 是 大 同 小 异 的 。 


如 果 你 觉得 命令 行 的 方式 太 过 于 繁琐 ， 也 可 以 下 载 GU1 工 具 来 完 
成 。 图 20-17 是 目前 比较 流行 的 re-sign. jar LAWEAH. 


B 





=> 
i! 
APK 


Drop .apk here 


全 图 20-17 主 界 面 


可 以 看 到 ，APK 重 新 签名 的 过 程 并 不 复杂 ， 这 或 许 也 是 市 面 上 很 多 
Android 应 用 程序 被 非法 二 次 打包 的 一 大 原因 。 当 然 ， 被 重新 签名 的 APK 
的 公 钥 信息 与 原 APK 相 比 显 然 已 经 发 生 了 变化 。 而 且 公 钥 和 私 钥 又 是 配 
对 的 ， 这 就 意味 着 在 升级 应 用 程序 的 场景 下 ， 我 们 可 以 通过 比 对 要 安装 
的 APK 与 老 版 本 APK 的 公 钥 信息 来 判断 这 个 应 用 程序 是 否 出 自 同 一 家 开发 
商 ， 从 而 在 一 定 程度 上 来 防止 恶意 程序 的 破坏 。 


Android 虚 拟 机 


21.1 ， Android 虚拟 机 基础 知识 
21.1.1 Java 虚拟 机 核心 概念 


如 果 从 1991 年 James Gosling 创 立 Java 的 前 身 一 一 oak 算 起 ，Java 已 
经 走 过 了 二 十 多 年 。 其 凭借 “Write once, Run anywhere” 的 口号 征服 
了 无 数 的 开发 者 与 设备 厂商 ， 并 仍 在 不 断 焕发 出 新 的 生机 一 一 与 其 说 是 
Android 系 统 将 Java 带 向 了 男 一 个 新 高 度 ， 倒 不 如 说 是 站 在 Java 这 个 巨 
人 的 肩膀 上 才 造 就 了 Android 今 天 的 成 绩 。 


我 们 知道 ，Android 系 统 在 成 立 之 初 就 选择 Java 作 为 其 首选 的 应 用 
程序 编程 语言 。 一 方面 ， 当 时 市 面 上 的 Java 应 用 程序 已 经 具备 一 定 的 体 
量 ， 某 种 程度 上 有 利于 Android 系 统 “ 坐 享 渔翁 之 利 ”; 另 一 方面 ， 
Java 语 言 快 速 构建 应 用 程序 的 能 力 对 于 Goog1e 壮 大 Android 生 态 圈 也 是 
KAHA. 


问题 在 于 ，Java 程 序 的 运行 需要 完整 的 虚拟 机 环境 ， 而 Android 系 
统 本 身 又 是 一 个 开源 项 目 ， 显 然 无 法 直接 使 用 商用 的 JVM《〈 当 然 ，JVNM 与 
终端 设备 之 间 “ 水 土 不 服 ”是 另 一 个 重要 的 考量 因素 ) 。 怎 么 办 呢 ? 
Google 给 出 的 答案 是 自 研 一 整套 具有 “Android 特 色 ” 的 Java 虚 拟 机 运 
行 时 环境 一 一 不 可 否认 的 是 ，Android 虚 拟 机 的 诞生 过 程 中 ， 或 多 或 少 
都 会 “借鉴 ”商业 JVM 中 的 一 些 设计 思想 和 技术 实现 (这 同时 也 为 后 续 
0racle 和 Google 之 间 的 “ 恩 恩怨 怨 ” 埋 下 了 伏笔 ) 。 





所 以 虽然 严格 意义 上 讲 Android 系 统 中 的 Dalvik/Art 并 不 算 100% 纯 
正 的 Java 虚 拟 机 (它们 并 不 完全 遵循 JVM 规 范 ) ， 但 “ 骨 子 ” 里 看 它们 
和 HotSpot 等 官方 JVM 又 源 出 一 脉 。 因 而 建议 大 家 在 研究 Dalvik/Art 之 前 
有 
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有 鉴于 此 ， 本 小 节 我 们 将 介绍 Java 虚 拟 机 的 一 些 核心 概念 ， 希 望 能 
为 大 家 后 续 章 节 的 学 习 打下 必要 的 根基 。 不 过 限于 篇 幅 ， 我 们 只 能 对 某 
些 关 键 技 术 “ 点 到 即 止 ”， 因 而 强烈 建议 读者 们 可 以 自行 参阅 Java 和 
Java 虚 拟 机 的 相关 资料 ， 如 0racle 的 《Java Language 
Specificatiodn》《The Java Virtual Machine Specification) =. 


如 果 用 一 句 话 来 概括 Java 虚 拟 机 所 要 解决 的 核心 问题 ， 那 么 就 是 它 
提出 的 口号 ， 即 如 何 做 到 “Write once, Run anywhere”。 为 了 达到 这 
一 终极 目标 ， 它 需要 把 开发 人 员 编 写 的 Java 语 言 文件 编译 为 中 间 状 态 的 
Bytecode， 然 后 再 在 运行 阶段 针对 具体 的 平台 做 “转译 ”一 一 将 字 节 码 
翻译 成 目标 平台 对 应 的 机 器 码 ; 其 他 的 诸如 JIT、lnterpreter 、 内 存 分 
oe 线程 管理 等 子 系统 从 本 质 上 说 都 是 为 这 一 终极 目标 而 服务 


理解 上 述 这 点 很 重要 ， 它 将 引导 我 们 从 更 本 源 的 角度 来 思考 JVM 的 
实现 。 


当 我 们 在 分 析 Java Virtual Machine 时 ， 应 该 注意 区 分 以 下 几 个 概 


è? 


。 抽象 的 Java 虚 拟 机 规范 ; 
o 具体 的 Java 虚 拟 机 实现 ; 
o 和 运行 时 态 的 Java 虚 拟 机 实例 。 


第 一 个 概念 指 的 是 0racle 官 方 发 布 的 Java 虚 拟 机 协议 规范 ; 然后 不 
同 厂商 可 以 基于 这 一 规范 来 实现 具体 的 JVM (Hotspot) 一 一 因而 市 面 
上 流行 的 虚拟 机 实现 方案 可 能 会 有 很 多 种 。 并 且 这 些 方案 并 不 一 定 完全 
采用 纯 软件 来 完成 ， 还 有 可 能 是 软 硬 件 的 集合 体 。 


当 一 个 虚拟 机 程序 运行 起 来 后 ， 便 形成 了 Java 虚 拟 机 实例 。 按 照 
Java 虚 拟 机 规范 中 的 描述 ， 我 们 可 以 从 Subsystem、Memory Area, Data 
Type 和 |instruction 几 个 维度 来 度量 JVM。 


毋庸 置疑 ，JVM 的 首要 任务 就 是 执行 Java 程 序 ， 因 而 通常 情况 下 一 
个 虚拟 机 实例 与 程序 的 生命 周期 是 紧密 绑 定 在 一 起 的 。JVM 中 的 线程 可 
以 分 为 daemon 和 non-daemon 两 种 ， 前 者 是 指 VM 自身 使 用 的 线程 ， 如 执行 
垃圾 回收 操作 的 工作 线程 (程序 也 可 以 将 它 的 线程 标注 为 daemon 
thread) 。 


虚拟 机 是 和 物理 机 相对 应 的 概念 ， 通 常 而 言 ， 一 个 虚拟 机 就 是 对 茶 
种 物理 形态 的 模拟 。 我 们 知道 ， 计 算 机 执行 代码 的 过 程 实际 上 也 代表 了 
其 自身 状态 的 迁移 过 程 一 一 这 个 观念 从 图 灵机 伊始 ， 本 质 上 是 “ 豆 古 未 
变 ” 的 。 抽 象 来 讲 ， 计 算 机 处 理 代 码 的 逻辑 如 下 所 示 : 





while(true) 

{ 
根据 当前 pc 寄存 器 取出 指令 ; 
执行 指令 ; 
调整 pc 寄存 器 值 ， 

} 


虚拟 机 和 物理 机 的 处 理 逻 辑 可 以 说 是 “一 脉 相 承 ”的 ， 只 不 过 它们 
各 自 所 面临 的 具体 对 象 和 场景 都 有 所 差异 。 


读者 可 以 思考 一 下 ， 如 果 以 一 个 简单 模型 来 描述 Java 虚 拟 机 ， 应 该 
是 什么 样子 的 呢 ? 相 较 于 通用 型 的 虚拟 机 〈 如 Qemu) ，JVM 的 目的 性 更 
为 明确 ， 即 “根据 输入 的 代码 ， 得 到 正确 的 结果 ”， 如 图 21-1 所 示 。 


Input 
Related Code 





全 图 21-1 JVM 的 0 层 模型 


图 21-1 中 我 们 并 没有 将 Input 部 分 直接 限定 为 Java Code， 这 是 因为 
随 着 JVM 的 不 断 发 展 ， 它 已 经 不 再 拘泥 于 最 初 的 范畴 了 。 比 如 我 们 完全 
可 以 在 编译 阶段 就 把 Java 代 码 编译 成 机 器 码 ， 这 种 情况 下 在 JVM 中 执行 
的 就 个 是 Java Code 了。 


JVM 的 内 部 运作 机 制 是 相当 复杂 的 。 根 据 《The Java Virtual 
Machine Specification》 中 的 描述 ，Java 虚 拟 机 在 运行 时 的 逻辑 结构 
大 致 如 图 21-2 所 示 。 


接 下 来 我 们 逐一 分 析 JVM 染 构 中 的 部 分 核心 模块 ， 以 此 为 基础 
来 “ 规 探 ”和 理解 它 的 内 部 运行 机 制 。 


(1) ClassLoader 和 双亲 委派 模型 
ClassLoader 〈 类 加 载 器 ) 提供 了 一 种 灵活 的 方式 ， 来 帮助 应 用 程 


序 将 字 节 码 流 以 自 定义 的 方式 加 载 到 虚拟 机 中 。 它 既是 Java 虚 拟 机 中 的 
一 个 重要 特性 ， 同 时 也 是 0SG1 、 热 部 署 等 技术 的 基础 。 
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全 图 21-2 Java 虚 拟 机 运行 时 


Java 虚 拟 机 中 通常 会 存在 如 下 几 种 ClassLoader 类型. 


Bootstrap ClassLoader; 


o 
e Extension ClassLoader; 

e System ClassLoader; 

e User ClassLoader. 

ClassLoader 用 于 加 载 Java 类 ， 而 大 多 数 类 型 的 ClassLoader 自 身 却 

也 是 Java 类 ， 这 就 意味 着 我 们 需要 一 个 非 Java 的 “ 鸡 ” 来 生 第 一 
n “g” 这 就 是 Bootstrap ClassLoader, MEH 
称 “Bootstrap” 也 同样 可 以 看 出 这 一 点 。Bootstrap ClassLoader H 
C/C++ 语言 编写 完成 ， 是 虚拟 机 自身 管理 功能 的 一 部 分 。 它 所 加 载 的 类 
通常 位 于 [JAVA_HOME]/1ib 中 ， 或 者 由 -Xbootc1asspath 指 定 ， 属 于 Java 
的 核心 实现 部 分 (例如 java. *, javax. * 等 ) 。 


Extension ClassLoader 则 负责 JRE 扩 展 目 录 中 的 各 种 类 的 加 载 ， 例 
如 [JAVA_HOME]/1ib/ext 文 件 夹 中 的 内 容 如 图 21-3 所 示 。 


System ClassLoader 又 被 称 为 应 用 程序 类 加 载 器 ， 它 用 于 加 载 
CLASSPATH 中 的 各 种 类 对 象 ， 可 以 通过 
ClassLoader. getSystemClassLoader () 来 获取 。 如 果 应 用 程序 没有 提供 
自 定义 的 ClassLoader， 那 么 默认 情况 下 系统 将 使 用 System 
ClassLoader 来 加 载 应 用 程序 中 的 类 。 


最 后 一 种 类 加 载 器 由 应 用 程序 提供 ， 它 们 都 应 该 继承 自 
java. lang. ClassLoader， 并 按照 规范 实现 其 中 的 接口 。 


那么 面 对 这 么 多 的 类 加 载 器 ，Java 虚 拟 机 应 该 如 何 管 理 ， 它 们 之 间 
又 有 什么 关联 呢 ? 


根据 Java Specification 中 的 规定 ， 任 何 一 个 类 都 必须 由 
ClassLoader 和 类 名 称 两 者 结合 才 可 以 得 到 唯一 确定 。 换 名 话说， 通过 
两 个 ClassLoader 加 载 同 一 个 Class 文 件 ， 最 终生 成 的 两 个 对 象 之 间 是 没 
有 直接 联系 的 。 


为 了 避免 由 此 产生 的 类 关系 混乱 ，Java 设 计 出 了 “ 双 杀 委派 ” 模 
型 ， 它 的 核心 框架 摘 述 如 图 21-4 所 示 。 


用 户 自 定义 的 ClassLoader 〈 即 最 底层 的 实现 ) 首先 在 Cache 中 查询 
被 加 载 对 象 是 否 已 经 存在 。 如 果 答 案 是 肯定 的 话 ， 直 接 返 回 结果 ; 否则 





它 会 优先 委派 它 的 上 一 级 〈 即 System ClassLoader) 去 执行 加 载 动作 ， 
而 不 是 马上 由 其 自身 来 党 试 加 载 目 标 对 象 。System ClassLoader 也 遵循 
同样 的 处 理 远 辑 ， 直 到 模型 到 达 最 顶端 一 一 Bootstrap ClassLoader. 
这 样 一 来 程序 中 的 基础 类 〈 如 0bject) 都 处 于 同一 空间 域 中 ， 从 而 有 效 
避免 了 混乱 的 发 生 。 


车 | access-bridge-64.jar 
四 | cldrdata,jar 

is, dnsns.jar 

车 | jaccess.jar 

辐 | jfxrtjar 

i| localedata.jar 

|_| meta-index 

i) nashornJar 

lä] sunecjar 

车 | sunjce_provider.jar 
车 | sunmscapi.jar 

车 | sunpkcs11.jar 


lë] zipfsjar 


全 图 21-3 文件 夹 


Bootstrap ClassLoader 


Extension ClassLoader 


System ClassLoader 


Uesr ClassLoader 


从 图 21-.4 Java 双 亲 委 派 模 型 


下 面 我 们 结合 Android 系 统 中 的 ClassLoader. loadClass(), RIA 
证 一 下 实际 的 类 加 载 过 程 : 


/*libcore/ojluni/src/main/java/java/lang/ClassLoader.java*/ 
protected Class<?> loadClass(String name, boolean resolve) 
throws ClassNotFoundException 


// First, check if the class has already been loaded 
Class c = findLoadedClass(name);//Cache P24 CAE Ht 
if (c == null) {// 之 前 未 加 载 过 目标 类 
long tO = System.nanoTime(); 
try { 
if (parent != null) {// 优 先 让 parent 执 行 加 载 操作 
= parent.loadClass(name, false); 
} else { 
= findBootstrapClassOrNull(name) ; 





} catch (ClassNotFoundException e) { 
// ClassNotFoundException thrown if class not 
// from the non-null parent class loader 


} 
if (c == null) {// 双 亲 模 型 中 的 所 有 上 层 都 没有 加 载 成 功 ， 落 


long t1 = System.nanoTime(); 
c = findClass(name); 











} 
i 


return c; 


这 段 代码 的 处 理 逻 辑 并 不 复杂 ， 如 下 所 示 。 


Step]. 首先 检查 是 否 已 经 加 载 过 目标 对 象 ， 即 
findLoadedClass () 。 


Step2. 如 采 上 一 步 中 未 找到 目标 类 ， 那么 接 下 来 优先 调用 它 的 父 
加 载 器 提供 的 loadC1ass。 假 如 没有 父 加 载 器 的 话 ， 则 使 用 内 建 
(built-in) 的 ClassLoader。 


Step3. 如 果 仍 然 没有 加 载 成 功 ， 此 时 就 可 以 启动 自身 的 加 载 器 功 
能 了 ， 即 findClass () 。 


值得 一 提 的 是 ，ClassLoader 并 非 只 要 完成 类 的 加 载 操作 就 可 
以 “万 事 大 吉 ” 了 ， 它 的 完整 职责 和 对 应 的 处 理 流 程 如 下 所 示 。 


Step1. Loading 
查找 和 加 载 目 标 类 数据 。 
Step2. Linking 


链接 过 程 是 检验 目标 类 是 否 合法 有 效 的 关键 环节 。 它 又 可 以 被 细 分 
为 以 下 几 个 子 项 : 


e Verification 

检验 加 载 的 数据 是 否 合法 、 正 确 
e Preparation 

为 类 变量 和 其 他 数据 分 配合 理 的 内 存 空 间 ， 并 初始 化 为 默认 值 。 
e Resolution 


将 符号 型 引用 转换 为 直接 引用 〈 类 似 于 C/Cr+ 中 的 重 定位 过 程 ) 的 


过 程 o 


Resolution〈 解 析 ) 过 程 的 输入 端 是 符号 引用 ， 输 出 端 则 是 直接 引 
用 。 我 们 可 以 这 么 理解 ， 符 号 引用 虽然 是 和 具体 的 内 存 布 局 无 关 的 ， 但 
是 必须 遵循 统一 的 标准 以 便 可 以 在 不 同 的 硬件 平台 上 被 正确 运行 ; 直接 
引用 则 是 能 指向 目标 对 象 的 内 存 地 址 、 偏 移 量 ， 或 者 其 他 可 以 代表 目标 
实例 的 对 象 。 

Step3. Initialization 

为 上 述 步 骤 中 的 对 象 做 初始 化 操作 。 

只 有 执行 了 如 上 几 个 步骤 后 ， 类 对 象 才 算是 真正 地 加 载 完 成 了 。 


(2) Runtime Data Areas 


Runtime Data Areas 是 JVM 在 程序 运行 过 程 中 所 需 的 数据 区 域 ， 由 
Stack、Heap 、MethodArea 等 多 个 部 分 组 成 。 


其 中 Program Counter Register 区 是 实现 Java 多 线程 管理 的 关键 之 
一 《从 前 面 的 框架 图 中 不 难 发 现 ， 每 个 Java 虚 拟 机 线程 都 需要 彼此 独立 
的 PC 寄存 器 ) 。 如 果 被 执行 的 函数 属于 nat ive 方 法 的 话 《〈 需 要 特别 注意 
的 是 ， 虽 然 C[C++ 在 JNI1 中 使 用 得 最 为 广泛 ， 但 Java 虚 拟 机 规范 中 并 没有 
特别 规定 nati ve 语言 具体 是 什么 ) ， 那 么 这 个 PC 寄存 器 实际 上 是 没有 定 
义 的 《因为 native 取 数 代 码 可 以 被 物理 硬件 直接 识别 并 执行 ， 此 时 并 不 
需要 模拟 的 PC Register) 。 


JVM 中 的 Stack 区 域 也 是 线程 独立 的 ， 它 们 伴随 新 线程 的 创建 而 出 
现 ， 并 随 线程 结束 而 消亡 。Java 虚 拟 机 中 的 栈 和 其 他 编程 语言 中 的 作用 
是 类 似 的 ， 即 用 于 存储 本 地 变量 和 栈 帧 等 临时 数据 。 什 么 叫 栈 帧 呢 ? 


Java 规 范 中 对 Stack Frame 的 定义 如 下 所 示 : 


“A frame is used to store data and partial results, as 
well as to perform dynamic 


linking, return values for methods, and dispatch 
exceptions” 


可 见 栈 帧 和 函数 之 间 是 一 对 一 的 关系 ， 它 的 内 部 包含 了 本 地 变量 数 
组 、 操 作 数 栈 以 及 对 运行 时 常量 池 的 引用 等 多 重信 息 。 


当 JVM 执 行 一 个 新 函数 前 ， 首 先 需要 创建 并 初始 化 一 个 Stack 
Frame， 然 后 压 入 栈 中 。 由 此 可 见 Stack 中 的 frame 数 量 将 随 着 被 调用 郴 
数 数量 的 增加 而 不 断 上 升 一 一 除非 函数 执行 结束 ， 此 时 JVM 才 会 释放 其 
对 应 的 frame。Stack Frame 是 解释 器 中 非常 重要 的 组 成 元 素 ， 建 议 大 家 
可 以 结合 起 来 理解 。 


JVM 中 另 一 个 重要 的 运行 时 内 存 区 域 是 Heap。 它 通常 被 用 于 给 各 种 
类 实例 和 数组 分 配 动 态 内 存 ， 而 且 这 一 部 分 内 存 空间 是 由 所 有 JVM 线 程 
共享 的 。 我 们 所 说 的 内 存 管理 和 垃圾 回收 机 制 大 多 情况 下 也 是 专门 针对 
堆 内 存 开展 的 ， 后 续 小 节 中 对 此 还 会 有 进一步 的 描述 。 


和 Heap 一 样 作为 所 有 线程 共享 区 域 而 存在 的 还 有 Method Area. MR 


名 思 义 ， 这 个 区 域 保存 的 内 容 有 点 类 似 于 操作 系统 进程 中 
的 “Text”Segment， 即 俗称 的 “代码 段 ”。 它 包含 了 每 个 Class 结 构 中 
的 运行 时 常量 池 、 方 法 数据 、 方 法 的 源 代码 等 一 系列 重要 信息 。 


Native Method Stacks 简 单 来 讲 用 于 支撑 JVM 运 行 hative 语 言 (= 
如 C/C++ 语言 ) 编 写 的 代码 。 不 过 这 块 区 域 并 不 是 必需 的 ， 取 决 于 JVM 的 
能 力 以 及 程序 的 具体 需求 。 下 面 是 一 个 Java 的 运行 时 范例 ， 如 图 21-5 所 
7JNo 


thread! | thread? | — thread 3 


stack 
frame 


pe registers Java stacks 





全 图 21-5 Java 运行 范例 (引用 自 «Inside the Java Virtual Machine» ) 


从 图 21-5 中 可 以 看 到 ， 这 个 Java 程 序 当 前 有 3 个 线程 ， 其 中 线程 1 和 
2 正在 执行 Java Method， 因而 PC Register 指 向 的 是 正在 执行 的 语句 
( 浅 色 块 ) ; 而 线程 3 因为 正在 执行 Native Method， 所 以 它 的 PC 寄存 器 
是 没有 定义 的 (上 暗色 块 )， 同 时 native method stack 被 用 于 支撑 
thread 3 执行 本 地 代码 。 


(3) 堆 和 垃圾 回收 


前 面 我 们 说 过 ， 堆 内 存 的 一 个 特点 是 “进程 独立 ， 线 程 共 享 ”。 换 
名 话说 ， 每 个 JVM 实 例 都 拥有 它们 自己 的 Heap 空 间 ， 从 而 保证 了 程序 间 
的 安全 性 ; 不 过 进程 内 部 的 各 个 线程 则 会 共享 一 个 堆 空 间 ， 因 而 需要 注 
意 访问 堆 变 量 时 的 代码 同步 问题 。 


Java 相 较 于 C/C++ 语言 的 一 个 重要 区 别 是 它 具 备 垃圾 自动 回收 的 能 
力 一 一 这 同时 也 是 堆 内 存 管理 系统 最 关键 的 一 个 功能 点 。 随 着 JVM 的 不 
断 更 新 换代 ， 其 所 支持 的 垃圾 回收 算法 也 在 不 停 地 推陈出新 。 我 们 这 里 
简单 讲述 一 下 业界 目前 最 为 流行 的 回收 算法 之 一 ， 即 “分 代 垃 圾 回 
收 ” 算 法 ， 如 图 21-6 所 示 。 


-n -XX: MaxPermSize 


-XX; PermSize 
“XX; aa 
= 
O | 


permananet 


reserved 
reserved 
reserved 





Young Generation (ld Generation Permanent 


全 图 21-6 内存 分 代 管 理 简 图 


简单 而 言 ， 分 代 回 收 机 制 会 将 内 存 划 分 为 如 下 “三 代 ” 来 区 别管 
TH 


e Yong Generation 


即 年 轻 代 内 存 ， MATAR EE 分 为 eden、 s0 和 s1 三 种 ， 其 中 后 两 者 也 
被 称 为 “from space” 和 “to space” 


e Old Generation 
老年 代 内 存 又 被 称 为 “Tenured Space” 


e Permanent Generation 


永久 代 内 存 ， 用 于 存储 和 类 、 方 法 相关 的 Meta Data， 并 不 属于 





Heap 的 范畴 ， 在 某 些 情况 下 可 以 不 予以 考虑 。 


所 有 内 存 空间 的 申请 请 求 都 首先 考虑 从 Eden 区 分 配 。 此 时 分 为 两 种 
情况 : 如 果 能 顺利 满足 该 内 存 申 请 则 “皆大欢喜”; 否则 会 触发 一 次 
Minor GC， 清 理 Eden 以 及 其 中 一 个 Survivor 中 的 垃圾 。JVM 规 定 
Survivor 至 少 得 有 一 个 始终 是 空 的 一 一 并 被 标记 为 “To Survivor”。 
清理 完成 后 ， 那 些 无 法 回收 的 对 象 〈 包 括 Eden 和 Survivor ) 会 被 转移 到 
另 一 个 Survivor 中 。 此 时 因为 两 个 Survivor 的 职责 发 生 了 变化 ， 所 以 它 
们 会 互 换 各 自 的 标记 《〈 即 From 和 To) 。 


、 那么 对 象 什么 时 候 会 被 复制 到 01d Space 中 呢 ? 这 取决 于 下 面 两 种 


情况 : 
e Casel: Survivor 已 满 
那么 它 所 管理 的 对 象 就 会 被 复制 到 01d Space. 
© Case2: 对 象 的 存活 时 间 达 到 一 定 国 值 
羡 值 可 以 通过 MaxTenur ingThreshold 来 调整 。 每 执行 一 次 MinorGC 
就 代表 存活 对 象 “ 又 长 了 一 岁 ”， 直 到 它们 起 过 阐 值 达到 “质变 ”后 被 
复制 到 01d Space 中 。 
如 果 01d Space 也 满 了 ， 就 会 触发 一 次 Full GC6， 对 内 存 垃圾 进行 全 
面 清 理 。 假 设 经 过 Fu11 GC 仍 无 法 满足 程序 的 内 存 请 求 ， 那 么 就 很 可 能 
产生 0ut0fMemory 的 错误 。 


当然 ， 上 述 流程 只 是 内 存 分 代 管理 和 回收 的 核心 思想 ， 实 际 的 内 部 
实现 远 比 我 们 描述 得 复杂 ， 感 兴趣 的 读者 可 以 参考 Java 官 方 文档 获取 更 


(4) Execution Engine 


执行 引擎 是 虚拟 机 中 的 中 枢 系 统 ， 它 将 为 程序 的 运行 提供 源源 不 断 
的 血液 供应 。 目 前 主流 的 虚拟 机 一 般 都 支持 多 种 执行 方式 ， 例 如 : 


。 Java? WE RERIT; 

。 在 运行 阶段 根据 一 定 的 算法 将 使 用 频率 高 的 字 节 码 编译 成 Native 
Code (JID， 然 后 再 执行 ; 

。 在 编译 阶段 就 将 字 节 码 直 接 转换 成 机 器 码 ， 类 似 于 Art 虚 拟 机 所 和 采 
用 的 AOT 技 术 。 


一 个 方法 的 字 节 码 流 是 由 一 连 串 指令 序列 构成 的 。 每 条 指令 都 包含 
了 一 个 单字 节 的 opcode， 以 及 紧 随 其 后 的 0 个 或 多 个 操作 数 〈 理 论 上 JVM 
是 和 零 操 作 数 的 ， 但 事实 上 会 有 一 些 例外 情况 ) 。 执 行 引擎 在 同一 时 间 只 
能 运行 一 条 指令 。 它 首先 获取 指令 的 opcode， 以 及 对 应 的 操作 数 〈 如 果 
有 的 话 ) ， 然 后 执行 它们 一 一 如 此 循环 往复 直到 线程 正常 或 异常 结束 。 
如 果 程 序 请 求 执行 一 个 Native Method， 那 么 执行 引擎 在 完成 这 一 请 求 
后 还 是 会 返回 到 字 节 码 流 中 继续 执行 。 


接 下 来 我 们 将 通过 一 个 实际 范例 来 对 比 基 于 栈 和 基于 寄存 器 的 执行 
引擎 的 实现 差异 ， 从 中 大 家 也 可 以 学 习 到 Execution Engine 处 理 字 节 三 
的 典型 过 程 。 


(5) 基于 寄存 器 和 基于 栈 的 Java 虚 拟 机 实现 


Java 虚 拟 机 执行 字 节 码 有 很 多 种 实现 方式 ， 其 中 运用 最 广泛 的 就 是 
基于 寄存 器 和 基于 栈 两 种 。 关 于 它们 二 者 之 间 的 “ 优 劣 ”之 争 ， 业 宕 讨 
论 由 来 已 久 【〈 比 较 经 典 的 是 一 篇 名 为 《Virtual Machine Showdown: 
Stack Versus Registers》 的 论文 ， 有 兴趣 的 读者 可 以 自行 查找 阅读 ) 
简单 而 言 ， 这 两 种 技术 各 有 千秋 ， 不 能 一 概 而 论 。 开 发 商 应 该 根据 
具体 需求 因地制宜 地 选择 最 适合 自己 的 实现 方式 。 


当然 ， 一 个 不 争 的 事实 是 ; 目前 市 面 上 大 多 数 的 JVW 都 是 基于 栈 实 
现 的 ; 这 与 真实 世界 中 的 物理 处 理 器 正好 相反 ， 因 为 后 者 是 基于 寄存 器 
的 。“ 存 在 即 是 合理 ”， 我 们 不 难 推断 出 在 虚拟 机 领域 ， 基 于 栈 的 “ 模 
拟 ” 方 式 一 定 有 其 过 人 之 处 。 艾 如 : 


。 单条 指令 更 为 紧凑 
由 于 JVM 中 执行 的 是 字 节 码 ， 不 需要 像 基于 寄存 器 的 染 构 那样 显 性 
地 指定 源 和 目标 ， 因 而 采用 栈 实现 的 方式 可 以 降低 单条 指令 的 Code 


Size。 





。 可 移植 性 更 强 


基于 寄存 器 的 虚拟 机 需要 考虑 很 多 与 目标 平台 强 相关 的 因素 。 比 如 
我 们 需要 根据 硬件 平台 的 真实 寄存 器 的 数量 、 它 们 的 用 途 等 ， 来 实现 虚 
拟 机 中 的 寄存 器 和 真实 世 弄 中 的 寄存 器 之 加 的 “映射 关系 ”， 从 而 提高 
执行 效率 。 相 较 而 言 ， 栈 虚拟 机 没有 这 方面 的 顾虑 ， 因 而 通用 性 更 强 。 


当然 ， 基 于 栈 的 实现 方式 也 有 其 缺点 ， 例 如 : 


。 由 于 指令 是 基于 栈 来 操作 的 ， 导 致 了 完成 同一 个 任务 所 需 的 指令 数 
比 基 于 寄存 口 的 架构 要 多 。 

。 从 执行 速度 来 看 ， 基 于 千 存 器 的 架构 具有 一 定 优势 。 因 为 基于 栈 的 
实现 方式 需要 更 多 次 数 的 内 存 读 写 操作 ， 而 且 完 成 同一 个 操作 所 需 
的 指令 数量 也 比 前 者 要 多 (虽然 单条 指令 的 体积 要 小 ) o 


为 了 让 大 家 对 这 两 种 技术 的 内 部 实现 有 一 个 更 直观 的 认识 ， 我 们 特 
别 编写 了 一 个 Java 小 程序 ， 并 在 接 下 来 的 内 容 中 加 以 详细 齐 析 。 


其 中 Java 源 码 摘抄 如 下 : 


public class Calculator { 
public static void main(String args[]){ 
Calculator cal = new Calculator(); 
System.out.println("add="+cal.add()); 


} 

public int add() 

{ 
int a=400; 
int b=200; 
int c= a+b; 
return c; 


} 
+ 


首先 ， 我 们 将 上 述 代码 段 对 应 的 程序 在 Host 机 上 进行 编译 ， 并 使 用 
以 下 命令 来 分 析 对 应 的 字 节 码 : 


javap -c XX.class 
得 到 的 结果 如 下 : 


public class calc.Calculator { 


public calc.Calculator(); 

: aload_ 0 

1: invokespecial #8 // Method java/lang/Object 
4: return 


public static void main(java.lang.String[]); 


Code 
O: new #1 // class calc/Calculat 
3: dup 
4: invokespecial #16 // Method "<init>":()V 
7: astore_1 
8: getstatic #17 // Field java/lang/System.out:Lj 
11: new #23 // class java/lang/StringBuilder 
14: dup 
15: ldc #25 // String add= 
17: invokespecial #27 // Method java/lang/StringBuilder ."<i 
20: aload_1 


21: invokevirtual #30 // Method add:()I 

24: invokevirtual #34 //Method java/lang/StringBuilder.appe 
27: invokevirtual #38 // Method java/lang/StringBuilder.toS 
30: invokevirtual #42 // Method java/io/PrintStream.printin 
33: return 


public int add(); 


0: sipush 400 
3: istore_1 

4: sipush 200 
7: istore_2 

8: iload 1 

9: iload 2 

10: iadd 

11: istore_3 

12: iload_3 

13: ireturn 


以 add 0 函数 为 例 ， 我 们 看 到 其 中 包含 了 很 多 诸如 sipush、 
istore_x 这 样 的 栈 操作 指令 ， 不 难 理解 这 是 针对 “ 栈 实现 虚拟 机 ”而 生 
成 的 编译 结果 。 


下面 我 们 再 以 图 例 的 形式 来 帮助 大 家 理解 这 些 指令 ， 如 图 21-7 所 
示 。 


sipush 400 


Local Variables Stack 


tis 
Et E i 
Local Variables Stack 
=u 
400 
Local Variables Stack 


Local Variables Stack 


-请 
rome) 
am] 


200 





Local Variables Stack 


= Variables ra 


全 图 21-7 指令 


图 例 中 的 左 半 部 分 代表 的 是 当前 正在 执行 的 指令 ， 右 边 则 
是 “ 栈 ” 中 的 最 新 状态 。 由 于 篇 幅 有 限 ， 我 们 合并 了 某 些 相似 指令 的 执 
行 过 程 〈 例 如 | load XX) A 


通过 前 面 的 学 习 ， 我 们 知道 Stack Frame 中 包含 了 本 地 变量 区 、 操 
作 数 栈 等 信息 ， 基 于 栈 的 虚拟 机 事实 上 就 是 借助 于 对 这 些 存储 区 域 
的 “腾挪 ”来 执行 函数 功能 的 。 


IMP GBIF AA EE, 18 “eB, BARS” , HIEARAG 
述 图 例 已 经 学 习 到 了 基于 栈 的 虚拟 机 的 基本 原理 了 。 接 下 来 我 们 就 可 以 
切入 到 基于 寄存 器 的 实现 方式 了 AL) ATT RAISE FA Ei Wadd ej 
数 ， 只 不 过 这 次 我 们 将 它 编译 成 Android 版 本 ， 结 果 如 下 : 





00042c: | [90042c] com.example.myapp 
00043c: 1300 9001 |0000: const/16 vO, #int 40 
000440: 1301 c800 |0002: const/16 v1, #int 20 
000444: 9002 0001 |0004: add-int v2, vO, vi 
000448: 0f02 |0006: return v2 


通过 对 比 基 于 栈 和 基于 寄存 器 的 编译 结果 ， 我 们 不 难 发 现 ， 基 于 寄 
存 器 的 方式 所 产生 的 指令 数量 相对 较 少 ; 但 每 一 条 指令 所 占 的 空间 却 比 
基于 栈 的 方式 要 多 〈 璧 如 00043c 和 000444 这 两 条 都 是 4 字 节 的 指令 ; 
000448 则 是 一 条 2 字 节 指令 


另外 ， 基 于 寄存 器 的 编译 指令 和 我 们 常见 的 汇编 代码 是 非常 相似 
的 。 在 我 们 这 个 范例 场景 中 ， 函 数 add 0 的 处 理 逻 辑 比较 简单 ， 所 以 只 
用 到 了 v0、v1 和 v2 共 3 个 寄存 器 。 指 令 序 列 利用 这 3 个 寄存 器 计算 出 
400+200 的 “和 ”， 并 将 最 终结 果 通 过 v2 来 返回 给 调用 者 。 


相信 从 这 个 范例 中 ， 大 家 可 以 学 习 到 基于 栈 和 基于 寄存 器 的 执行 引 
擎 在 代码 长 度 、 指 令 数量 和 执行 方式 等 多 方面 的 区 别 。 


21.1.2 ”LLVM 编 译 器 框架 


LLVM 的 全 称 是 Low Level Virtual Machine, BAET 
University of Illinois at Urbana- ĉhanpaldn; 是 一 个 开源 项 目 。 根 


据 其 官方 网 站 上 的 表述 ，Virtual Machine 这 个 名 字 起 得 并 不 是 特别 贴 
切 ， 因 为 LLVM 和 我 们 传统 意义 上 的 虚拟 机 没有 太 大 关系 一 一 它 本 质 上 表 
达 的 是 : “The LLVM Project is a collection of modular and 
reusable compiler and toolchain technologies”。 换 名 话说 ， 相 
对 于 传统 的 编译 器 ，LLVM 的 价值 在 于 它 的 “可 模块 化 ”以 及 “可 重复 使 
用 ” o 


随 着 LLVM 的 不 断 发 展 状 大 ， 它 所 提供 的 Toolchain 数 量 也 在 增长 。 
目前 LLVM 包 含 的 核心 子 项 目 如 表 21-1 所 示 。 


表 21-1 ”LLVM 各 核心 子 项 目 释义 





Sub- Description 
Projects 


提供 了 与 具体 的 编译 源 和 编译 目标 无 关 的 优化 器 ， 


以 及 支持 多 种 主流 CPU 的 代码 生成 工具 


C/C++/Objective-C 编 译 器 








Native Debugger 


beam 这 个 子 项 目 实现 了 LLVM 优 化 器 /代码 生成 器 


实现 了 标准 的 C++ 库 ， 并 完全 支持 C++11 规 范 





基于 LLVM 技 术 实 现 的 Java 和 和 .NET 虚拟 机 (不 过 当 


前 已经 停止 维护 ) 


pe | 现 了 标准 的 OpenCL 库 | 
= 为 C/C++ 程序 提供 了 内 存 安 全 的 编译 器 
这 是 clang/llvm 内 置 的 linker 





学 习 LLVM 最 好 的 资料 还 是 11vm. org 官 网 ， 以 及 它 的 原始 作者 Chr is 
Lattner 〈 这 位 出 生 于 1978 年 的 年 轻 人 之 前 或 许 并 不 为 大 多 数 读者 所 熟 
知 。 但 随 着 他 加 入 Apple 人 公司， 以 及 其 主导 的 Swift 语言 的 日 益 流 行 ， 这 
位 LLVM 的 主要 缔造 者 收获 了 越 来 越 多 的 掌声 ) 所 写 的 一 篇 文章 ， 大 家 可 
以 从 下 面 链 接 中 找到 : 


http://www.aosabook.org/en/llvm.html 


LLVM 的 核心 思想 并 不 复杂 ， 如 图 21-8 所 示 。 


Source Frnend | Ootinger | Baten Machine 
Cage rontend | Optimizer | Dacken Cafe 





全 图 21-8 Three-Phase Compiler ( 4] Á http://www.aosabook.org/en/llvm.html) 
这 就 是 LLVM 的 抽象 框架 ， 看 上 去 相当 的 简洁 。 主 要 分 为 3 个 部 分 。 
e Frontend 


前 端 负责 分 析 源 代码 、 检 查 错误 ， 然 后 将 源码 编译 成 抽象 语法 树 
(Abstract Syntax Tree) 。 


e Optimizer 


优化 器 如 其 名 所 示 ， 会 通过 多 种 优化 手段 来 提高 代码 的 运行 效率 ， 
而 且 它 在 一 定 程度 上 是 独立 于 具体 的 语言 和 目标 平台 的 。 


e Backend 
。 后 端 也 被 称 为 是 代码 生成 器 ， 用 于 将 前 述 的 源码 转化 为 目标 平台 的 
指令 集 。 
LLVWM 的 模块 化 和 可 重复 使 用 的 设计 理念 使 得 旨 在 支持 多 种 源码 语言 
和 目标 平台 的 编译 器 受 葵 良 多 。 


C Frontend X86 Backend > X86 


Fortran Common 
PowerPC 


Frontend Optimizer Backend 


Ada Frontend ARM Backend > ARM 





A 421-9 LLVM 的 模块 化 (4) Á http://www.aosabook.org/en/Ilvm.html) 


从 图 21-9 中 我 们 不 难看 出 ， 如 果 要 让 基于 LLVM 框 架 的 编译 器 支持 一 
种 新 语言 ， 那 么 所 要 做 的 可 能 仅仅 是 实现 一 个 新 的 Frontend， 而 已 有 的 
0ptimizer 和 Backend 则 能 做 到 重复 使 用 。 这 无 疑 是 对 传统 编译 器 的 一 大 
创新 ， 同 时 大 大 降低 了 开发 周期 和 开发 难度 。 


LLVM 的 上 述 能 力 得 到 实现 的 前 提 ， 在 于 它 的 一 个 非常 重要 的 设计 
Intermediate Representation (ERIR) 。1R 能 在 LLVM 的 编译 器 
中 (具体 而 言 是 在 0ptimizer 阶 段 〉 以 一 种 相对 独立 的 方式 来 表述 各 种 
源 代码 ， 从 而 很 好 地 剥离 了 各 种 不 同 语言 间 的 差异 ， 进 而 实现 模块 的 重 
用 。 下 面 我 们 引用 官方 的 一 个 范例 来 让 大 家 对 1R 有 个 直观 的 认识 。 


范例 是 使 用 C 语 言 编写 的 两 个 简单 函数 : 
unsigned addi(unsigned a, unsigned b) { 


return a+b; 


t 


// Perhaps not the most efficient way to add two numbers. 





unsigned add2(unsigned a, unsigned b) { 
if (a == 0) return b; 
return add2(a-1, b+1); 


这 两 个 add 函 数 完 成 了 相同 的 功能 ， 即 计算 两 个 变量 之 和 ， 只 不 过 
在 实现 上 略 有 差异 一 一 而 且 从 执行 效率 上 看 add1 相 对 于 add2 更 可 取 些 。 


在 LLVM 编 译 器 中 它们 首先 会 被 转化 成 IR， 对 应 的 . 11 文 件 如 下 所 





/小 : 


define i32 @add1(132 %a, 132 %b) { 
entry: 

%tmp1 = add 132 %a, %b 

ret 132 %tmp1 


define i32 @add2(i32 %a, i32 %b) { 
entry: 
%tmp1 = icmp eq i32 %a, © 
br i1 %tmp1, label %done, label %recurse 


recurse: 
%tmp2 = sub 132 %a, 1 
%tmp3 = add 132 %b, 1 
%tmp4 = call 132 @add2(i32 %tmp2, 132 %tmp3) 
ret 132 %tmp4 


ret 132 %b 


从 上 述 add 函 数 的 1R 描 述 中 ， 可 以 看 到 它 既 有 点 类 似 于 某 种 低级 的 
RISC 指 令 集 ， 同 时 又 在 尽力 和 具体 的 机 器 语言 “保持 距离 ” 后 面 这 
点 尤为 重要 ， 它 是 LLVM 能 够 轻松 支持 多 种 语言 和 目标 平台 的 关键 所 在 。 
可 想 而 知 ，1R 这 个 “中 间 人 ”的 职责 就 是 保证 前 端 和 后 端的 “无 缝 ” 对 
接 一 一 这 意味 着 ，1R 既 不 能 太 复杂 ， 否 则 前 端 所 生成 的 1R 很 可 能 会 变 得 
异常 繁琐 ; 同时 也 不 能 太 “ 简 单 ”， 否 则 也 无 法 保证 优化 工作 的 正常 开 
展 。 


关于 1R 的 更 多 细节 例如 怎么 书写 一 个 1R 的 优化 器 ，1R 与 前 端 源 码 
具体 是 如 何 转 化 的 等 等 ) 及 内 部 实现 原理 ， 强 烈 建 议 大 家 能 够 自行 查阅 
相关 资料 并 做 更 深入 的 分 析 学 习 。 





21.1.3 Android 中 的 经 典 垃圾 回收 算法 


Garbage Collection (HIKE) 简单 来 讲 是 一 种 自动 化 的 内 存 管 
理 机 制 。 它 的 历史 可 以 追溯 到 上 世纪 的 50 年 代 ， 所 以 并 非 Java 语 言 的 专 
利 。 但 不 可 否认 的 是 ，Java 语 言 的 蓬勃 发 展 极 大 地 推动 了 GC 技术 的 推 陈 
出 新 ， 进 而 让 其 为 更 多 的 开发 者 所 知晓 。 我 们 曾 在 本 书 基本 知识 章节 谈 
到 过 内 存 指针 的 强大 之 处 ， 以 及 它 可 能 带 来 的 各 种 梦 太 ， 也 分 析 了 
Google 为 了 应 对 这 一 问题 所 引入 的 智能 指针 机 制 。 可 见 无 论 是 “ 先 
天 ”还 是 “后 天 ”，“ 自 动 化 内 存 管理 ”这 一 优良 特性 都 受到 了 各 种 语 
言 的 青睐 。 当 然 ， 凡 事 通 常 有 利 也 有 弊 一 一 自动 化 内 存 管理 带 来 的 直接 
影响 是 系统 资源 的 额外 消耗 以 及 运行 性 能 的 降低 《〈 这 个 问题 也 是 垃圾 回 
收 技术 不 断 升 级 换代 的 一 个 重要 原动力 ) 。 


本 小 节 中 我 们 来 简要 分 析 下 Android 系 统 中 所 采用 的 6GC 算 法 ， 以 便 


为 后 面 的 学 习 打 下 一 定 的 技术 基础 。Android 系 统 中 不 管 是 Dalvik 或 是 
， 它 们 所 使 用 的 垃圾 回收 算法 都 是 以 Mark-Sweep 为 根基 演变 而 来 


Mark 的 字面 意思 是 “标记 ”， 在 这 里 指 的 是 对 所 有 内 存 对 象 进行 遍 
历 处 理 、 统 计 和 标记 的 过 程 ; 相对 应 的 Sweep 即 是 “清扫 ”过 程 一 一 依 
据 Mark 阶 段 提 供 的 结论 来 完成 垃圾 回收 。 

Mark-Sweep 算 法 的 核心 步骤 有 3 个 ， 如 下 所 示 : 

Step1， 首先 ， 系 统 中 所 有 0b jects 对 应 的 Mark Bit 都 会 被 清空 

Step2，Mark 阶 段 。 从 GC Root 开始 遍历 系统 中 的 所 有 对 象 一 一 只 
从 “ 根 ” 开 始 有 一 条 路 径 可 以 到 达 某 个 Object， 那 么 我 们 就 可 以 将 它 的 
状态 标记 为 “被 引用 ”， 或 者 更 直 白 地 说 就 是 “还 有 利用 价值 ” 


Step3， 系 统 开始 线性 地 处 理 堆 中 的 所 有 元 素 ， 并 将 那些 没有 被 标 
记 为 “有 利用 价值 ”的 对 象 做 Sweep 处 理 。 


下 面 我 们 再 针对 上 述 3 个 步骤 进行 扩展 说 明 。 
(1) GC 的 触发 时 机 
我 们 知道 智能 指针 采用 的 是 引用 计数 的 方式 来 实现 内 存 的 自动 化 管 


理 。 这 就 意味 着 对 象 引 用 的 每 次 变更 都 需要 调整 计数 ， 直 到 Count 值 为 0 
时 才 回 收 内 存 一 一 换 句 话说 引用 计数 的 GC 触 发 条 件 是 Count 为 0。 相 对 于 
Reference Counting，GC 采 用 的 触发 方式 在 某 种 程度 上 效率 更 高 ， 因 为 
它 不 需要 频繁 地 为 各 对 象 调整 计数 值 ， 而 是 选择 在 某 些 特定 的 情况 下 统 
一 进行 处 理 。 那 么 6C 的 触发 时 机 应 该 如 何 选择 才 是 合理 的 呢 ? 
以 Android 系 统 为 例 ， 发 生 6C 的 常见 场景 有 如 下 几 种 。 
e GC_FOR_MALLOC 


堆 内 存 已 满 ， 而 你 的 程序 尝试 去 分 配 新 的 内 存 块 的 情况 。 此 时 系统 
需要 暂停 程序 来 回收 内 存 。 


e GC_CONCURRENT 


és 当 堆 内 存 超过 特定 阔 值 (Begins to fill up) 时 ， 触 发 的 并 行 6C 事 





e GC_HPROF_DUMP_HEAP 


当 开 发 者 主动 请 求 创建 HPROF 〈 可 以 参见 本 书 第 5 章 关 于 程序 内 存 优 
化 的 分 析 ) 文件 来 帮助 分 析 堆 内 存 时 触发 的 GC。 


e GC_EXPLICIT 


“ 显 性 6C6”， 比 如 程序 主动 调用 gc () 函数 来 完成 垃圾 回收 。 不 过 我 
人 因为 理论 情况 下 系统 会 自动 帮 你 完成 这 些 操 


由 此 可 见 ，6C 的 触发 条 件 大 致 分 为 两 类 : 其 一 是 由 程序 主动 请 求 产 
生 ; 另 一 个 就 是 当 程序 运行 过 程 中 分 配 内 存 出 现 〈 或 者 即将 出 现 ) Ke 
情况 时 系统 做 出 的 主动 响应 。 


(2) GC Root 是 什么 
GC Root 是 Mark-Sweep 中 非常 重要 的 角色 。 试 想 一 下 ， 如 果 一 个 活 


路 有 用 的 对 和 象 却 在 6C 后 不 复 存在 ， 那 么 后 果 是 不 堪 设 想 的。 因而 如 何 快 
速 有 效 地 区 分 出 “罪犯 ”与 “良民 ”， 是 保证 6 成 功 的 关键 点 之 一 。 


Dalvik 规 定 GC Root 至 少 应 包含 以 下 这 些 元 素 : 
(1) System classes defined by root classloader 
(2) For each thread: 


e Interpreted stack, from top to "curFrame" 

e Dalvik registers (args + local vars) 

e JNI local references 

e Automatic VM local references (TrackedAlloc) 
e Associated Thread/VMThread object 

e ThreadGroups 


e Exception currently being thrown, if present 
(3) JNI global references 
@ Interned string table 
© Primitive classes 
©) Special objects 
@ Objects in debugger object registry 


感 兴趣 的 读者 可 以 参考 Dav1ik 的 官方 文档 和 A0SP 工 程 项 目 中 的 源码 
了 解 其 中 的 详细 信息 。 


(3) Mark 的 执行 过 程 


为 了 让 大 家 更 好 地 理解 这 一 算法 的 原理 ， 下 面 我 们 通过 一 个 范例 来 
做 实际 分 析 。 如 图 21-10 所 示 。 





A 图 21-10 Mark-Sweep 7 45] 


在 这 个 简单 的 演示 图 中 ，GC Root Set 共 包含 了 6 个 对 象 〈 当 然 它们 
还 会 分 别 引 用 其 他 对 象 ) 。 璧 如 Root 2 引用 了 A， 后 者 又 引用 了 B 和 (Ci; 
同 理 ，Root 4 引用 了 D; 而 对 象 E 则 没有 被 Root Set 中 的 任何 元 素 所 引 
用 。 


在 Mark[ 价 段 ， 系 统 首 先 从 GC Root Set 中 的 每 一 个 元 素 出 发 ， 逐 一 
遍历 它们 所 引用 的 各 子 对 象 ， 以 及 子 对 象 所 引用 的 其 他 对 象 对 于 从 





GC Root 出 发 可 以 到 达 的 对 象 〈 如 图 21-10 中 的 ABCD) ， 都 会 被 标记 在 一 
个 名 为 Mark Heap 的 Bitmap 中 ， 以 备 后 用 。 更 具体 地 讲 ， 系 统 从 Root 节 
点 出 发 的 路 径 中 发 现 的 所 有 新 对 象 ， 都 会 被 添加 到 GC Root Seth, + 
做 好 Bitmap 的 更 新 ; 这 样 当 最 顶层 的 6C Root 元 素 全 部 处 理 完成 后 ， 紧 
a A pl 直到 Set 中 没有 新 的 元 素 
NA. 


在 我 们 这 个 场景 中 ， 在 Mark 阶 段 没 有 被 标记 的 元 素 是 E 和 F， 所 以 它 
们 将 成 为 下 一 步 Sweep 操 作 中 的 “被 处 理 对 象 ” 。 


(4) Sweep 的 执行 过 程 


有 了 Mark 中 的 积累 ，Sweep 的 执行 过 程 相 对 来 说 就 顺畅 得 多 了 。 可 
选 的 实现 方式 也 很 多 ， 比 如 线性 遍历 整个 堆 来 释放 没有 被 标记 的 对 象 。 
Android 中 除了 Mark Heap Bitmap 外 ， 还 有 另 一 个 辅助 Sweep 的 元 素 ， 即 
Live Heap Bitmap。 其 中 LHB 记 录 的 是 已 经 分 配 的 对 象 ， 而 MHB 按 前 面 的 
分 析 保 存 的 是 本 次 需要 存活 的 对 象 一 一 这 样 只 要 综合 这 两 个 Bitmap 中 的 
数据 就 可 以 准确 判断 出 哪些 对 象 是 本 轮 Sweep 的 “牺牲 品 ” 了 。 


总 体 来 说 ，Mark-Sweep 算 法 不 仅 实 现 简单 ， 而 且 比 起 引用 计数 又 有 
其 自身 的 优势 ， 因 而 在 GC 领 域 广 受 欢迎 。 


21.1.4 Art 和 Dalvik 之 争 


Dalvik 是 Android 4. 4 版 本 前 的 标准 虚拟 机 ， 它 成 功 地 支撑 了 
Android eH “HEIL” BRA “RIE” ARE PIE, AAndroidAt 
RRIA E TAS AY BS KA DT o 


虽然 在 当前 的 Android 系 统 中 Art 虚 拟 机 已 经 取代 了 Dalvik， 后 者 似 
乎 成 了 “上 昨日 黄花 ”， 但 这 并 不 表示 Dalvik 已 然 “ 一 无 是 处 ”。Art 虚 
拟 机 事实 上 是 基于 Dalvik 的 深入 改造 ， 因 而 研究 后 者 对 于 我 们 理解 Art 
是 大 有 褐 益 的 。 有 鉴于 此 ， 我 们 将 在 本 小 节 先 对 Dalvik 的 基础 知识 做 一 
个 必要 的 铺垫 。 


一 个 新 生 事物 往往 是 伴随 着 问题 的 解决 而 出 现 的 ， 这 几乎 已 经 成 为 
科技 发 展 史 中 “ 吾 古 不 变 ” 的 原则 。 从 这 个 角度 来 看 ，Dalvik 也 一 定 是 
为 了 解决 某 种 困境 或 挑战 而 存在 的 一 一 而 且 纵 观 最 近 十 几 年 来 的 技术 格 
局 ， 这 种 挑战 往往 不 是 只 来 自 于 技术 创新 本 身 ， 同 时 也 隐 含 着 各 个 大 公 


司 之 间 的 “政治 较量 ”。 


Dalvik 的 初始 作者 是 Dan Bornstein， 据 说 这 个 虚拟 机 的 名 字 起 源 
于 其 祖先 居住 过 的 一 个 冰岛 小 渔村 。Dalvik 出 现 的 时 候 ，Sun 公 司 的 
Java 语 言 和 JVM 已 经 在 市 面 上 占据 领先 地 位 。 那 么 为 什么 还 需要 另 起 炉 
灶 打 造 一 个 不 完全 归属 于 JVM 阵 营 的 “异类 ”了 呢 ? 更 为 关键 的 是 ， 这 个 
初期 并 不 为 人 看 好 的 虚拟 机 ， 如 何在 夹缝 之 中 最 终 获 得 了 巨大 的 发 展 ， 
成 束 了 Android 阵 营 与 其 他 移动 操作 系统 三 分 天 下 的 局 面 呢 ? 


Dalvik 是 面向 诸如 Android 之 类 的 移动 设备 平台 的 (我 们 也 不 能 否 
认 如 今 移动 端 和 传统 PC 端的 界限 已 经 没有 那么 明显 了 ， 存 在 互相 “入 
=z AER) 。 而 这 些 平台 的 一 些 “ 老 生 常 谈 ”的 弱势 ， 就 是 内 存 小 ， 
处 理 器 能 力 弱 等 。 如 何在 这 些 特 殊 的 环境 下 解决 JVM 所 存在 的 一 些 问 
题 ， 既 是 Dalvik 所 面临 的 挑战 ， 同 时 也 为 它 提 供 了 前 所 未 有 的 机 遇 。 
Dalvik 所 做 出 的 努力 包括 但 不 限于 : 


。 多 个 Class 要 能 融合 进 一 个 Dex 文 件 中 ， 以 节省 存储 空间 ; 

Dex 文 件 可 以 在 多 个 进程 之 间 共 享 ; 

字 节 码 的 检验 操作 是 非常 耗 时 的 ， 因 而 我 们 最 好 在 应 用 程序 运行 之 
前 预先 完成 ; 

字 市 码 的 优化 是 很 有 必要 的 ， 可 以 让 程序 运行 得 更 快 ， 而 且 更 节约 





电量 消耗 ; 
。 为 了 保证 安全 性 ， 多 个 进程 间 共 享 的 代码 不 能 被 随意 编辑 (只 
BE) o 


可 以 说 Dalvik 以 其 更 贴近 于 移动 设备 的 先天 优势 ， 支 撑 了 Android 
系统 的 芷 壮 成 长 。 那 么 为 什么 后 来 Goog1le 又 要 按 弃 使 用 了 多 年 且 已 经 日 
至 成 熟 的 Dalvik， 转 而 投向 Art 的 怀抱 呢 ? 


简单 来 讲 ， 还 是 “运行 速度 ”。 

Android M+ DRE AS HERB, Hpi “A 
统 庞大 ， 运 行 慢 ”。 除 了 本 书 其 他 章节 讲解 的 “Project Butter” 5h, 
对 虚拟 机 的 大 力 改造 也 是 Android 企 图 脱离 困境 所 做 出 的 尝试 之 一 。 


于 是 Art 从 Android 4. 4 开始 ， 以 和 Dalvik 暂 时 共存 的 形态 正式 进入 
了 人 们 的 视野 。 因 为 Android 4. 4 时 Art 还 处 于 Preview 状 态 ， 所 以 


Goog le 官方 提供 了 如 下 的 声明 : 


“Art is a new Android runtime being introduced 
experimentally in the 4.4 release. This is a preview of work 
in progress in KitKat that can be turned on in Settings > 
developer options. This is available for the purpose of 
obtaining early developer and partner feedback. ” 


在 Kitkat 的 系统 设置 中 ， 我 们 可 以 找到 如 图 21-11 所 示 的 系统 选 


Use Dalvik 


Use ART 


Cancel 





全 图 21-11 子 流 选 项 


随后 Art 便 再 接骨 万， 并 在 2014 年 6 月 26 日 Gboogle 1/0 大 会 上 发 布 的 
Android Lollipop 中 正式 取代 了 Dalvik 的 位 置 。 


接 下 来 我 们 用 数据 说 话 〈 见 图 21-12 和 图 21-13) ， 看 下 Art 在 性 能 
上 相对 于 Dalvik 有 多 大 的 改善 。 


Nexus 5 


ART performance comparison 


全 图 21-12 引用 自 Google I/O 2014 Keynote 





Jason - ARTBench = | App Network Usage 


Overview interactions Devices OS versions Alerts 


Sort by Average time 


MyActivity#SpectralNormDalvik 14.5 sec 
MyActivity#SpectralNormART 4.3 sec 
MyActivity 0.152 sec 


全 图 21-13 引用 自 newrelic.com 


通过 上 述 Art 与 Dalvik 的 对 比 图 ， 我 们 可 以 看 到 前 者 在 性 能 上 确实 
有 显著 优势 。 其 中 newrel ic. com 考 核 的 是 两 个 相同 的 应 用 程序 分 别 在 局 
用 了 Art 和 Dalvik 虚 拟 机 的 GenyMotion 模 拟 器 上 启动 速度 不 难 发 
现 ， 运 行 于 Art 之 上 的 应 用 程序 快 了 3 倍 ! 





产生 这 种 差异 的 主要 原因 在 于 Dalvik 虚 拟 机 多 数 情况 下 还 是 得 通过 
解释 器 的 方式 来 执行 Dex 数 据 〈JIT， 即 Just in Time 技 术 虽 然 可 以 在 一 
定 程度 上 提高 效率 ， 但 也 仅仅 是 针对 一 小 部 分 情况 ， 作 用 有 限 ) ; 而 
Art 虚 拟 机 则 采用 了 AOT (Ahead of Time) 技术 ， 从 而 大 幅 提 高 了 性 
能 。 我 们 需要 理解 以 下 几 个 要 点 。 


e Dex 是 一 种 字 节 码 格 式 ， 是 Dalvik 虚 拟 机 中 的 可 执行 文件 。 

。 Dalv 玉 采用 了 JIT 技 术 来 将 频繁 执行 的 字 节 码 编译 成 目标 平台 上 的 机 
器 码 。JIT 区 别 于 AOT 的 一 个 主要 特征 是 ， 它 只 有 在 程序 运行 过 程 
中 才 会 将 部 分 热点 代码 编译 成 机 器 码 一 一 而 且 这 在 某 种 程度 上 也 加 
重 了 CPU 的 负担 。 

。 AOT 如 其 字面 意思 所 示 ， 会 提前 将 Java 代 码 翻 译 成 针对 目标 平台 的 
机 器 码 ， 从 而 避 开 了 JIT 的 上 述 不 足 。 当 然 ， 这 也 就 意味 着 如 果 是 
采用 了 AOT 技 术 的 ROOM 方案， 那么 Android 的 编译 时 间 将 会 有 所 增 
加 。 不 过 由 于 Android 系 统 的 构建 原本 就 比较 慢 ， 所 以 这 点 牺牲 还 
是 值得 的 。 另 外 ， 第 三 方 APK 事 先 并 不 知晓 它 将 安装 和 运行 于 哪个 
具体 的 硬件 平台 之 上 ， 所 以 ， 对 于 这 些 APK 来 说 肯定 不 能 以 AOT 的 
形式 发 布 。 不 过 ， 当 它们 在 配备 了 At 虚拟 机 的 设备 上 安装 时 ， 后 
者 会 调用 一 个 精简 的 编译 器 (dex20at) 来 完成 动态 的 “翻译 ” 工 
作 。 这 样 才 能 有 效 地 保证 第 三 方 应 用 程序 与 系统 预 装 的 应 用 程序 保 
持 同样 的 运行 效率 。 我 们 在 后 续 小 节 还 会 有 专门 的 介绍 。 

















21.1.5 _ Art 虚拟 机 整体 框架 
Art 虚 拟 机 整体 框架 如 图 21-14 所 示 。 
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全 图 21-14 虚拟 机 整体 框架 


Android 虚 拟 机 从 诞生 到 现在 ， 主 要 经 历 了 两 个 大 的 平台 ， 即 Art 和 
Dalvik。 


Dalvik 迁 移 到 Art 实 现 对 于 Android 虚 拟 机 而 言 是 一 个 很 大 的 变动 ， 
我 们 应 该 如 何 保证 二 者 之 间 的 无 缝 切换 呢 ? Google 给 出 的 解决 方案 是 将 
EMI “Batt” 无 论 是 Dalvik、Art 或 者 是 未 来 可 能 出 现 的 任何 
新 型 虚拟 机 ， 它 们 提供 的 功能 将 全 部 被 封装 在 一 个 . so 库 中 ， 并 且 对 外 
需要 暴露 JN|_GetDefaultJavaVMlnitArgs、JNI_CreateJavaVM 和 
JNI_GetCreatedJavaVMs 三 个 接口 〈 不 排除 后 续 会 增加 新 接口 ) 。 使 用 
者 〈 比 如 Zygote) 只 需要 按照 统一 的 接口 标准 就 可 以 控制 和 使 用 所 有 类 
型 的 Android 虚 拟 机 了 ， 这 样 一 来 就 很 好 地 保证 了 它们 的 无 缝 对 接 。 


组 成 Android 虚 拟 机 的 核心 子 系统 包括 但 不 限于 : Runtime, 
ClassLoader System, Execution Engine System, Heap Manager 和 GC 
系统 、JIT、JN1 环 境 等 。 


Runt ime 如 其 名 所 示 ， 代 表 了 虚拟 机 的 运行 时 态 ， 起 到 了 “大 总 
管 ”的 作用 ; JavaVM 是 对 虚拟 机 的 抽象 ， 每 个 进程 中 最 多 只 有 一 个 实例 
存在 ; JNIEnv 负 责 JNI (Java Native Interface) 机 制 ， 即 解决 Java 与 
C/C++ 等 本 地 语言 之 间 如 何 互相 通信 的 问题 。 需 要 特别 注意 的 是 ， 

JNIEnv 是 线程 相关 的 。 


和 标准 的 JVM 一 样 ， 类 加 载 器 在 Android 虚 拟 机 中 也 扮演 着 很 重要 的 
作用 。 它 又 可 以 被 细 分 为 Boot ClassLoader, System ClassLoader, 
DexClassLoader 等 。 所 有 被 加 载 的 类 和 它们 的 组 成 元 素 都 将 由 
ClassLinker 做 统一 的 管理 。 另 外 ， 为 了 实现 类 似 于 ELF 中 的 动态 延迟 加 
载 的 效果 ，Android 虚 拟 机 中 还 使 用 了 DexCache 机 制 。 我 们 在 后 续 小 节 
还 会 有 更 详细 的 分 析 。 


Execution Engine 是 虚拟 机 的 “动力 系统 ”。 除 了 字 节 码 解释 执行 
的 方式 (内 部 又 可 以 借助 于 JIT 来 实现 加 速 ) 外 ，Art 虚 拟 机 还 支持 通过 
AoT 来 直接 执行 字 节 码 编 译 而 成 的 机 器 代码 (Android N 版 本 之 前 ) 。 这 
其 中 还 涉及 很 多 细节 问题 ， 比 如 : 


。 在 什么 时 候 执 行 编译 工作 





在 M 版 本 的 Android Art 虚 拟 机 中 ，A0OT 的 编译 时 机 有 两 个 ， 即 随 
Android ROM 构 建 时 一 起 编译 ， 以 及 在 程序 安装 时 执行 编译 〈 针 对 第 三 
方 应 用 程序 的 情况 ) 。 我 们 在 后 续 内 容 中 将 通过 两 个 小 节 来 分 别 讲解 这 
两 种 编译 时 机 。 


。 编译 后 的 机 器 代码 如 何 存 储 


我 们 将 通过 一 个 小 节 来 分 析 Art 虚 拟 机 中 引入 的 新 的 存储 格式 ， 即 
0AT 文 件 〈 事 实 上 属于 ELF 文 件 的 变种 ， 因 而 我 们 在 讲解 0AT 之 前 还 会 用 
专门 的 小 节 来 为 大 家 补充 背景 知识 ) 。 


o 虚拟 机 如 何 加 载 字 节 码 及 OAT 机 器 码 


加 载 字 节 码 自然 会 涉及 ClassLoader 的 相关 知识 ; 加 载 O0AT 则 需要 用 
到 ELF 的 基础 能 力 。 我 们 将 利用 若干 小 节 的 篇 幅 来 专门 讲解 这 些 知 识 ， 
以 帮助 大 家 更 好 地 理解 Art 虚 拟 机 。 


。 如 何 执行 字 节 码 和 OAT 机 器 码 


因为 程序 中 同时 有 字 节 码 和 机 器 码 ， 那 么 在 具体 执行 时 该 如 何 抉 
择 ， 当 遇 到 需要 从 字 市 码 切 换 到 机 器 码 《〈《 反 之 亦 然 ) 的 情况 时 又 应 该 怎 
么 应 对 呢 ? 这 些 都 将 在 本 章节 得 到 详细 的 前述 。 


另外 ， 由 于 “一 股 脑 ” 地 在 程序 安装 阶段 将 Dex 转 化 为 0AT 造 成 了 一 
定 的 资源 浪费 ， 所 以 从 Android N 版 本 开始 Art 虚 拟 机 又 改变 了 之 前 的 
0AT 策 略 一 一 程序 在 安装 时 不 再 统一 执行 dex2oat， 而 改 由 根据 程序 的 实 
际 运行 情况 来 决定 有 哪些 部 分 是 需要 被 编译 成 本 地 代码 的 。 这 样 一 来 
Android N 版 本 中 的 Art 虚 拟 机 就 又 回 到 了 “三 足见 立 ” 的 时 代 ， 即 : 
Interpreter 、JIT 和 0AT 三 分 天 下 的 局 面 。 


本 章 剩余 内 容 的 编排 大 致 如 下 : 


(1) Android 虚 拟 机 的 基础 知识 ， 包 括 ELF、0AT、Dex 字 节 码 等 的 
详细 分 析 ; 


(2) Android 虚 拟 机 的 类 加 载 系统 (ClassLoader, ClassLinker 
=) ; 


(3) Android 虚 拟 机 的 堆 内 存 管理 ; 


(4) Android 虚 拟 机 的 执行 引擎 ， 这 是 本 章 的 重 中 之 重 ， 将 涵盖 
0AT、 解 释 器 和 JI1T 三 种 类 型 的 执行 方式 ; 


(5) 与 Android 虚 拟 机 相关 的 其 他 信息 ， 包 括 Native Bridge, 
JDWP、 如 何 调试 虚拟 机 等 内 容 。 


21.1.6 ， Android 应 用 程序 与 虚拟 机 


虚拟 机 只 能 算是 一 个 “和 舞台 ”， 真 正 给 观众 带 来 “视觉 盛 宣 ”的 还 
是 台 上 的 各 “主角 ” 们 ， 即 Android 应 用 程序 。 我 们 对 和 舞台 的 基本 要 求 
是 至 少 不 能 拖 演 员 们 的 “后 腿 ” 就 好 比 同一 场 话 剧 ， 不 能 因为 北京 
和 上 海 的 舞台 差异 而 导致 演出 效果 的 大 幅 降 低 “〈 甚 至 是 需要 演员 们 根据 
舞台 的 特点 来 增 、 删 、 改 戏 本 ) ， 否 则 就 是 一 个 非常 失败 的 舞台 。 平 心 
而 论 ，Android 虚 拟 机 这 个 大 舞台 虽然 一 直 在 “装修 改造 ”例如 全 新 
舞台 Art 的 出 现 ，Dalvik 的 不 断 更 新 换代 等 ) ， 但 “主角 ” 们 确实 没有 
因此 而 受到 太 多 的 影响 这 就 说 明了 Android 系 统 这 个 “大 导演 ”在 
处 理 “ 和 舞台 问题 ”上 的 确 有 其 独到 之 处 。 


那么 Android 应 用 程序 与 虚拟 机 之 间 是 如 何 保持 这 种 默契 的 呢 ? 


首先 ，Android 为 应 用 程序 的 编译 、 打 包 等 过 程 提供 了 一 系列 完整 
的 工具 支撑 ， 使 得 开发 者 可 以 不 需要 特别 关心 系统 的 底层 实现 。 


其 次 ，Android 应 用 程序 的 文件 结构 是 相对 稳定 的 。 图 21-15 所 示 的 
i a N 版 本 上 的 APK 应 用 程序 的 内 部 典型 构 
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Bb XAR un 
|_| META-INF 文件 去 
OR 文件 去 
| com 文件 去 
=| BeaconVersion.txt 5 5 文本 文档 
| AndroidManifest.xml 236,428 23,512 XML 文档 
| | resources.arsc 1,393,808 1,393,808 ARSC 文件 
| classes.dex 9,183,328 3,809,222 DEX 文件 
] classes2.dex 9,284,832 3,742,401 DEX 文件 
ia] classes3.dex 8,916,136 3,788,998 DEX 文件 








A 21-15 应 用 的 内 部 构成 


不 难 发 现 ， 对 于 开发 人 员 而 言 应 用 程序 的 编译 过 程 是 “透明 ”的 ， 
而 且 APK 中 的 可 执行 文件 也 一 直 保 持 Dex 不 变 。 这 些 都 没有 因为 Android 
虚拟 机 的 升级 换代 而 发 生变 更 。 这 样 就 保证 了 Android 应 用 程序 不 会 因 
为 “和 舞台 ”的 升级 而 需要 不 断 地 “ 改 弦 易 办 ”。 


大 家 可 能 还 有 一 个 困惑 的 地 方 一 一 Dalvik 和 Art 这 两 个 差别 巨大 的 
虚拟 机 ， 对 应 用 程序 本 身 却 没有 什么 特殊 要 求 ， 那 么 真正 的 “分 水 
It” SEMER? 我 们 可 以 先 看 一 下 Google 在 1/0 会 议 上 官方 发 布 的 一 
张 关于 APK 生 命 周期 的 示意 如 图 21-16 所 示 。 
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全 图 21-16 APK 生 命 周 期 


我 们 将 产生 APK 的 过 程 称 为 Package 阶 段 ， 与 之 相对 应 的 则 是 APK 的 
安装 阶段 。 从 图 21-16 中 可 以 清晰 地 看 到 ， 虚 拟 机 的 具体 类 型 〈 璧 如 Art 


或 Dalvik) 对 于 应 用 程序 的 Package 阶 段 是 100% 透 明 的 。 


真正 的 “分 水 岭 ” 出 现在 应 用 程序 的 安装 阶段 。 具 体 来 讲 ， 
Android 系 统 在 安装 APK 的 时 候 ， 它 需要 根据 当前 的 虚拟 机 类 型 而 做 区 分 
处 理 。 


e Dalvik 


如 果 系统 设备 配备 的 是 Dalvik 虚 拟 机 ， 那 么 在 应 用 程序 安装 阶段 需 
要 对 Dex 文 件 做 0dex 优 化 处 理 。 简 单 而 言 束 是 利用 dexopt 工 具 来 生成 
0dex 文 件 ， 不 过 还 应 该 细 分 为 如 下 几 种 情况 : 


情况 1: 打包 到 系统 ROM 中 的 APK， 即 预 装 的 应 用 程序 。 这 种 情况 下 
编译 系统 具有 绝对 主动 权 。 换 名 话说， 优化 过 程 在 编译 阶段 就 完成 了 。 
而 且 完 成 优化 操作 后 ， 我 们 可 以 选择 是 否 将 jar 〈 或 者 APK) 文件 中 的 
classes. dex 移 除 ， 再 把 0dex 放 到 与 原 jar/APK 的 同 级 目录 下 。 这 种 处 理 
方式 既 保证 了 应 用 程序 运行 时 的 效率 ， 同 时 还 节省 了 存储 空间 。 


情况 2: 针对 非 系 统 预 集成 的 第 三 方 应 用 程序 ， 会 在 安装 阶段 由 
instal ler 系 统 程序 来 负责 优化 操作 ， 最 终结 果 会 被 保存 
到 /data/Dalvik-cache 目 录 下 ， 并 以 . odexN RRS. 


情况 3: 针对 第 三 方 应 用 程序 还 有 另 一 种 可 能 性 ， 就 是 等 到 它 运 行 
时 再 执行 优化 操作 〈 这 种 方式 有 点 类 似 于 “Just in time” ) 。 不 过 由 
于 应 用 程序 并 不 一 定 具备 对 dalvik-cache 的 写 操作 权限 ， 所 以 这 种 方式 
通常 只 在 开启 了 工程 模式 的 设备 中 才 有 效果 。 


e Att 


如 果 当 前 系统 使 用 的 是 Art 虚 拟 机 ， 那 么 应 用 程序 在 安装 阶段 同样 
也 会 有 一 次 预 处 理 〈 和 Dalvik 中 的 情况 一 样 ， 如 果 是 ROM 预 置 的 APK， 那 
么 处 理 时 机 会 有 所 不 同 ) 一 一 只 不 过 Art 虚 拟 机 中 预 处 理 所 使 用 的 工具 
是 dex2oat， 输 出 的 则 是 Linux 的 标准 可 执行 文件 ， 即 ELF File. 


这 样 一 来 我 们 就 能 保证 应 用 程序 在 “无 感知 ”的 情况 下 兼容 各 种 类 
型 的 虚拟 机 了 。 


21.1.7 Procedure Call Standard for Arm Architecture (过 程 调 用 


标准 ) 


在 后 续 讲解 Art 虚 拟 机 如 何 执行 机 器 码 之 前 ， 我 们 还 有 一 个 非常 重 
要 的 基础 知识 需要 补充 ， 即 Procedure Call Standard 〈 过 程 调用 标 
准 ) 。PCS 是 汇编 程序 中 调用 和 被 调用 方 之 间 的 一 种 约定 ， 只 有 严格 遵 
守 约 定 才 能 保证 程序 的 正常 运行 。 不 同体 系 结构 下 的 PCS 会 有 些 差异 ， 
其 中 针对 ARM 的 标准 是 AAPCS (Procedure Call Standard for Arm 
Architecture) 。 相 关 标 准 的 释义 及 关系 如 下 所 示 : 


PCS Procedure Call Standard. 
AAPCS Procedure Call Standard for the ARM Architecture (this standard). 
APCS ARM Procedure Call Standard (obsolete). 
TPCS Thumb Procedure Call Standard (obsolete). 
ATPCS ARM-Thumb Procedure Call Standard (precursor to this standard). 
任何 高 级 语言 被 翻译 成 机 器 代码 后 ， 也 都 需要 遵循 PCS， 这 样 才能 
保证 它们 在 目标 平台 上 被 正确 执行 。 根 据 ARM 规 范 中 的 定义 ，Procedure 
和 Function 是 有 区 别 的 ， 如 下 所 示 : 
Procedure A routine that returns no result value. 


Function A routine that returns a result value. 


那么 Rout ine 又 应 该 如 何 理解 呢 ? 


Routine, Sub-routine: A fragment of program to which 
control can be transferred that, on completing its task, 
returns control to its caller at an instruction following the 
call. Routine is used for clarity where there are nested 
calls: a routine is the caller and a subroutine is the cal lee. 


fa) BRI, AAPS ÆSubrout ines IA LAMA Ss. Ae ae SH te 
模块 完美 协同 工作 的 基础 一 一 或 者 说 它 是 调用 者 (Calling Routine) 


和 被 调用 者 (Called Routine) 之 间 的 一 个 非常 严格 的 协议 规范 。 


我 们 知道 ， 大 多 数 硬 件 平 台 都 有 其 通用 和 特殊 用 途 的 寄存 器 ， 它 们 
将 在 CPU 执行 代码 的 过 程 中 发 挥 重要 作用 。ARM 系 统 当 然 也 不 例外 。 所 以 
要 正确 地 理解 AAPCS， 首 先 我 们 需要 对 ARM 架 构 中 的 寄存 器 ， 以 及 它们 在 
PCS 中 扮演 的 角色 有 一 个 清晰 的 认识 ， 如 图 21-17 所 示 。 


AAPCS 适 用 于 进程 中 的 单个 线程 ， 而 每 一 个 进程 (Process) MAE 
自己 的 Program State， 后 者 由 相应 的 机 器 寄存 器 和 一 些 进程 可 以 访问 
到 的 内 存 〈 如 果 不 是 该 进程 可 以 访问 到 的 范围 ， 将 产生 异常 ) 中 的 内 容 
A i 一 个 进程 中 的 内 存 区 域 可 以 大 致 分 为 
Hg 下 几 类 : 


。 代码 区 域 ; 

。 只 读 的 静态 数据 区 域 ; 
。 可 写 的 静态 数据 区 域 ; 
。 堆 区 域 ; 

。 栈 区 域 。 


Role in the procedure call standard 
pf PC | The Program Counter. 
Pf LR | The Link Register 
os | | SP Thetck Poin 
mf] P| The Intra-Procedure-call scratch register 
aes Varlable-register 8, 

lable-register 7, 


Platform register 
The meaning of this register is defined by the platform standard, 


aee Variable-register 5. 
AA | Variable register 4, 
faf | Variable register 3, 
DEIS, Variable register 2. 


EIKIN Argument’seratch register 3. 
ed fa] | Areument/result/scratch register 2. 
afaj | Argument/result/scratch register 1. 





全 图 21-17 ARM 体 系 中 的 寄存 器 以 及 它们 在 PCS 中 所 扮演 的 角色 (引用 自 ARM 公 司 的 官方 资料 
«Procedure Call Standard for the ARM® Architecture» ) 


其 中 可 写 的 静态 数据 区 域 又 可 以 细 分 为 已 初始 化 、 清 零 初始 化 和 未 
初始 化 的 数据 区 。 


另外 无 论 是 ARM 或 者 是 Thumb 指 令 集 网络 上 有 不 少 关于 这 两 种 指令 
集 之 间 的 区 别 与 联系 的 资料 ， 建 议 大 家 可 以 自行 参阅 学 习 ) ， 它 们 都 提 
供 一 条 Pr imitive 调 用 指令 ， 即 BL。 这 条 指令 会 将 PC (Program 
Counter) 寄存 器 的 下 一 个 值 保存 到 链接 寄存 器 (Link Register) H, 
并 且 把 BL 需要 跳 转 的 目标 地 址 存 入 PC 中 (另外 ， 在 Thumb 状 态 下 执行 BL 
指令 时 ，LR 中 的 Bit0 位 会 被 置 为 1; 反之 在 ARM 状 态 下 会 被 置 为 0 。 这 
样 做 的 目的 ， 一 方面 是 保证 程序 可 以 正确 地 跳 转 到 目标 地 址 中 去 执行 代 
fT i EE i 
天 的 状态 。 


还 有 一 个 与 APCS 有 关联 的 规范 是 ATPCS， 它 是 AAPCS 的 前 身 。ATPCS 
是 保证 0 语言 与 汇编 语言 可 以 混合 编程 的 关键 ， 请 大 家 重点 思考 以 下 两 
点 。 


ANAS 


(1) 参数 的 传递 
参数 的 传递 方式 有 两 种 ， 即 参数 个 数 可 变 以 及 参数 个 数 不 可 变 的 情 
Hlo 
以 参数 个 数 可 变 的 情况 为 例 ， 其 处 理 逻 辑 如 下 : 

。 将 参数 存 入 al-a4 中 ， 如 果 参 数 个 数 小 于 4， 则 只 需要 用 到 al-a3 (3 个 
BR) 或 者 a1-a2 (2 个 参数 ) 或 者 al (1 个 参数 ) ; 

。 如 果 参 数 个 数 大 于 4， 则 将 上 一 步 中 未 处 理 完 的 参数 以 逆序 的 方式 
存 入 栈 中 ， 即 剩余 的 第 1 个 参数 存 入 VAL(SP)， 第 2 个 参数 存 入 
VAL(SP)+4， 以 此 类 推 。 

(2) 返回 值 的 处 理 


疯 数 的 返回 值 有 可 能 是 Integer 或 者 Floating-Point， 而 且 所 占用 
的 空间 可 能 是 1 个 或 者 多 个 Words。 以 Integer 的 情况 为 例 ， 返 回 值 的 具 


体 处 理 策 略 是 : 


e 如 果 是 1-wotd value， 则 保存 在 al 中 ; 

e 如 果 是 2-4 wotds， 则 分 别 对 应 al-a2、al-a3、al-a4; 

。 对 于 需要 占用 更 多 words 的 情况 , 则 需要 通过 额外 的 内 存 地 址 参数 来 
传递 返回 值 。 


在 后 续 小 节 的 学 习 过 程 中 ， 我 们 会 发 现 Android 虚 拟 机 并 没有 完全 
遵循 AAPCS， 而 是 在 它 的 基础 上 做 了 适当 的 定制 〈 例 如 用 r9 寄 存 器 来 记 
录 Thread 信 息 ) 。 请 大 家 结合 起 来 阅读 理解 。 


21.1.8 C++ 11 标 准 中 的 新 特性 


Android 虚 拟 机 子 系统 主要 是 用 C++ 和 汇编 语言 编写 完成 的 ， 其 中 运 
用 了 大 量 的 C++ 11 特 性 。 本 小 节 我 们 主要 讲解 Ct+ 11 相 对 于 C++ 语言 老 
版 本 标准 的 一 些 差 异 特性 ， 为 大 家 阅读 虚拟 机 的 代码 实现 扫 清 障碍 。 


21.1.8.1 ”智能 指针 unique_ptr 


我 们 在 本 书 操作 系统 基础 知识 章节 已 经 详细 分 析 过 Goog |e 提 供 的 智 
能 指针 方案 及 它 的 基本 原理 了 ， 可 以 说 它 和 Android 庶 拟 机 内 部 使 用 的 
C++ 中 的 智能 指针 具有 “异曲同工 ”之 效 。 


C++ 中 共有 4 种 类 型 的 智能 指针 ， 即 : auto_ptr、unique_ptr、 
shared_ptr 和 weak_ptr。 第 一 种 auto_ptr 在 C++11 中 已 经 被 据 弃 了 ， 大 
家 可 以 不 用 再 做 进一步 了 解 。 另 外 几 种 在 Android 虚 拟 机 中 使 用 频率 最 
高 的 则 是 unique_ptr， 因 而 我 们 作为 本 小 节 的 重点 来 做 讲解 。 


顾名思义 ，unique_ptr 说 明 该 智能 指针 所 管理 的 对 象 只 允许 有 一 个 
引用 ， 与 之 相对 的 是 shared_ptr 。 当 unique_ptr 自 身 被 销毁 的 时 候 ， 它 
所 管理 的 对 象 也 会 被 同步 释放 回收 ， 以 避免 内 存 泄 露 的 发 生 。 

unique_ptr 中 包含 的 主要 成 员 函 数 如 表 21-2 所 示 。 


表 21-2 主要 成 员 函 数 


Member | Description | 





functions 
beoe | 为 智能 指针 管理 的 对 象 赋值 





获取 智能 指针 所 管理 的 对 象 ， 返 回 值 有 可 能 是 
nullptr 要 特别 注意 执行 get 函 数 后 ，unique_ptr 仍 

get 拥有 对 目标 对 象 的 管理 权 ， 因 而 调用 者 不 能 将 
pao ees ace 否则 会 出 现 
HIR 





el 释放 智能 指针 所 管理 的 对 象 ， 意 味 着 unique_ptr 
将 失去 对 目标 对 象 的 管理 权 





下 面 举 一 个 简单 的 例子 来 说 明 unique_ptr 的 用 法 与 作用 : 


void test_uniqueptr() 


TEST_XX * u_ptr = new TEST_XX; 


delete u_ptr; 


上 述 函数 中 的 TEXT_Xx 对 象 的 释放 完全 取决 于 最 后 一 个 delete 语 名 
的 执行 ， 属 于 不 可 靠 的 方式 : 
void test_uniqueptr2() 
{ 

unique_ptr<TEST_XX> u_ptr(new TEST_XX); 


delete u_ptr; 


当 u_ptr 对 象 的 生命 周期 结束 的 时 候 ， 其 析 构 函数 必然 会 被 调用 ， 
同时 被 销毁 的 还 包括 TEST_XX 对 象 ， 从 而 避免 了 内 存 泄露 的 情况 。 


当然 ， 这 只 是 unique_ptr 的 一 个 典型 使 用 场景 。 大 家 可 以 与 后 续 小 
节 中 的 虚拟 机 源码 分 析 结 合 起 来 学 习 。 


21.1.8.2 ”类 型 自动 推导 auto 


旧版 本 的 C++ 规范 要 求 源码 中 必须 显 式 声明 各 个 变量 的 类 型 ， 这 就 
是 我 们 所 说 的 强 语言 行为 。 而 C++ 11 中 改变 了 这 种 状态 ， 它 允许 开发 人 
员 使 用 auto 来 代替 变量 的 类 型 声明 ， 然 后 由 系统 来 自动 推导 出 变量 的 真 
实 类 型 。 相 信 这 种 能 力 大 家 在 脚本 语言 中 已 经 “见怪 不 怪 ” 了 一 一 这 也 
从 侧面 说 明了 C++ 为 了 提升 开发 者 便捷 性 ， 借 鉴 和 了 吸收 了 其 他 不 少 编程 
语言 的 优秀 特性 。 


下 面 是 使 用 auto 的 一 个 小 范例 ， 供 大 家 参考 : 


auto a 
auto c ae 
auto s("hello"); 


值得 一 提 的 是 ，Cr+ 11 提 供 的 类 型 自动 推导 功能 事实 上 是 由 编译 器 
完成 的 ， 这 样 一 来 就 可 以 保证 程序 在 运行 过 程 中 的 性 能 不 受到 影响 了 。 
不 过 这 同时 也 提醒 我 们 ， 使 用 auto 变 量 的 一 个 前 提 条 件 是 能 提供 足够 的 
言 息 来 供 编译 器 完成 自动 推导 ， 例 如 给 变量 做 初始 化 。 而 诸如 下 面 这 样 


的 场景 显然 会 导致 编译 错误 : 


auto m; 


10; 


21.1.8.3 空 指针 nullptt 


在 C++ 旧版 本 的 规范 中 ， 开 发 人 员 已 经 习惯 于 通过 NULL 来 初始 化 一 
个 空 指针 了 。NULL 通 常会 被 定义 为 (void *) 0 或 者 0， 范 例如 下 所 示 : 


#ifndef NULL 
#ifdef _ cplusplus 
#define NULL 0 
#else 


#define NULL ((void *)0) 
#endif 
#endif 


NULL 的 不 足 则 在 于 它 在 菜 些 场景 下 有 可 能 会 产生 二 义 性 。 
举 一 个 例子 来 说 ， 下 面 是 两 个 重 载 函 数 : 


void my_function(float *); 
void my_function(int); 


如 果 我 们 希望 调用 的 是 第 一 个 函数 (float*) ， 而 且 传递 的 参数 为 
空 指针 ， 那 么 在 以 往 的 表达 方法 中 ， 就 变 成 了 : 
my_function (NULL) ; 


由 于 NULL 本 身 也 是 0〈 属 于 int 类 型 ) ， 所 以 上 述 的 函数 调用 并 没有 
办 法 确定 程序 的 “真实 意图 ”一 一 二 义 性 就 此 产生 。 


为 了 避免 不 必要 的 麻烦 ，C++ 11 标 准 中 引入 了 关键 字 nul1lptr 来 解 
决 类 似 的 问题 。 


它 的 典型 范例 如 下 : 
ArtMethod* method_ = nullptr; 
if (r == nullptr) return 0; 


21.1.8.4 原子 操作 和 原子 类 型 


原子 操作 简单 来 讲 是 指 “A sequence of one or more machine 
instructions that are executed sequentially, without 


interruption”， 即 不 可 中 断 的 一 个 或 多 个 机 器 指令 的 执行 过 程 。 


原子 操作 的 实现 和 具体 的 硬件 平台 有 直接 关系 。 单 处 理 器 的 情况 
下 ， 由 于 中 断 只 能 发 生 在 指令 之 间 ， 所 以 单条 指令 可 以 完成 的 操作 都 可 
以 被 认为 是 原子 的 。 多 处 理 器 的 情况 则 会 更 复杂 一 些 ， 因 为 我 们 很 难保 
证 多 个 处 理 器 的 具体 执行 时 间 。 通 常 我 们 会 有 如 下 几 种 典型 的 方法 来 解 
决 这 类 问题 。 


。 利用 总 线 锁 来 实现 原子 操作 


总 线 锁 实际 上 是 处 理 器 必 片 提供 的 一 个 LOCK 信 号 。 当 有 对 个 处 理 器 输 
出 这 一 信号 时 ， 总 线 会 傈 证 暂时 不 处 理 其 他 处 理 器 的 请 求 ， 从 而 满足 单 
个 处 理 器 独占 内 存 的 要 求 。 


。 利用 缓存 锁 来 实现 原子 操作 。 


总 线 锁 在 工作 期 间 内 ， 其 他 处 理 器 与 内 存 之 间 的 通信 都 被 “ 截 
断 ” 了 ， 显 然 这 样 的 做 法 相当 “霸道 ”， 人 性 价 比 不 高 。 缓 存 锁 可 以 在 某 
些 场景 下 代替 总 线 锁 ， 确保 在 完成 同样 功能 的 情况 下 降低 开销 。 


原子 操作 的 具体 硬件 实现 方式 有 很 多 ， 为 此 C++ 11 标 准 中 提供 了 专 
门 的 软件 “封冻 ”来 帮助 开发 人 员 屏 向 这 些 硬件 上 的 差异 性 ， 同 时 还 能 
更 方便 地 解决 部 分 同步 问题 。 


以 出 售 火车 票 为 例 ， 假 设 余 票数 量 为 count， 那 么 传统 的 做 法 需要 
通过 互 斥 锁 等 手段 才能 保证 正确 性 。 而 在 C++ 11 中 ， 我 们 可 以 直接 将 
count 声 明 为 原子 类 型 (如 atomic_int) ， 然 后 资源 竞争 的 问题 就 可 以 
交 由 编译 器 来 解决 了 。 提 供 这 个 特性 的 头 文件 是 <atomic>， 其 中 常见 的 
数据 类 型 都 有 它们 对 应 的 原子 类 型 ， 壁 如 atomic_bool|、atomic_char、 
atomic schar (signed char) 、atomic uchar (unsigned char) 、 
atomic short、 atomic_ushort (unsigned short) 、atomic_int、 
atomic uint (unsigned int) 等 : 


#include <atomic> 
atomic_int count(10000); 


除 此 之 外 ，C++ 11 标 准 还 提供 了 模板 类 atomic 来 帮助 大 家 扩展 自己 
的 “原子 类 型 ”。Art 虚 拟 机 中 的 Atomic 就 是 通过 这 种 方式 实现 的 ， 如 
下 所 示 : 
/*art/runtime/atomic.h*/ 
template<typename T> 
class PACKED(sizeof(T)) Atomic : public std::atomic<T> { 
public: 
Atomic<T>() : std::atomic<T>(0) { } 


explicit Atomic<T>(T value) : std::atomic<T>(value) { } 


c++ 提供 的 原子 操作 在 运行 效率 上 做 了 不 少 优 化 ， 因 而 在 Art 虚 拟 机 


中 使 用 比较 多 。 
21.1.8.5 Lambda 


Lambda 是 希腊 字母 的 第 11 位 (人 入 ， 国 际 音 标 /' 1amde/) , WE 
命名 的 表达 式 在 不 少 编程 语言 中 都 存在 ， 例如 C++、 Python、 Java (M8 
开始 ) | JavaScript. 


不 过 不 同 编 程 语言 (甚至 是 同 种 语言 不 同 编译 器 ) 对 于 Lambda 的 具 
体 表达 方式 存在 一 定 的 差异 。 在 C++ 11 标 准 中 ，Lambda 遵 从 如 下 的 格 


式 : 


[capture](parameters) mutable exception-> return_type { function 


capture: “捕获 ”列表 ， 它 同时 也 是 Lambda 表 达 式 的 起 始 标志 ， 
用 于 指示 可 以 使 用 的 上 下 文 变量 。 常 见 的 范例 如 下 所 示 : 


[] 捕获 列表 为 空 的 情况 下 ， 所 有 外 部 变量 在 Lambda 表 达 式 
中 都 不 可 以 访问 ; 


&y] ”表示 x 变量 以 值 传递 的 方式 捕获 ， 而 y 变 量 以 引用 的 方式 
获 ; 


[&] 表示 所 有 外 部 变量 都 以 引用 的 方式 捕获 ; 

[=] 表示 所 有 外 部 变量 都 以 值 传递 的 方式 捕获 。 
parameters: 参数 列表 ， 这 和 普通 函数 的 定义 是 类 似 的 。 
exception: 此 表达 式 是 否 会 抛 出 异常 ， 以 及 异常 的 类 型 


return_type: 返回 值 类 型 ， 即 Lambda 表 达 式 的 返回 结果 的 数据 类 
型 。 


function_body: lambda 表 达 式 的 内 部 实现 。 它 除了 可 以 像 普通 函 
2 样 使 用 Parameters 外 ， 还 可 以 根据 Capture 中 的 设置 来 访问 外 部 变 


ma 


下 面 我 们 举 个 例子 来 帮助 大 家 进一步 理解 Lambda: 


std::vector<int> List{ 1, 2, 3, 4, 5 }; 

int total = 0; 

int value = 5; 

std::for_each(begin(List), end(List), [&, value, this](int x) { 
total += x * value * this->XXX_FUNC(); 

}); 


上 述 代码 段 实现 的 是 列表 的 遍历 功能 。 从 [] 列 表 可 以 看 出 除 value 
和 thi s 指 针 以 值 传递 的 方式 来 捕获 之 外 ， 其 余 变量 都 以 引用 的 方式 传 
递 。 值 传递 意味 着 在 Lambda 表 达 式 定义 时 该 变量 的 值 就 已 经 被 确定 下 来 
了 ， 而 引用 传递 则 是 指 Lambda 被 调用 时 才 会 确定 变量 的 值 ; 参数 列表 中 
只 有 x 个 变量 。 因 为 这 个 Lambda 没 有 返回 值 ， 此 种 情况 下 人 允许 省 略 掉 “- 
5a 


天 于 Lambda 还 有 很 多 应 用 场景 ， 建 议 大 家 可 以 参阅 相关 资料 做 进 一 
步 了 解 ， 限 于 篇 幅 我 们 暂 不 做 过 多 阐述 。 


21.2 Android 虚拟 机 核心 文件 格式 Dex 字 节 码 


Java 最 重要 的 特性 是 “Write once, run anywhere” (WORA) ， 这 
也 是 它 得 以 快速 发 展 的 原始 驱动 力 。 不 过 要 做 到 这 一 点 并 不 容易 ，Java 
首先 要 解决 的 棘手 问题 就 是 如 何 让 这 门 高 级 语言 所 编写 的 代码 让 形态 各 
异 的 目标 平台 们 所 “理解 ”。 


字 节 码 就 是 上 述 问题 思考 的 结果 。 


字 节 码 又 被 称 为 “P-Code” (Portable Code) ， 是 一 种 “ 承 上 启 
下 ”的 指令 集 。“ 承 上 ”是 指 Java 代 码 ， 而 “局 下 ”针对 的 是 具体 的 硬 
件 平台 。 在 大 部 分 情况 下 ，Java 代 码 在 编译 阶段 首先 会 被 转换 为 
Bytecode， 然 后 在 运行 过 程 中 再 通过 Interpreter (解释 器 〉 来 解释 执 
行 。 不 过 需要 大 家 特别 注意 的 是 ， 由 于 现在 大 部 分 的 虚拟 机 都 支持 
JIT (Just In Time) 功能 ， 所 以 并 非 所 有 场景 下 都 需要 解释 器 的 参 
与 。 示 意图 如 图 21-18 所 示 。 


Android 中 的 字 节 码 和 标准 JDK 相 比 有 其 特殊 之 处 。 根 据 Goog le 提供 
的 官方 文档 ，Android 在 设计 Bytecode 时 所 采用 的 核心 原则 如 下 。 


(1) Bytecode 的 机 器 模型 (Machine Model) 和 调用 规范 
(Calling Conventions) 应 该 尽 可 能 模拟 通用 的 真实 机 器 框架 ， 以 及 
C-Style 的 调用 规范 。 


Dalvik 是 基于 寄存 器 的 (Register-Based。 可 以 参见 前 面 小 节 的 分 
析 ) 虚拟 机 ， 而 且 每 帧 大 小 在 创建 时 是 固定 的 “ 帧 ”包含 了 一 定数 
量 的 寄存 器 值 〈 取 决 于 当前 的 具体 函数 ) 以 及 执行 函数 时 所 需 的 额外 信 
息 ， 比 如 程序 计数 器 等 。 


(2) 指令 的 存储 单位 采用 的 是 16bit 的 无 符号 数 。 


(3) Strings、types、fields 及 methods 有 各 自 独 立 的 索引 常量 值 
(Constant Pools) ， 这 点 和 Java 规 范 中 的 字 节 码 是 类 似 的 。 


(4) 从 经 验 来 看 ， 一 个 函数 所 需 的 寄存 器 数量 大 致 在 8 一 16 个 ， 所 
以 很 多 指令 都 被 限制 只 能 访问 16 个 寄存 器 〈 不 过 这 并 不 是 绝对 的 ， 
Dalvik 理 论 上 可 以 访问 的 虚拟 寡 存 器 数量 可 以 达到 65536) 。 








(5) 有 一 些 “ 伪 指令 ”被 用 于 承载 不 定 长 度 的 数据 ， 这 些 指令 在 
常规 执行 流 中 是 不 应 该 出 现 的 。 同 时 ， 它 们 需要 做 到 4 字 节 对 齐 。 为 了 
达到 这 一 目标 ， 在 茶 些 情况 下 需要 我 们 添加 额外 的 nop 指 令 。 


AENA BITNA 


Class Loader 


Java Bytecode Operation System 





全 图 21-18 Java 编译 和 运行 时 简 图 
表 21-3 是 对 Android 中 常用 字 节 码 的 释义 ， 供 大 家 参考 学 习 。 


表 21-3 ”Android 虚 拟 机 常用 字 节 码 释 义 


Aix | a 

ig UF | 将 源 寄存 器 的 内 容 

多 到 目标 寄存 器 

move vA, vB B: 源 寄存 器 转移 到 目标 寄存 器 
( Abits ) 


move/from16 


VAA, vVBBBB 


move/16 vAAAA, 
VBBBB 


_ A SE 
return-object VAA ae 数 由 one ME 


P ti ZEN , G a, 
27 11x 人 bearing 寄 存 | 抛 出 指定 的 异常 事 





| | | (8bits) 有 


28 10t goto +AA 





if-test vA, vB, 


男 外 ，Android 编 译 Java 的 过 程 也 与 JDK 中 的 处 理 方式 存在 差异 。 它 
首先 会 将 Java 代 码 编译 成 . class 文 件 ， 然 后 再 利用 Android 系 统 提供 的 
dx 工具 将 其 进一步 转换 为 . dex。 换 言 之 Android 系 统 并 没有 直接 使 

么 Dex 与 JDK 标 准 的 Class 格 式 文件 相 比 有 什么 区 别 
Ne? 如 图 21-19 所 示 。 
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全 图 21-19 ”Dex 文 件 格式 与 Class 文 件 格式 的 对 比 


关于 class 文件 格式 的 详细 介绍 信息 ， 大 家 可 以 查阅 0racle 的 官方 


http://docs.oracle.com/javase/specs/ 


由 图 21-19 可 知 ， 一 个 Android 应 用 程序 中 通常 只 包含 一 个 Dex 文 件 
GES: 这 并 不 是 绝对 的 ， 和 譬如 在 函数 数量 超过 限制 时 Dex 需 要 做 分 包 
处 理 ) 。 这 和 标准 Java 规 范 中 的 做 法 是 不 一 样 的 ， 后 者 会 在 一 个 Jar 包 


中 存储 若干 个 Class 文 件 ， 并 分 别管 理 。 这 就 意味 着 Dx 工 具 需 要 对 各 
Class 进 行 统一 处 理 ， 然 后 将 内 容 “ 糙 合 ” 进 最 终 的 Dex 文 件 中 。 


Dex 文 件 中 的 各 主要 域 的 释义 如 表 21-4 所 示 。 
表 21-4 ”主要 域 


本 Dex 文 件 中 所 使 用 的 字符 串 列 
表 ， 不 允许 有 重复 项 








本 Dex 文 件 中 所 使 用 的 数据 类 型 列 
表 ， 不 允许 有 重复 项 





本 Dex 文 件 中 所 引用 的 各 种 域 
(field) 的 列表 ， 不 允许 有 重复 项 





method_ idslmethod_ id_item[j oe HA KA 


类 定义 列表 。 父 类 
(superclass) 、 接 口 (interface) 
在 列表 中 的 位 置 需要 比 子 类 靠 前 





i ea | 用 于 文 撑 上 述 所 有 列表 的 相关 数据 
pane fie | 链接 文件 所 使 用 的 数据 








下 面 我 们 通过 解析 一 个 具体 的 Dex 文 件 来 加 深 大 家 的 理解 。 
(1) 范例 源码 是 由 两 个 类 组 成 的 ， 如 下 所 示 : 


© com.example.myapp 
©) ù Calculator 
CH MyActivity 


(2) 其 中 MyActivity 中 的 实现 如 下 : 
package com.example.myapp; 


import android.app.Activity; 
import android.os.Bundle; 


public class MyActivity extends Activity { 
@Override 
public void onCreate(Bundle savedInstanceState) { 
super .onCreate(savediInstanceState) ; 
setContentView(R.layout.main); 
Calculator cal = new Calculator(); 
System.out.printin("add="+cal.add()); 


(3) Calculator 的 实现 如 下 : 
package com.example.myapp; 


public class Calculator { 
public int add() 
{ 
int a=400; 
int b=200; 
int c= a+b; 
return c; 


我 们 按照 常规 的 Android 应 用 程序 编译 流程 来 生成 最 终 的 APK 文 件 ， 
然后 再 从 后 者 中 提取 出 classes. dex 文 件 。 紧 接着 我 们 利用 Andro id 官方 
提供 的 dexdump 工 具 来 解析 它 的 内 部 构造 ， 命 令 如 下 : 


dexdump -f classes.dex >example 
我 们 从 上 述 命令 的 输出 结果 中 截取 部 分 内 容 ， 如 下 所 示 : 
Processing 'classes.dex'... 


Opened 'classes.dex', DEX version '035' 
DEX file header: 


magic : 'dex\n035\0' 
checksum : 05378d39 
signature : 6927...8403 
file_size : 2700 
header_size : 112 

link_size : 0 

link_off : © (0x000000) 
string_ids_size : 56 
string_ids_off : 112 (0x000070) 
type_ids_size : 21 
type_ids_off : 336 (0x000150) 
proto_ids_size : 8 
proto_ids_off : 420 (0x0001a4 ) 
field_ids_size “5 

field _ ids off : 516 (0x000204) 
method_ids_size : 19 
method_ids_off : 556 (0x00022c) 
class_defs_size : 8 
class_defs_off : 708 (0x0002c4) 
data_size : 1736 

data_off : 964 (0x0003c4) 


Dex 的 文件 头 记 录 的 是 Magic 数 ( “dex\n035\0” ) 、 校 验 码 、 签 
名 、 总 文件 大 小 、 各 个 区 段 所 占 的 空间 大 小 以 及 它们 的 起 始 地 址 在 本 文 
件 中 的 偏 移 量 等 一 系列 信息 。 


接 下 来 我 们 以 strings_ids 和 method_ids 为 例 ， 讲 解 如 何 读 取 Dex 中 
的 这 些 字 段 数据 。 


(1) string_ids 


上 述 dump 结 果 中 显示 的 string_ids_off 值 为 112 (0x70) 。 细 心 的 
读者 一 定 注意 到 了 ， 文 件 头 所 占 的 大 小 亦 是 112 一 一 意味 着 String 这 一 
区 段 是 紧 挨 着 Header 存 储 的 。0x70 处 的 数据 如 下 所 示 : 


00000070h: A6 05 00 00 AE 05 00 00 CO 05 00 00 Di O5 00 00 


由 string_ids_size 我 们 知道 ，String_ids 所 包含 的 项 目 总 数 是 
56， 而 且 每 一 个 item 都 遵循 string_id_item 数 据 结构 〈Dex 文 件 格式 相 
关 的 所 有 数据 结构 都 可 以 在 Android 官 网 上 找到 详细 释义 : 
https://source. android. com/devices/tech/dalvik/dex- 
format. html) ， 如 图 21-20 所 示 。 


string_id_item 
appears in the string_ids section 
alignment: 4 bytes 


re | Feat [Da 


string_data_off uint offset from the start of the file to the string data for this item. The offset 
should be to a location in the data section, and the data should be in the 
format specified by "string_data_item" below. There is no alignment 
requirement for the offset. 


全 图 21-20 Dex 文 件 的 格式 


每 一 个 string_id_item 所 占 的 空间 大 小 也 是 固定 的 ， 为 4Byte， 并 
且 按 照 高 位 在 后 的 顺序 进行 存储 。 以 Calculator 场 景 中 String_ids 的 第 
一 项 “0xA605 0000” 为 例 ， 它 实际 对 应 的 值 就 是 “0x0000 05A6”。 这 
个 地 址 指示 的 是 用 于 摘 述 该 String 具 体 数据 的 string_data_item 在 Dex 
文件 中 的 偏 移 量 ， 如 下 所 示 : 


000005a0h: 01 00 00 00 02 00 He 3C 69 GE 69 74 3E 00 10 42 3 ...... Exinit>..B 


String_data_item 也 是 一 个 固定 的 数据 结构 ， 如 图 21-21 所 示 。 


string_data_item 
appears in the data section 


alignment: none (byte-aligned) 


0 


utf16_size uleb128 size of this string, in UTF-16 code units (which is the “string length" in many 
systems). That is, this is the decoded length of the string. (The encoded length is 
implied by the position of the 0 byte.) 


data ubyte[] a series of MUTF-8 code units (a.k.a. octets, a.k.a. bytes) followed by a byte of 
value 0. See "MUTF-8 (Modified UTF-8) Encoding" above for details and discussion 
about the data format. 
Note: It is acceptable to have a string which includes (the encoded form of) 
UTF-16 surrogate code units (that is, U+d800 ... U+dfff) either in isolation or 
out-of-order with respect to the usual encoding of Unicode into UTF-16. It is up 
to higher-level uses of strings to reject such invalid encodings, if appropriate. 


全 图 21-21 stting_data_item 数 据 结构 解析 


对 照 string_data_item 的 数据 格式 ， 不 难得 出 0x05A6 这 个 地 址 所 表 
示 的 字符 串 大 小 为 6， 具 体 指 的 是 ““init>” 这 个 函数 名 。 


(2) method_ids 


Method 和 String 的 处 理 过 程 也 是 类 似 的 ， 只 不 过 面 对 的 数据 结构 有 
所 区 列 。 


Method_ids 是 一 个 method_id_item[] 数 组 ， 后 者 对 应 的 数据 结构 如 
图 21-22 所 示 。 


method_id_item 
appears in the method_ids section 


alignment: 4 bytes 


A oee 


class_idx  ushort index into the type_ids list for the definer of this method. This must be a class or 
array type, and not a primitive type. 


proto_idx  ushort index into the proto_ids list for the prototype of this method 


name_idx uint index into the string_ids list for the name of this method. The string must conform 
to the syntax for MemberName, defined above. 


A 21-22 method_idq_item 数 据 结构 解析 


每 一 个 method_id_item 占 用 4 个 字 节 空间 。 在 Calculator 这 个 范例 
中 ，method_ids 的 偏 移 地 址 是 556 (0x00022c) ， 我 们 截取 部 分 数据 显 
示 如 图 21-23 所 示 。 


00000220h: 24 00 00 00 12 00 OE 00 30 00 00 00 01 00 04 00 
00000230h: 00 00 00 00 01 00 06 00 2F 00 00 00 03 00 04 00 
00000240h: 00 00 00 00 04 00 04 00 00 00 00 00 BER 

00000250h: £ bem 05 00 04 00 00 00 00 00 05 00 06 00 





全 图 21-23 数据 


我 们 随机 选取 第 4 个 函数 来 分 析 ， 对 应 的 数据 是 “0x0400 0000 
2200 0000”。 其 中 class_idx 〈 此 函数 所 属 的 Class) 的 值 是 0x04， 即 
type_ids 数 组 的 第 4 项 ; proto idx 〈 此 函数 的 原型 ) 的 值 是 “0x00”， 
即 proto_ids 的 第 0 项 ; 最 后 ，name_idx (此 函数 的 名 称 ) 指向 的 是 
string_ids 的 第 0x22 项 ， 由 前 述 的 讲解 不 难 推算 出 具体 值 是 “add”。 


那么 函数 的 具体 实现 保存 在 哪个 区 域 呢 ? 


答案 是 class_defs。 具 体 而 言 ，class_defs 是 由 class def_item[] 
组 成 的 。 而 c1ass_def_item 数 据 结构 中 又 有 一 个 class_data_off 偏 移 量 
E E clea re ees 
和 域 。 


在 Android 虚 拟 机 规范 中 ， 洱 数 会 被 细 分 为 Virtual、Direct、 


Super 等 多 种 类 型 ， 而 且 调用 这 些 函 数 所 使 用 的 字 节 码 指令 也 是 不 同 
的 。 如 表 21-5 所 示 。 


表 21-5 Android 虚拟 机 中 的 函数 种 类 及 调用 指令 


这 是 最 常见 的 函数 类 型 。 之 所 以 冠 之 
以 “Virtual”， 是 因为 这 类 函数 是 可 以 被 重 载 
6e: 的 。 换 名 话说， 除了 private、static 和 
Virtual linvoke- lfinal (还 有 构造 函数 ) 等 之 外 的 函数 通常 都 





virtual ”| 属于 virtual 类 型 。 处 理 这 类 函数 时 需要 特别 
考虑 VTable 的 实现 ， 所 以 在 执行 效率 上 相对 
于 其 他 函数 类 型 会 稍微 低 一 些 


即 Superclass 的 Virtual Method 


Direct jinvoke- 站 不 能 和 AS PRL 
direct 

Static invoke- 
static 

Es 





以 “add” 消 数 为 例 ， 它 编译 生成 的 字 节 码 如 下 : 


Virtual methods - 


#0 : (in Lcom/example/myapp/Calculator; ) 
name : 'add' 
type >: '()I' 
access : @x0001 (PUBLIC) 
code - 
registers : 4 
ins : 1 
outs : 0 
insns size : 7 16-bit code units 
00042c: | [00042c] com.example.myapp 
00043c: 1300 9001 |0000: const/16 vO, #int 40 
000440: 1301 c800 |0002: const/16 vi, #int 20 
000444: 9002 0001 |0004: add-int v2, vO, vi 
000448: 0f02 |0006: return v2 
同时 onCreate 中 调用 add 函 数 对 应 的 字 节 码 实现 如 下 : 
0004a8: 6e10 0400 0000 |OO1a: invoke-virtual {v0}, 
Lcom/example/myapp/Calculator; .add : 
0004ae: 0a03 1001d: move-result v3 ###1% K BOA 


因为 add 卫 数 属于 Calculator 这 个 类 ， 所 以 invoke-virtual 中 的 人 参 
数 是 Lcom/example/myapp /Calculator。 


为 了 支持 多 态 性 ， 虚 拟 机 会 为 类 〈 有 需要 的 情况 下 ) 提供 两 个 特殊 
的 表 ， 即 VTable 和 1Table。 

下 面 是 一 个 简单 的 范例 : 
class A 

public void Method1(){ 


} 
public void Method2(String a){ 


} 


Class B extends A{ 
public void Method1(){ 


t 
public void Method3(){ 
Method1(); 


} 


子 类 在 构建 自己 的 VTable 时 ， 首 先 会 完整 复制 父 类 的 VTable， 然 后 
再 以 此 为 基础 替换 生成 自己 的 虚拟 函数 表 。 在 上 面 这 个 例子 中 ，Class 


A. Method1 


A. Method2 


因为 Class B 继 承 自 Class A， 并 且 重 载 了 Method1， 所 以 它 的 
VTab le 就 变 为 : 


B. Method1 
A. Method2 
B. Method3 


这 样 一 来 ，B. Method3 () 在 运行 阶段 通过 上 述 虚 拟 表 就 可 以 查 出 其 
所 调用 的 Method1 对 应 的 最 终 函 数 是 B. Method1; 而 假如 Class BRAE 
载 Method1， 那 么 它 的 VTable 中 第 1 个 函数 就 仍然 是 A. Method1， 从 而 产 
生 不 一 样 的 效果 。 


那么 1Table 又 是 什么 呢 ， 为 什么 除了 VTable 外 还 需要 一 个 ITable? 
我 们 知道 ，Java 语 言 中 虽然 只 允许 继承 一 个 父 类 ， 但 却 可 以 实现 多 个 接 
口 。 换 名 话说 ，VTable 并 没有 办 法 解决 所 有 的 多 态 问题 ， 因 而 虚拟 机 又 
引入 了 1Table 来 处 理 这 种 情况 。 我 们 在 后 续 小 节 分 析 Art 的 内 部 实现 时 
还 有 针对 1Table 的 更 多 讲解 ， 建 议 大 家 结合 起 来 阅读 。 





21.3 ”Android 虚 拟 机 核心 文件 格式 一 一 可 执行 文件 的 基石 ELF 


Android 对 于 Linux 的 借鉴 并 不 仅仅 体现 在 操作 系统 层面 ， 在 很 多 技 
术 实 现 上 也 是 如 此 。 以 Android MM 版 本 中 的 Art 虚 拟 机 为 例 ， 其 最 大 的 特 
点 就 是 通过 dex2oat 将 Dex 预 编译 成 包含 了 机 器 指令 的 oat 文 件 ， 从 而 显 
著 提升 了 程序 的 执行 效率 。 而 oat 文 件 本 身 并 不 是 一 个 新 事物 ， 它 是 
Android 系 统 基于 Linux 中 的 可 执行 文件 格式 一 一 ELF 所 做 的 扩展 。 
Android 系 统 既 遵循 了 ELF 文 件 协议 ， 同 时 还 根据 Art 虚 拟 机 的 特点 和 具 
体 需求 “另辟蹊径 ”， 针 对 ELF 做 了 巧妙 的 扩展 ， 可 谓 是 “ 鱼 和 能 掌 兼 


V EE] 
F o 


本 小 节 中 我 们 将 讲解 ELF 的 基础 知识 ， 从 而 为 大 家 后 续 学 习 oat 和 程 
序 的 执行 过 程 扫 清 障碍 。 如 果 读 者 对 ELF 已 经 有 深入 了 解 ， 那 么 可 以 选 
择 跳 过 本 小 节 内 容 。 


21.3.1 ”ELF 文件 格式 


Executable and Linkable Format (ELF)， 最 初 是 由 UN1X 系 统 实验 
室 作 为 《Application Binary Interface Specification》 的 一 个 核心 
组 成 元 素 发 布 的 (可 以 参考 | 阅读 https://refspecs. | inuxfoundation. 
org/elf/gabi41. pdf) ， 随 后 又 被 整合 到 《Tool Interface Standard 
(TIS) Portable Formats Specification》 规 范 中 。TIS 在 1993 年 和 
1995 年 分 别 发 布 了 v1. 1 和 v1. 2 两 个 版 本 的 ELF 规 范 。 建 议 读者 可 以 在 本 
小 节 的 基础 上 再 自行 查阅 1. 2 版 本 ， 以 便 对 ELF 有 更 全 面 的 认识 。 下 面 是 
Linux 基 金 会 提供 的 ELF 规 范 的 下 载 地 址 : 


https://refspecs.linuxfoundation.org/elf/elf.pdf 


另外 ，TIS 和 AB1 中 所 包含 的 ELF 规 范 是 通用 性 质 的 ， 各 芯片 处 理 器 
厂商 还 会 在 此 基础 上 融入 与 Processor 相 关 的 具体 信息 。 这 种 可 扩展 性 
也 是 ELF 得 以 广泛 推广 的 一 个 重要 原因 ， 我 们 后 续 在 分 析 它 的 内 部 结构 
还 会 有 进一步 讲解 。 


从 ELF 文 件 的 典型 处 理 过 程 来 看 ， 它 至 少 支持 3 种 文件 形态 ， 分 别 是 
可 重 定 向 文件 (Relocatable File) 、 可 执行 文件 (Executable 
File) 和 可 共享 的 对 象 文 件 (Shared Object File) 。 如 图 21-24 所 
7JNo 





Relocatable 
Files 


ion 
al 


Shared Object Files 


Shared Object Files 





Edit | Source Preprocessing] Temp | Compile 
Developer | : : 
Files Files | Compiler 


全 图 21-24 ELF 的 典型 处 理 流程 


首先 ， 开 发 人 员 利 用 1DE 或 者 文本 编辑 器 编写 源码 文件 〈 如 C/C++ 语 
言 源 代码 ) 。 预 处 理 主要 针对 的 是 各 种 预 编译 语句 ， 
如 “#define”“#include” 等 ， 并 将 处 理 结 果 输 出 给 编译 阶段 。 紧 接 
着 的 编译 任务 涉及 的 环节 比较 多 ， 包 括 语法 分 析 、 语 义 分 析 和 优化 等 ， 
因而 通常 也 是 最 耗 时 的 。 不 过 它 的 产 出 物 还 不 是 最 终 的 机 器 码 ， 而 是 汇 
编码 一 一 这 也 就 是 下 一 步 我 们 需要 执行 Assembly 的 原因 ， 此 时 得 到 的 文 
件 我 们 称 为 目标 文件 (0bject File) 。 一 个 可 执行 对 象 〈 或 者 库 ) 通 
常 是 由 多 个 0bject 组 成 的 ， 所 以 我 们 还 需要 最 后 一 步 ， 即 通过 
Linking (这 个 过 程 中 会 涉及 Address Allocation, Symbol 
Resolution、Relocation 重 定位 等 多 个 过 程 ) 生成 为 最 终 的 输出 物 〈 如 
动态 链接 库 、 可 执行 文件 等 ) ， 或 者 利用 ar 来 生成 静态 库 。 当 然 ， 现 在 
的 编译 器 一 般 会 把 这 些 步 又 隐藏 起 来 ， 用 户 只 需要 利用 简单 的 命令 就 可 
以 完成 所 有 编译 链接 过 程 了 。 


Relocatable File 的 一 个 具体 范例 是 . o 文 件 ， 它 是 在 编译 过 程 中 产 
生 的 “中 间 文 件 ”。 例 如 图 21-25 所 示 的 是 A0SP 工 程 中 adbd 程 序 的 编译 
产物 ， 其 中 包含 了 很 多 . o 文 件 : 


EXECUTABLES adbd intermediates 





md i 


daemon export_includes File_sync_service.o 
out/t | out/t 
sys sys 
bui bui 
svs bio 
file_sync_service.P framebuffer_ framebuffer_ 
service.o service.P 
-I sy out/t 
-I sy sys 
-I sy bui 
Svs 
import_includes remount_service.o remount_service.P 
] out/t f 
bui 
svs 
services.o services.P set_verity_enable_ 


state_service.o 


从 图 21-25 adbd 程 序 的 编译 产物 
我 们 可 以 通过 fi le 命令 来 揭 开 这 些 . o 文 件 的 “庐山 真面目 ” 


s@ubuntu:~/Android_M/out/target/product/generic/ob}/EXECUTABLES/adbd_intermediates$ file services.o file sync_service.o franebuffer_service.o 
mount_service.o set_verity enable state service.o 

services.0: ELF 32-bit LSB relocatable, ARM, EABIS version 1 (GNU/Linux), not stripped 

file_sync_service.o: ELF 32-bit LSB relocatable, ARM, EABIS version 1 (GNU/Linux), not stripped 

U/Linux), not stripped 

U/Linux), not stripped 

U/Linux), not stripped 


renount_service,0: ELF 32-bit LSB relocatable, ARM, EABIS version 4 


I 

I 
franebuffer_service,o; ELF 32-bit LSB relocatable, ARM, EABIS version 1 

I 
set_verity enable state service.o: ELF 32-bit LSB relocatable, ARM, EABIS version 1 


N 
(CN 
(CN 
(CN 
(CN 





可 见 它 们 都 属于 ELF (32bit 或 64bit) Relocatable 文 件 。 


除了 上 述 的 “中 间 文 件 ” 外 ，ELF 格 式 的 可 执行 文件 相信 大 家 也 不 
会 陌生 。Linux 平 台 下 的 大 部 分 可 执行 程序 都 采用 了 ELF 规 范 ，Android 
系统 自然 也 不 例外 。 例 如 下 面 所 示 的 是 针对 Android 工 程 中 
prebuilt/qemu-kernelvarm 目 录 下 的 vml inux-qemu 程 序 执行 的 fi1e 结 
果 : 


s@ubuntu:~/Androtd M/prebuilts/qenu-kernel/ars file vmlinux-qenu 
vnlinux-qemu: ELF 32-bit LSB executable, ARM, EABIS version 1 (SYSV), statically Linked, BuildID[ shat }=8887¢22689309b389959c29Fd3ea9d912c94b80H 





, hot stripped 


可 见 它 们 的 文件 格式 是 ELF (32b it 或 者 64bit) Executable. 


ELF 的 另 一 种 文件 形态 是 Shared Object File〈 即 动态 链接 库 ) ， 
通常 情况 下 以 “. so” 为 后 缀 名 。Android 工 程 中 同样 包含 了 很 多 动态 链 
接 库 对 象 ， 例 如 下 面 所 示 的 1ibselinux. so: 


S@ubuntu:~/Androtd M/out/host/Linux-x86/Lib64$ file Libselinux.so 
libselinux.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically Linked, BuildID[shat ]=0427918cF960f98F7c03¢6577c648673c0190 





16, not stripped 
由 此 可 见 ，ELF 文 件 规范 实际 上 就 贯穿 于 整个 Android 工 程 中 。 


有 了 这 些 “ 感 性 ”的 认识 后 ， 接 下 来 我 们 进一步 了 解 ELF 文 件 格式 
的 内 部 构成 。 


根据 ELF 规 范文 档 中 的 描述 ， 我 们 可 以 从 Linking 和 和 Execution 两 个 
视角 来 审视 它 的 内 部 结构 ， 如 图 21-26 所 示 。 


那么 ELF 的 设计 者 为 什么 要 为 它 提供 两 个 不 同 的 视角 ， 图 21-26 所 示 
的 Section 和 Segment 之 间 的 区 别 和 联系 又 是 什么 呢 ? 


Linking View 
ELF Header 


Program Header Table 
optional 


Section | 


Seciton Header Table 








Execution View 


ELF Header 


Program Header Table 


Seciton Header Table 
optional 


OSDI980 


全 图 21-26 ELEF 文 件 格式 的 两 个 视角 


简单 来 讲 ，Section 中 存储 的 信息 用 于 支撑 程序 的 链接 工作 ， 针 对 
的 是 Linker; 而 Segment 提 供 的 则 是 程序 运行 时 所 需 的 数据 ， 面 向 的 是 
加 载 器 Loader 。 另 外 ， 以 Segment 的 方式 加 载 在 一 定 程度 上 还 可 以 节约 
存储 空间 。 这 是 因为 Section 在 加 载 时 是 页 对 齐 的 ， 这 样 难 免 会 造成 空 
间 资 源 的 浪费 。 而 一 个 Segment 由 多 个 段 组 成 ， 段 与 段 之 间 没 有 间隔 ， 
所 以 能 尽量 避免 类 似 情 况 的 发 生 。 由 于 Section 和 Segment 的 中 文 译名 都 
可 以 是 “ 段 ”， 大 家 在 查阅 相关 资料 时 一 定 要 鉴别 清楚 作者 所 指 的 是 什 
A, UR “AEk, BH” . 


接 下 来 我 们 编写 一 个 简单 的 程序 ， 并 通过 解析 这 个 程序 的 内 部 构造 
来 帮助 大 家 更 好 地 理解 ELF 文 件 格式 。 


范例 程序 的 功能 相当 简单 ， 就 是 完成 对 两 个 int 变 量 的 求 和 操作 ， 
如 下 所 示 : 


/*main.c*/ 
#include "stdio.h" 


void main() 

add(1,2); 

printf("This is an example"); 
int add(int value1, int value2) 


return valueit+value2; 


} 
我 们 首先 通过 gcc 将 上 述 的 main. c 编 译 成 main. o 文 件 ， 命 令 行 如 


下 : 
gcc -c main.c 


然后 利用 readel1f 读 取 它 的 头 文件 内 容 ， 结 果 如 图 21-27 所 示 。 


S@ubuntu:~/TestELF$ readelf -h main.o 

ELF Header: 
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
Class: ELF64 
Data: 2's complement, Little endian 
Version: 1 (current) 
OS/ABI: UNIX - System V 
ABI Version: 9 
Type: REL (Relocatable file) 
Machine: Advanced Micro Devices X86-64 
Version: 0x1 
Entry point address: 0x0 
Start of program headers: 9 (bytes into file) 
Start of section headers: 384 (bytes into file) 
Flags: 0x0 
Size of this header: 64 (bytes) 
Size of program headers: 9 (bytes) 
Number of program headers: 0 
Size of section headers: 64 (bytes) 
Number of section headers: 13 
Section header string table index: 10 





全 图 21-27 ELF 的 Header 信 息 


顺便 说 一 下 ，reade1f 是 Linux 系 统 中 分 析 ELF 文 件 的 一 个 很 方便 的 
工具 。 大 家 可 以 通过 “--help” 命 令 来 获取 到 它 的 具体 使 用 方法 。 


根据 ELF 官 方 文档 的 描述 ，ELF Header 对 应 的 数据 结构 是 : 


#define EI NIDENT 16 


typedef struct { 
unsigned char e ident[EI NIDENT]; 


Elf32 Half e type; 
Elf32 Half e machine; 
Elf32 Word e version; 
Elf32 Addr e entry; 
E1f32 off e phoff; 
E1f32 Off e shoff; 
Elf32 Word e flags; 
Elf32 Half € ehsi 767 
Elf32 Half e phentsize; 
Elf32 Half e phnum; 
Elf32 Half e shentsize; 
Elf32 Half e shnum; 
Elf32 Half e shstrndx; 


} El1f32 Ehdr; 


我 们 对 照 上 面 reade1f 得 到 的 实例 数据 ， 来 逐一 解释 E1f32_Ehdr 中 
各 个 字段 的 含义 (注意 : reade1f 对 ELF 文 件 进行 了 “可 读 性 ”处 理 ， 
而 在 显示 顺序 上 有 可 能 和 上 述 的 数据 结构 没有 完全 一 致 〉: 


e El NIDENT 


由 reade1f 的 结果 可 以 看 到 ，ELF 的 Magic 区 域 共 16 个 字 节 ， 即 “7f 
45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00”。 好 比 每 种 商品 都 
需要 一 个 标签 一 样 ，ELF 也 需要 一 张 “身份 证 ”: 前 4 个 字 节 “7f 45 4c 
46” 表 示 ELF 的 文件 魔 数 ， 即 ASC11 码 “. ELF”; 第 5 个 字 节 代表 硬件 平 
台 的 位 数 〈1 代 表 32 位 ，2 代 表 64 位 ) ;第 6 个 字 节 表示 数据 的 大 小 端 模式 
(1 代表 小 端 模 式 ，2 代 表 大 端 模 式 ) ; 第 7 个 字 节 代表 ELF 的 版 本 号 ， 不 
过 到 目前 为 止 这 个 数 只 能 被 置 为 1; 第 8 个 字 节 用 于 表示 目标 操作 系统 
ABI (例如 0x00 表 示 System V，0x01 表 示 HP-UX，0x02 表 示 NetBSD，0x03 
表示 Linux 等 ) 。 


。 紧 随 其 后 的 e_type 用 于 指示 这 个 ELE 对 象 的 文件 类 型 。 核 心 值 如 下 


所 示 : 


Name Value Meaning 
ET NONE No file type 
ET REL Relocatable file 
ET EXEC Executable file 
ET DYN Shared object file 
ET CORE Core file 
ET LOPROC Processor-specific 
ET HIPROC Processor-specific 





例如 编译 阶段 得 到 的 . o 可 重 定位 文件 ， 就 属于 ET_REL 类 型 。 
e e_machine 


用 于 标记 机 器 的 平台 架构 ， 可 选 值 如 下 所 示 : 


Name Value Meaning 
EM NONE No machine 
EM M32 AT&T WE 32100 
EM SPARC SPARC 
EM 386 Intel 80386 
EM 68K Motorola 68000 
EM 88K Motorola 88000 
EM 860 Intel 80860 
EM MIPS MIPS RS3000 





e e_version 
用 于 指示 ELF 规 范 的 版 本 号 。 
e e_entry 


程序 的 入 口 地 址 ， 即 系统 将 首先 把 控制 权 传 递 到 e_entry 这 个 虚 地 
址 所 指示 的 位 置 。 在 我 们 这 个 main. o 范 例 中 e_entry 的 具体 值 为 0。 


e ¢_phoff 


用 于 指示 Program Header Table 在 这 个 ELF 文 件 中 的 偏 移 量 (以 字 
节 为 单位 ) ， 在 我 们 这 个 场景 下 e_phoff 为 0。 


e e_shoff 


用 于 指示 Section Header Table 在 这 个 ELF 文 件 中 的 偏 移 量 (以 字 
节 为 单位 ) ， 有 可 能 为 0。 我 们 会 在 后 续 内 容 中 做 进一步 分 析 。 


e e_flags 
这 是 与 本 ELF 文 件 所 针对 的 目标 处 理 器 相关 (Processor- 


Specific) 的 标志 位 。 图 21-28 所 示 是 《ELF for the Arm 
Architecture》 中 关于 e flags 的 描述 。 


Table 4-2, ARM-specific e_flags 





EF ARM ABIMASK This masks an 8-bit version number, the version of the ABI to which this 
(OxFF000000) ELF file conforms. This ABI is version 5. A value of 0 denotes unknown 
(current version is 0x05000000) | conformance. 
EF ARM BE8 The ELF file contains BE-8 code, suitable for execution on an ARM 
(0x00800000) Architecture v6 processor. This flag must only be set on an executable file. 


EF ARM GCCMASK Legacy code (ABI version 4 and earlier) generated by gcc-arm-xxx might 
(0x00400FFF) use these bits. 


EF ARM ABI FLOAT HARD Set in executable file headers (e_type = ET_EXEC or ET_DYN) to note that 
(0x00000400) the executable file was built to conform to the hardware floating-point 
(ABI version 5 and later) procedure-call standard. 
Compatible with legacy (pre version 5) gcc use as EF_ARM_VFP_FLOAT. 


EF ARM ABI FLOAT SOFT Set in executable file headers (e type = ET_EXEC or ET_DYN) to note 
(0x00000200) explicitly that the executable file was built to conform to the software 
(ABI version 5 and later) floating-point procedure-call standard (the base standard). If both 
EF_ARM AB| FLOAT XXXX bits are clear, conformance to the base 
procedure-call standard is implied. 
Compatible with legacy (pre version 5) gcc use as EF ARM_SOFT_FLOAT. 








全 图 21-28 e_flags 的 描述 
e ce chsize 
用 于 描述 ELF Header 所 占 的 空间 大 小 〈 以 字 节 为 单位 ) 。 
e e_phentsize 


用 于 标记 一 个 Program Header 所 占 的 空间 大 小 〈 以 字 节 为 单位 ) ， 
有 可 能 为 0。 因 为 我 们 的 范例 是 编译 产生 的 中 间 . o 文 件 ， 所 以 并 不 涉及 


Segment。 
e e_phnum 
用 于 标记 Program Header Table 的 总 条 目 数 ， 有 可 能 为 0。 
e e_shentsize 
用 于 标记 一 个 Section Header 所 占 的 空间 大 小 〈 以 字 节 为 单位 ) 。 
e e_shnum 
用 于 标记 Section Header Tables FEAR. 


前 面 我 们 提 到 ，Sect ion 主 要 是 在 链接 和 重 定位 阶段 发 挥 作用 。 换 
句 话 说 ，Relocable Files 正 常情 况 下 都 会 包含 Section 信 息 。 我 们 同样 
可 以 利用 reade1f 工 具 把 ELF 中 的 Section 信 息 打 印 出 来 ， 所 用 命令 行 如 
F: 


readelf -S main.o 


根据 图 21-29 所 示 的 输出 结果 ， 可 以 得 知 main. o 包 含 了 多 达 13 个 的 
Section， 其 中 既 有 大 家 所 熟悉 的 . text (FERRIES) ，. data 〈 已 赋 初 
始 值 的 静态 变量 ) 和 . bss 段 〈 未 赋 初 始 值 的 全 局 变量 和 静态 变量 ) , E 
有 . rela. text、. symtab 这 类 看 上 去 比较 陌生 的 Section 那么 后 面 这 
些 段 有 什么 作用 呢 ? 


简单 来 说 ， 它 们 将 在 程序 链接 、 重 定位 或 者 其 他 环节 中 起 到 辅助 作 
FA. 240. shstrtab 是 “Section Header String Table” 的 缩写 ， 用 于 





记录 每 个 Sect ion 的 名 称 。 它 在 main. o 中 的 偏 移 地 址 为 0x118 〈 图 21-29 
中 的 “0ffset” 列 ) ， 占 用 空间 大 小 为 0x61。 我 们 可 以 利用 下 面 的 命令 
来 分 析 . shstrtab 中 存储 的 内 容 是 什么 : 


hexdump 


-C main.o 


结果 值 如 图 21-30 所 示 。 


Section Headers : 


[Nr] 


Name 
Size 


0000000000000000 
- text 
000000000000003d 
.rela.text 
0000000000000048 
.data 
0000000000000000 
.bss 
0000000000000000 
.rodata 
0000000000000013 
. comment 
000000000000002c 
.note.GNU-stack 
0000000000000000 
.eh_frame 
0000000000000058 
.rela.eh frame 
0000000000000030 
.shstrtab 
0000000000000061 
.Symtab 
0000000000000120 
.strtab 
0000000000000018 


Type 

EntSize 

NULL 
0000000000000000 
PROGBITS 
0000000000000000 
RELA 
0000000000000018 
PROGBITS 
0000000000000000 
NOBITS 
0000000000000000 
PROGBITS 
0000000000000000 
PROGBITS 
0000000000000001 
PROGBITS 
0000000000000000 
PROGBITS 
0000000000000000 
RELA 
0000000000000018 
STRTAB 
0000000000000000 
SYMTAB 
0000000000000018 
STRTAB 
0000000000000000 


Address 
Flags Link Inf 
0000000000000000 
0 
0000000000000000 
AX 0 
0000000000000000 
11 
0000000000000000 
WA 0 
0000000000000000 
WA 0 
0000000000000000 
A 0 
0000000000000000 
MS 0 
0000000000000000 
0 
0000000000000000 
A 0 
0000000000000000 
a UF 
0000000000000000 
0 
0000000000000000 
12 
0000000000000000 
9 


全 图 21-29 ELF 中 的 Section 范 例 


DO 


9 


0 


1 


9 


9 


9 


9 


0 


0 


8 


0 


9 


0 


offset 
Align 
00000000 
0) 
00000040 
1 
000005f8 
8 
0000007d 
1 
0000007d 
al 
0000007d 
1 
00000090 
1 
000000bc 
1 
000000c0 
8 
00000640 
8 
00000118 
1 
000004c0 
8 
000005e0 
1 





- symtab | 
|..strtab..shstrt| 
Jab..rela.text..d| 


|ata. .bss. .rodata| 
| . .Comment . .note. | 
|GNU-stack..rela. | 
|eh_frame 





全 图 21-30 shstrtab section 中 的 内 容 
这 和 我 们 在 “readelf -S$” 看 到 的 情况 是 一 致 的 。 


“. strtab” 是 “String Table” 的 简写 ， 是 字符 串 的 列表 集合 。 
每 个 字符 串 都 被 要 求 以 ASC11 格 式 存储 ， 且 以 “\0” 结 尾 : 


000005e0 00 6d 61 69 6e 2e 63 00 6d 61 69 6e 00 61 64 64 |.main.c.main.add 
000005f6 00 70 72 69 6e 74 66 00 14 00 00 00 00 00 00 00 |.printf 





那么 各 个 Symbol1 是 如 何 与 . strtab 对 应 起 来 的 呢 ? 这 就 是 . symtab 所 
起 的 作用 ， 它 为 每 个 Symbo1 都 分 配 了 一 个 全 局 唯一 的 entry， 从 而 建立 
起 符号 与 字符 串 之 间 的 对 应 关系 。 以 main. c 中 的 add 函 数 (Symbol) 为 
例 ， 其 在 . symtab 中 对 应 的 是 如 图 21-31 所 示 的 第 10 项 内 容 。 


table '.symtab' contains 12 entries: 
Value Size Type Bind Vis Ndx Name 
0000000000000000 NOTYPE LOCAL DEFAULT UND 
0000000000000000 FILE LOCAL DEFAULT ABS main.c 
0000000000000000 SECTION LOCAL DEFAULT 1 
0000000000000000 SECTION LOCAL DEFAULT 3 
0000000000000000 SECTION LOCAL DEFAULT 一 
0000000000000000 SECTION LOCAL DEFAULT 5 
0000000000000000 SECTION LOCAL DEFAULT 7 
8 
6 
al 


© 


0000000000000000 SECTION LOCAL DEFAULT 
0000000000000000 SECTION LOCAL DEFAULT 
0000000000000000 FUNC GLOBAL DEFAULT main 
0000000000000029 FUNC GLOBAL DEFAULT 1 add 
0000000000000000 NOTYPE GLOBAL DEFAULT UND printf 


N +S 
OOreROOOCOOOʻ`OO`OOO 


s 
2: 
= iF 
4: 
Si 
6: 
te 
8 : 
9; 
0: 
abe 


ha þad 





全 图 21-31 symtab 各 项 内 容 


Symbol Table 的 数据 结构 如 下 : 


Figure 1-15. Symbol Table Entry 


typedef struct { 
Elf32 Word st_name; 
Elf32 Addr st_value; 
E1f32 Word st size; 
unsigned char st info; 
unsigned char st other; 
Elf32 Half st_shndx; 

} Elf32 Sym; 


很 显然 ，st_name 表 示 的 是 这 个 Symbo1 的 名 称 。 但 细心 的 读者 应 该 
能 发 现 ， 它 其 实 只 是 一 个 Word 值 ， 如 何 能 表达 出 “add” 这 个 字符 串 
Ne? 答案 就 是 st_name 实 际 上 是 “add” 字 符 串 在 . strtab 中 所 对 应 的 
Index。 这 样 的 设计 一 方面 有 效 解 决 了 字符 串 这 种 可 变 长 度 的 数据 与 其 
他 固定 长 度数 据 如 何 “共存 ”的 问题 ; 另 一 方面 也 可 以 实现 字符 串 的 复 
用 ， 节 约 了 存储 空间 。 


另外 ，“add” 的 Type 是 FUNC， 代 表 它 是 一 个 函数 ; Ndx 是 Index 的 
缩写 ， 表 示 这 个 函数 的 定义 是 在 序号 为 1 的 Section 中 ， 
即 “. text” 段 ; “Value” 列 则 表示 add 函 数 在 “. text” 中 的 偏 移 量 ， 
从 中 可 以 看 到 这 个 值 是 0x29。 


那么 情况 真 的 是 如 此 吗 ? 我 们 可 以 通过 反 编译 main. o 来 找到 答案 ， 
如 图 21-32 所 示 。 


Disassembly of section .text: 


0000000000000000 <main>: 

0: %rbp 
%rsp,%rbp 
$0x2,%esi 
$0x1,%edi 
$0x0 , %eax 
18 <main+0x18> 
$0x0,%edi 
50x0 ,%eax 
27 <main+0x27> 
%rbp 


%rbp 

%rsp,%rbp 

%edi, -Ox4(%rbp) 
%eS1, -Ox8(%rbp) 
-Ox8(%rbp) , %eax 
-0x4(%rbp) , %edx 
%edx ,%eax 

%r bp 





A 4) 21-32 main.o 的 编译 结果 


由 图 21-32 我 们 可 以 清楚 地 看 到 ，add 在 main. o 文 件 中 的 仿 移 量 确实 
是 0x29。 不 过 因为 当前 main. o 还 没有 经 过 链接 操作 ， 所 以 各 个 地 址 值 看 
上 去 还 不 是 很 正规 。 接 下 来 我 们 就 执行 链接 操作 使 其 成 为 真正 的 可 执行 
程序 ， 所 使 用 的 命令 如 下 所 示 : 


gcc -O main main.o 


此 时 我 们 再 来 反 编译 main 文 件 ， 情 况 已 经 发 生 了 很 大 的 变化 。 如 图 
21-33 所 示 。 


000000000040052d <main>: 
40052d: 55 %rbp 
40052e: 48 %rsp ,%rbp 
400531: be $0x2,%esi 
400536: bf $0x1,%edi 
40053b: b8 $0x0,%eax 
400540: e8 400556 <add> 
400545: bf $0x4005f4,%edi 
40054a: b8 $0x0,%eax 
40054f: e8 400410 <printf@plt> 
400554: 5d %rbp 
400555: c3 


0000000000400556 <add> : 
400556: %rbp 
400557: 89 %rsp ,%rbp 
40055a: 7d %edi, -Ox4(%rbp) 
40055d: 75 %eS1, -Ox8(%rbp) 
400560: 45 -0x8(%rbp) , %eax 
400563: 55 -O0x4(%rbp) ,%edx 
400566: dO %edx , %eax 
400568: %rbp 
400569: 
40056a: Of 1f 44 00 00 Ox0(%rax,%rax,1) 





全 图 21-33 ”执行 链接 操作 后 再 次 反 编 译 的 结果 


为 了 方便 大 家 对 main 函 数 在 链接 前 后 的 变化 做 对 比 观察 ， 我 们 特别 
制作 了 下 列表 格 ， 如 图 21-34 所 示 。 





0: 55 
push %rbp 40052d: 55 

1: 48 89 push %rbp 
e5 mov 40052e: 48 89 e5 
%rsp,%rbp mov Yorsp, %rbp 

4: be 02 00 00 00 400531: be 02 00 00 00 
mov $0x2,%esi mov $0x2,%esi 


9: bf 01 00 00 00 400536: bf 01 00 00 00 


mov $0x1,%edi mov $0x1,%edi 


e: b8 00 00 00 00 40053b: b8 00 00 00 00 
mov $0x0,%eax mov $0x0,%eax 

13: e8 00 00 00 00 400540: e8 11 00 00 00 
callq 18 <main+0x18> callq 400556 <add> 

18: bf 00 00 00 00 400545: bf f4 05 40 00 
mov $0x0,%edi mov $0x4005f4,%edi 

1d: b8 00 00 00 00 40054a: b8 00 00 00 00 
mov $0x0,%eax mov $0x0,%eax 

22: e8 00 00 00 00 40054f: e8 bc fe ff ff 
callq 27 <main+0x27> callq 400410 <printf@plt> 

27: 5d 400554: 5d 
pop %rbp pop %rbp 

28: c3 400555: c3 
retq retq 





AA21-34 ”对比 结果 
其 中 有 差异 的 地 方 我 们 以 阴影 的 方式 标识 出 来 ， 包 括 但 不 限于 : 
。 地址 由 相对 地 址 变 成 了 绝对 地 址 


可 以 明显 地 看 到 各 条 指令 的 地 址 已 经 由 0x00、0x01 等 相对 地 址 转变 
成 了 0x40052d、0x40052e 等 绝对 地 址 〈 虚 拟 内 存 地 址 ) 。 


。 函数 的 跳 转 指令 发 生 了 变化 


对 于 “add” 这 类 在 可 执行 程序 内 部 定义 的 函数 ， 我 们 可 以 直接 利 
用 它 的 绝对 地 址 来 实现 跳 转 ; 而 对 于 printf 这 种 由 动态 链接 库 提供 的 函 
数 则 没有 那么 简单 。 因 为 动态 链接 库 被 加 载 到 内 存 中 的 具体 地 址 必须 要 
等 到 运行 阶段 才能 得 到 确认 ， 所 以 我 们 需要 一 种 更 为 灵活 的 机 制 来 确保 
程序 可 以 正常 调用 动态 链接 库 中 的 函数 。 这 就 涉及 了 动态 链接 库 的 加 载 
与 运行 原理 了 ， 我 们 将 在 下 一 小 节 做 专门 讲解 。 


ELF 中 其 他 常见 的 区 段 及 释义 如 表 21-6 所 示 。 


表 21-6 ELF 常 见 Section 释 义 


a aa || 








Section Description 


text 代码 区 段 


.data 经 过 初始 化 的 变量 区 


i 


„bss 未 初始 化 的 变量 区 


函数 的 重 定 位 信息 区 


.rel.text 











静态 变量 的 重 定向 信息 区 


.rel.data 


用 于 动态 链接 时 提供 重 定 癌 信息 〈 如 果 使 用 了 PLT) 


rel.plt JER: 在 64 位 机 器 上 的 名 称 是 .rela.plt 


用 于 动态 链接 时 提供 重 定 癌 信 息 〈 如 果 没 有 使 用 
PLT) 


.rel.dyn 





got Global Offset Table, JEE HX A EHR EIE 
debug ”提供 调试 相关 信息 


.strtab = String Table， 用 于 存储 各 个 Symbol 名 对 应 的 字符 串 


symtab Symbol Table， 用 于 存储 各 个 Symbol 的 数据 


REPPI EEE 





ot Executable 或 Shared Object 中 包含 的 用 于 初始 化 的 函 
| 数 


ae fini 类 似 ， 提 供 了 一 组 用 于 初始 化 的 函数 〈 按 顺序 


Executable 或 Shared Object 中 包含 的 用 于 析 构 的 函数 








和 .fini 类 似 ， 提 供 了 一 组 用 于 析 构 的 函数 “ 按 顺 序 执 
) 


.fini_array 行 


J 





ELF 文 件 也 允许 程序 亨 根 据 需 要 来 提供 构造 和 析 构 函数 〈 这 点 和 Class 
类 很 相似 ) ， 分 别 对 应 . init/. init array 和 和. au fini array 区 段 。 
AA A AN RRMA, HE RASA aA ; 
MACIE, “HH” RAES 被 执行 。 如 
RR. init/. init_array 在 ELF 中 同时 存在 ， 那 么 前 者 的 优先 级 要 高 于 后 
者 。 利 用 C/C++ 语言 编程 时 ， 开 发 人 员 可 以 通过 给 函数 指定 

attribute ((constructor))/((destructor)) JÆ 性 来 生 
成 . init/. fini 区 段 。 


值得 一 提 的 是 ，ELF 可 执行 程序 在 运行 时 的 内 存 布局 大 致 如 图 21-35 
所 示 。 


Kernel Space 
Random stack offset 


Memory Mapping 


Random brk offset 





全 图 21-35 ELF 可 执行 程序 典型 内 存 布局 图 


因为 Android 虚 拟 机 本 身 也 是 寄居 在 Li nux 应 用 程序 之 上 的 ， 所 以 同 
样 遵循 上 述 图 例 ， 这 一 点 请 大 家 在 学 习 虚 拟 机 过 程 中 务必 保持 正确 的 认 


识 。 

21.3.2 Linux 平 台 下 ELF 文 件 的 加 载 和 动态 链接 过 程 
静态 库 和 动态 链接 库 有 什么 区 别 呢 ? 
Wiki 上 对 静态 库 的 释义 如 下 所 示 : 


“In computer science, a static library or statically- 
linked library is a set of routines, external functions and 
variables which are resolved in a caller at compile-time and 
copied into a target application by a compiler, linker, or 
binder, producing an object file and a stand-alone 
executable” 


RPO HEJL IFFR ae Se EIET AY eT ES LE A SOY) 
地 址 解析 工作 ， 并 使 之 成 为 可 执行 程序 中 不 可 分 割 的 一 部 分 。 这 种 处 理 
手段 在 某 种 程度 上 也 可 以 有 效 地 实现 代码 的 重复 利用 ， 使 得 编 与 程序 不 
需要 每 次 都 从 零 开 始 ， 因 而 在 程序 开发 的 早期 得 到 了 广泛 的 应 用 一 一 其 
至 是 当时 技术 条 件 下 的 唯一 选择 。 但 是 它 的 缺点 也 是 比较 明显 的 ， 即 可 
执行 程序 的 体积 会 随 着 静态 链接 库 的 增加 而 不 断 变 大 。 男 外 ， 如 果 操 作 
系统 中 有 多 个 可 执行 程序 都 用 到 了 同一 个 静态 库 A， 按 照 静 态 链接 的 做 
法 就 需要 把 A 分 别 打包 进 所 有 程序 中 一 一 这 显然 是 一 种 资源 浪费 。 


与 静态 链接 库 相 对 应 的 ， 便 是 动态 链接 库 的 处 理 方式 ， 我 们 再 来 看 
下 它 的 定义 : 


“In computing, a dynamic linker is the part of an 
operating system that loads and links the shared libraries 
needed by an executable when it is executed (at "run time"), 
by copying the content of libraries from persistent storage to 
RAM, and filling jump tables and relocating pointers. ” 


动态 链接 库 有 如 下 几 个 核心 特点 : 


。 动态 链接 库 不 需要 在 编译 时 就 被 打包 到 可 执行 程序 中 ， 而 是 等 到 后 
者 在 运行 阶段 再 实现 动态 的 加 载 和 重 定位 。 

。 动态 链接 库 在 被 加 载 到 内 存 中 之 后 ， 操 作 系 统 需 要 为 它 执 行动 态 链 
接 操 作 。 值 得 一 提 的 是 ， 有 一 些 参 考 资料 会 把 这 里 的 链接 称 为 “ 动 
态 链接 ”， 而 将 前 述 编译 阶段 的 链接 叫做 “静态 链接 ”; HBA 
链接 中 也 会 有 Relocation (Link Time Relocation) ， 只 是 和 动态 链接 
中 的 重 定 位 (Load Time Relocation) 所 针对 的 对 象 和 处 理 过 程 存在 
差异 。 换 名 话说 ， 只 要 涉及 多 个 文件 之 间 的 链接 ， 通 常 都 需要 重 定 
位 。 只 不 过 静态 链接 发 生 在 编译 阶段 ， 而 动态 链接 则 发 生 在 运行 阶 
段 。 这 些 概念 都 很 容易 搞 混淆 ， 提 醒 大 家 注意 区 分 。 








实际 的 动态 链接 过 程 是 比较 复杂 的 ， 例 如 需要 链接 器 的 介入 〈 链 接 
器 通常 也 是 一 个 ELF 文 件 ， 因 而 存在 “ 乍 生 鸡 ， 鸡 生 和 蛋 ” 的 问题 ， 解 决 
类 似 问 题 的 办 法 通常 被 称 为 “BootStrap”。 这 其 中 还 有 很 多 有 趣 的 细 
节 ， 有 兴趣 的 读者 可 以 自行 查阅 相关 资料 ) ， 需 要 重 定位 ， 需 要 有 效 的 
机 制 来 管理 所 有 的 动态 符号 等 。 
i 接 下 来 我 们 仍 以 之 前 的 求 和 程序 为 例 ， 进 一 步 讲解 动态 链接 库 的 工 
原理 : 


/*main.c*/ 
#include "stdio.h" 


void main() 

add(1,2); 

printf("This is an example"); 
int add(int value1, int value2) 


return valueit+value2; 


} 


在 这 个 程序 中 ，add 函 数 是 定义 在 main. c 中 的 ， 因 而 它 的 地 址 是 已 
FORD; 而 pr intf 了 水 数 则 由 C6 库 提供 ， 属 于 “外 部 函数 ”， 所 以 它 在 编译 
时 并 不 会 被 打包 到 “ 求 和 ”小 程序 中 。 等 到 “ 求 和 ”程序 在 机 器 上 真正 


运行 起 来 后 ， 操 作 系统 会 把 它 需 要 的 动态 链接 库 从 磁盘 〈 或 其 他 存储 介 
R) 加 载 到 内 存 中 ， 然 后 解析 出 〈 如 果 是 局 用 了 延 时 解析 的 话 ， 情 况 会 
有 所 不 同 ) 所 有 它 引 用 的 外 部 函数 的 真实 地 址 ， 并 保证 可 执行 程序 可 以 
正确 指向 这 些 外 部 函数 。 


那么 动态 链接 的 这 些 操作 是 在 什么 时 候 执 行 的 呢 ? 由 前 一 小 节 的 分 
析 大 家 应 该 知道 ，ELF 头 文件 中 有 一 项 代表 的 是 程序 的 入 口 地 址 ， 即 
e_entry。 它 在 求 和 程序 中 对 应 的 具体 值 是 : 


Version: Ox1 
Entry point address: 0x400440 





Start of program headers: 64 (bytes into file) 


ELF 可 执行 程序 在 运行 过 程 中 的 入 口 地 址 一 定 是 e_entry 吗 ? 这 个 问 
题 可 以 从 Linux Kerne1 如 何 局 动 ELF 程 序 中 找到 答案 。 当 我 们 需要 运行 
一 个 ELF 程 序 时 ， 内 核 在 经 过 一 系列 操作 后 会 调用 do_execve 一 一 这 个 范 
数 最 终 又 会 利用 load_ elf_binary 来 完成 ELF 文 件 的 加 载 和 解析 (Linux 
支持 多 种 可 执行 文件 格式 ， 由 一 个 1inux_binfmt 结 构 体 表示 ， 其 中 包含 
的 load_binary 成 员 变 量 指向 可 执行 文件 具体 的 加 载 函 数 ) 。 


函数 load_elf_binary 很 长 ， 我 们 来 分 段 阅 读 : 


static int load_elf_binary(struct linux_binprm *bprm, struct pt_r 


{ 





/* 开始 处 理 头 文件 信息 */ 

if (loc->elf_ex.e_phentsize != sizeof(struct elf_phdr) ) 
goto out; 

if (loc->elf_ex.e_phnum < 1 || 
loc->elf_ex.e_phnum > 65536U / sizeof(struct elf_phdr) ) 
goto out; 

size = loc->elf_ex.e_phnum * sizeof(struct elf_phdr); 

retval = -ENOMEM; 

elf_phdata = kmalloc(size, GFP_KERNEL); 

if (!elf_phdata) 
goto out; 


变量 loc 保 存 的 是 ELF 文 件 的 头 文 件 信息 。 上 述 代 码 段 中 ，e_phnum 
代表 的 是 Program Header Table 的 数量 ; e_phentsize 则 代表 一 个 
Program Header 所 占 的 空间 大 小 。 因 为 PHT 区 段 对 于 可 执行 程序 来 说 是 


必 不 可 少 的 ， 所 以 在 数量 上 一 定 是 >1 (并 且 <65536) 的 : 


for (i = 0; i < loc->elf_ex.e_phnum; i++) { 
if (elf_ppnt->p_type == PT_INTERP) {... 
retval = -ENOMEM; 
elf_interpreter = kmalloc(elf_ppnt->p_filesz, 
GFP_KERNEL ); 
if (!elf_interpreter) 
goto out_free_ph; 


retval = kernel_read(bprm->file, elf_ppnt->p_offse 
elf_interpreter, 
elf_ppnt->p_filesz); 


interpreter = open_exec(elf_interpreter); 


loc->interp_elf_ex = *((struct elfhdr *)bprm->buf ) 
break; 


} 
elf_ppnt++; 


上 述 这 个 for 循 环 是 整个 函数 的 关键 点 之 一 ， 它 的 目标 是 通过 遍历 
所 有 Program Header 来 查找 到 Interpreter， 即 通常 所 说 的 “解释 
器 ”上 段 。 一 旦 找到 ， 我 们 就 可 以 把 其 中 的 内 容 通 过 kerne1_read 读 取 到 
irae >p_offset 所 指示 的 地 址 空间 中 了 。 


ELF 文 件 格式 有 一 个 名 为 “. interp” 的 Section， 用 于 指示 上 述 的 
链接 器 的 位 置 。 例 如 下 面 是 针对 “ 求 和 ”小 程序 执行 “readelf - 
S” 命 令 所 得 到 的 信息 ， 大 家 注意 看 第 2 个 区 上 段 : 


Section Headers: 
[Nr] Name Type Address Offset 
Size EntSize Flags Link Info Align 


[ 0] NULL 0000000000000000 00000000 
0000000000000000 0000000000000000 0 0 0 
„interp PROGBITS 0000000000400238 00000238 
000000000000001c 0000000000000000 A 0 0 1 





由 “. interp” 区 段 的 0ffset 可 知 它 的 偏 移 量 为 00000238， 我 们 来 
看 一 下 这 个 地 址 下 保存 的 数据 : 







TFE LOMO CMO 6c 6962 3634 2f6c ........ /1lib64/1 
0000240: 642d 6c69 6e75 782d 7838 362d 3634 2e73 d-lLinux-x86-64.s 
0000250: 6f2e 3200 0400 0000 1000 0000 0100 0000 0.2 


2828 6642 2 2 EA 


TN 求 和 程序 所 使 用 的 链接 器 的 名 称 为 “/1ib64/1d-|inux-x86- 
64. so. 2” 〈 这 个 链接 器 虽然 表面 上 看 是 一 个 so 文件 ， 但 事实 上 也 是 一 
个 可 执行 程序 ) ， 它 在 文件 系统 中 的 位 置 如 图 21-36 所 示 。 


lib64 x 


\d-linux-x86-64.s0.2 


全 图 21-36 在 文件 系统 中 的 位 置 


需要 特别 说 明 的 是 ， 我 们 的 求 和 程序 是 在 Linux 平 台 下 所 做 的 实 
验 。Android 系 统 中 的 Linker 与 之 大 同 小 异 ， 如 下 所 示 : 


00000170 20 00 00 00 2f 73 79 73 74 65 6d 2f 62 69 6e 2f | .../system/bin/| 
00000180 6c 69 6e 6b 65 72 00 00 08 00 00 00 04 00 00 00 |linker.......... | 


在 Android 系 统 中 ， 可 执行 程序 通常 会 被 存储 在 /system/bin/ 目 录 
其 中 就 包括 了 我 们 关心 的 Linker。 


我 们 再 回 到 1oad_e1lf_binary 涵 数 ， 看 一 下 系统 会 利用 interpreter 
做 些 什 么 工作 : 


if (elf_interpreter) { 

retval = -ELIBBAD; 

/* Not an ELF interpreter */ 

if (memcmp(loc->interp_elf_ex.e_ident, ELFMAG, SELFMAG) 
goto out_free_dentry; 

/* Verify the interpreter has a valid arch */ 

if (!elf_check_arch(&loc->interp_elf_ex)) 
goto out_free_dentry; 


首先 需要 验证 interpreter 的 合法 性 ， 包 括 Magic Number 是否 正 
i; 机 器 平台 架构 是 否 有 效 等 : 


if (elf_interpreter) { 
unsigned long uninitialized_var(interp_map_addr); 


elf_entry = load_elf_interp(&loc->interp_elf_ex, 
interpreter, 
&interp_map_addr, 
load_bias); 


} else { 
elf_entry = loc->elf_ex.e_entry; 
if (BAD_ADDR(elf_entry)) { 
force_sig(SIGSEGV, current); 
retval = -EINVAL; 
goto out_free_dentry; 


} 


上 述 这 段 代 码 是 决定 ELF 入 口 地 址 的 关键 。 它 的 处 理 逻 辑 概括 起 来 
就 是 : 如 果 interpreter 区 段 存在 ， 那 么 这 个 ELF 文 件 的 入 口 地 址 就 是 
load_elf_interpH WARE; 否则 就 仍然 采用 ELF 头 文件 信息 中 指定 
的 e_entry。 换 名 话说 ，ELF 程 序 真 正 的 入 口 地 址 取决 于 它 在 执行 过 程 中 
是 否 需 要 解释 器 一 一 如 果 答 案 是 肯定 的 ， 那 么 入 口 就 在 解释 器 中 ; 否则 
使 用 默认 的 e_entry。 


理解 了 ELF 的 入 口 地址 如 何 确定 后 ， 4) ANT EK 
数 符 号 特别 是 pr intf 这 类 外 部 函数 ) 信息 


0000000000400570 T _ libc csyu init 
U __libc_start_main@@GLIBC_ 2.2.5 
000000000040052d T main 


U printf@@GLIBC_2.2.5 
00000000004004a0 t register_tm_clones 





不 难 发 现 ， 对 于 main 这 种 内 部 函数 而 言 ， 它 的 地 址 是 预先 就 确定 
AY; 而 pr intf 则 不 一 样 ， 它 只 是 被 标志 为 “pr intf@@GL1BC 2.2.5”， 
并 没有 分 配 具体 的 地 址 值 。 大 家 可 能 会 有 疑问 ， 可 执行 程序 在 运行 时 怎 
么 知道 要 加 载 哪 些 动态 库 呢 ? 这 些 信息 事实 上 是 由 . dynamic 区 段 

(. dynamic 有 点 类 似 于 “大 总 管 ”， 它 包含 了 所 有 与 动态 链接 相关 的 信 
息 ) 提供 的 。 璧 如 从 图 21 -37 Gastar dps) 中 可 以 看 出 这 个 可 执 


行程 序 依 赖 于 1ibc 动 态 库 〈NEEDED 类 型 ) ， 系 统 根据 “这 条 线索 ”很 容 
易 就 能 判断 出 ELF 在 运行 时 所 需要 加 载 的 动态 链接 库 了 。 


有 了 上 述 知识 点 的 铺垫 后 ， 我 们 现在 可 以 给 出 动态 链接 库 相 关 的 处 
理 过 程 了 《以 求 和 程序 为 例 ) 。 


。 在 编译 阶段 ， 求 和 程序 经 历 了 预 编译 、 编 译 、 汇 编 及 链接 操作 后 ， 
最 终 形成 一 个 ELE 可 执行 程序 。 同 时 求 和 程序 所 依赖 的 动态 库 会 被 
记录 到 .dynamic 区 段 中 ; 加 载 动态 库 所 需 的 Linker 由 .interp 来 指示 。 

o 当 求 和 程序 运行 起 来 以 后 ， 系 统 首先 会 通过 .interp 区 段 找到 链接 器 
的 绝对 路 径 ， 然 后 将 控制 权 交 给 它 (因为 求 和 小 程序 使 用 到 了 动态 
链接 库 ， 所 以 入 口 地 址 在 Linketr 中 ) 。 

Linker 负 责 解 析 .dynamic 中 的 记录 ， 得 出 求 和 程序 依赖 的 所 有 动态 链 
接 库 ， 以 及 它们 又 依赖 于 哪些 其 他 的 动态 库 ， 以 此 类 推 。 因 

为 .dynamic 中 并 不 会 指定 动态 库 的 绝对 路 径 ， 所 以 这 还 涉及 搜索 目 
录 的 设置 问题 ， 具 体 细节 大 家 可 以 自行 查阅 相关 资料 了 解 详情 。 
动态 链接 库 加 载 完 成 后 ， 它 们 所 包含 的 export 函 数 在 内 存 中 的 地 址 
就 可 以 确定 下 来 了 。Linketr 通 过 预 设 机 制 ( 如 GOT/PLT) 来 保证 求 
和 程序 中 引用 到 外 部 函数 的 地 方 可 以 正常 工作 ， 即 完成 Dynamic 


Relocation. 








Dynamic section at offset Oxe28 contains 24 entries: 


Tag Type 
0x0000000000000001 
0x000000000000000c 
0x000000000000000d 
0x0000000000000019 
0x000000000000001b 
0x000000000000001a 
0x000000000000001c 
0x000000006ffffef5 
0x0000000000000005 
0x0000000000000006 
0x000000000000000a 
0x000000000000000b 
0x0000000000000015 
0x0000000000000003 
0x0000000000000002 
0x0000000000000014 
0x0000000000000017 
0x0000000000000007 
0x0000000000000008 
0x0000000000000009 
0x000000006ffffffe 
0x000000006fffffff 


作用 ) ? 


高 程序 的 局 动 速 


(NEEDED) 
(INIT) 
(FINI) 
(INIT_ARRAY) 
(INIT_ARRAYSZ) 
(FINI_ARRAY) 
(FINI_ARRAYSZ) 
(GNU_HASH) 
(STRTAB) 
(SYMTAB) 
(STRSZ) 
(SYMENT) 
(DEBUG) 
(PLTGOT) 
(PLTRELSZ) 
(PLTREL) 
(JMPREL) 
(RELA) 
(RELASZ) 
(RELAENT) 
(VERNEED) 
(VERNEEDNUM) 


Name/Value 
Shared library: [libc.so.6] 
0x4003e0 
0x4005e4 
0x600e10 
8 (bytes) 
0x600e18 
8 (bytes) 
0x400298 
0x400318 
©x4002b8 
63 (bytes) 
24 (bytes) 
0x0 
0x601000 
72 (bytes) 
RELA 
0x400398 
0x400380 
24 (bytes) 
24 (bytes) 
0x400360 
1 





全 图 21-37 Dynamic section 


Dynamic Relocation 在 设计 时 有 很 多 需要 考量 的 因素 ， 例 如 : 








(1) 链接 器 如 何 知道 可 执行 程序 中 有 哪些 需要 重 定位 的 对 象 ? 
(2) 在 没有 重 定位 以 前 ， 这 些 被 引用 对 象 的 地 址 如 何 表 示 ? 
(3) 如 何 保证 在 不 修改 代码 段 的 情况 下 完成 Relocation (GOT 表 的 


(4) 如 何等 到 动态 对 象 被 第 一 次 访问 时 才 去 做 解析 操作 ， 从 而 提 
度 ? (PLT 表 的 作用 ) 


对 于 第 1 个 问题 ，ELF 专 门 指 定 了 一 些 特 殊 的 Section 来 做 解答 ， 如 


下 所 示 : 


Relocation section '.rela.dyn' at offset 0x380 contains 1 entries: 
Offset Info Type Sym. Value Sym. Name + Addend 
000000600ff8 000300000006 R_X86_64_GLOB_DAT 0000000000000000 _ gmon_start__ + 0 


Relocation section '.rela.plt' at offset 0x398 contains 3 entries: 


Offset Info Type Sym. Value Sym. Name + Addend 
000000601018 000100000007 R_X86_64_JUMP_SLO 0000000000000000 printf + 0 
000000601020 000200000007 R_X86 64 JUMP_SLO 0000000000000000 _ libc_start_main + 0 
000000601028 000300000007 R_X86_64 JUMP_SLO 0000000000000000 _ gmon_start_ + 0 





ELF 动 态 链 接 库 中 以 “. rela” 开 头 的 Section 描 述 的 是 可 重 定位 相 
关 的 信息 。 比 如 上 面 的 “. rela. dyn” 和 “. rela.plt” 分 别 表示 需要 被 
重 定位 的 数据 对 象 〈 此 时 被 修正 的 位 置 在 “. got” 和 数据 段 中 ) 和 函数 
WR 〈 此 时 被 修正 的 位 置 在 “. got. plt” 中 ) 。 这 一 点 和 静态 链接 时 的 
做 法 类 似 ， 它 会 有 名 为 “. rel.text” 和 “. rel. data” 的 段 来 分 别 保存 
代码 和 数据 段 的 重 定 位 信息 。 另 外 ， 上 图 中 除 printf 之 外 还 有 一 些 由 编 
人 
略 过 。 


这 样子 链接 器 就 可 以 清楚 地 知道 自己 的 服务 对 象 是 谁 了 。 确 定 了 这 
一 点 以 后 ， 链 接 器 接 下 来 要 回答 的 是 ， 它 采用 什么 方式 来 为 这 些 对 象 服 
务 才 是 最 合理 的 呢 ? 大 家 可 能 会 在 第 一 时 间 想 到 : 可 以 在 编译 阶段 只 给 
外 部 对 象 分 配 一 个 临时 地 址 ， 然 后 再 在 动态 重 定 位 时 将 这 些 临时 地 址 蔡 
换 成 真实 地 址 。 这 种 方案 理论 上 是 可 行 的 ， 但 对 于 动态 链接 的 场景 来 说 
并 非 最 佳 方案 。 试 想 一 下 ， 动 态 链接 库 的 一 个 核心 优势 就 是 代码 共享 
不 单 是 指 进程 内 的 代码 共享 ， 还 包括 进程 间 的 代码 共享 一 一 实现 这 
个 目标 的 前 提 条 件 之 一 是 动态 库 中 的 代码 段 不 需要 为 任何 进程 做 定制 工 
作 。 而 采用 上 述 的 方案 显然 需要 为 每 一 个 进程 都 做 一 次 代码 修正 “因为 
在 动态 链接 中 被 蔡 换 的 临时 地 址 是 在 代码 段 中 ) ， 所 以 是 不 可 取 的 。 


ELF 针 对 上 述 问 题 给 出 的 方案 是 GO0T (Global Offset Table) 。 它 
的 核心 思想 说 得 直 白 点 ， 就 是 将 “ 变 ” 与 “不 变 ” 的 部 分 隔离 开 来 一 一 
通过 增加 一 个 “中 间 层 ”G0T， 来 保持 代码 段 的 “不 变 ”， 而 
把 “ 变 ” 的 部 分 放 到 G0T 表 中 。 


(BEA SOOM “ABA” TW? 大 家 是 否 想 过 这 样 的 问题 
如 果 程 序 中 有 非常 多 需要 动态 链接 的 对 象 ， 而 它们 中 的 绝 大 部 分 在 程序 
执行 过 程 中 是 不 会 被 使 用 到 的 ， 那 么 我 们 在 一 开始 就 为 所 有 对 象 做 解析 
和 重 定位 是 否 合理 呢 ? 实践 证 明 这 种 “一 杆子 ”的 做 法 确实 会 影响 程序 











的 运行 效率 ， 特 别 是 它 的 启动 速度 。 聪 明 的 人 们 立即 又 想到 了 有 没有 一 
种 Lazy Binding 的 方法 来 在 “需要 动态 对 象 的 时 候 ” 才 对 它 做 重 定位 
呢 ? 这 就 是 PLT 的 存在 价值 了 。 


接 下 来 我 们 仍然 以 求 和 程序 为 例子 ， 来 详细 分 析 下 G0T 和 PLT 两 大 机 
制 的 实现 原理 。 


先 来 看 下 main 涵 数 对 应 的 汇编 代码 : 


000000000040052d <main>: 
40052d: %rbp 
40052e: 89 %rsp,%rbp 
400531: 02 $0x2,%esi 
400536: 01 $0x1,%edi 
40053b: 00 $0x0,%eax 


400540: 11 400556 <add> 
400545: f4 $0x4005f4,%edi 
40054a: 00 $0x0 ,%eax 

40054f: bc 400410 <printf@plt> 
400554: %r bp 

400555: 





大 家 注意 看 一 下 40054f 这 一 行 汇编 语句 : 
callq 400410 <printf@plt> 


这 里 通过 cal1q 指 令 调 用 了 一 个 地 址 为 0x400410 的 目标 位 置 ， 从 释 
义 来 看 它 属 于 . p1t 区 域 。 所 以 我 们 反 编译 . p1t 段 来 做 跟 进 分 析 : 


0000000000400410 <printf@plt>: 
400410: ff 25 02 Oc 20 00 jmpq *0x200c02(%rip) # 601018 <_GLOBAL_OFFSET_TABLE_+0x18> 


400416: 68 00 00 00 00 pushq $0x0 
40041b: e9 e0 ff ff ff jmpq 400400 < init+0x20> 





《printf@p1t> 的 实现 并 不 复杂 : 0x400410 处 是 一 条 跳 转 指令 ， 而 且 
跳 转 地 址 被 保存 于 0x200c02 指 针 所 指向 的 地 址 。 通 过 0x400410 语 句 后 面 
的 注释 不 难 发 现 ，0x200c02 对 应 的 是 Global Offset Table 含 移 0x18 的 
地 方 。 


此 时 分 为 如 下 两 种 情况 “以 “ 求 和 ”程序 为 例 ): 


e 当 printf 被 第 1 次 访问 时 


当 我 们 第 一 次 调用 pr intf 这 个 函数 时 ， 程 序 首先 通过 cal1q 调 用 
<printf@p1t>， 然 后 在 执行 0x400410 语 句 时 跳 转 到 G0T 表 中 。 可 是 此 时 
printf 了 水 数 的 真实 地 址 还 未 得 到 解析 ， 换 句 话说 G60T+0x18 的 地 方 保存 的 
是 0x400416 一 一 所 以 绕 了 一 圈 又 回 到 了 plt 中 。 而 0x400416 是 条 堆栈 语 
句 ， 目 的 是 为 了 保存 printf 在 rel. plt 中 的 序号 〈rel.plt 中 的 信息 包括 
了 printf 在 G0T 中 的 地 址 ， 以 及 它 的 名 称 “pr intf”， 以 便 后 续 查 找 目 
标 符号 真实 地 址 ， 并 将 结果 值 保 存 到 正确 的 60T 地 址 中 ) 。 紧 接着 执行 
的 0x40041b 也 是 一 条 跳 转 语句 ， 跳 转 目标 是 Plt[0] 。PLT 表 的 第 一 项 是 
比较 特殊 的 ， 它 的 工作 简单 来 说 就 是 为 跳 转 到 GO0T[2] 做 准备 。 而 
GOT[O], GOT[1] 和 GOT[2] 都 是 系统 预先 保留 的 ， 其 中 G0T[2] 中 保存 的 是 
一 个 名 为 _dl_runtime_resolve 的 函数 ， 用 于 解析 某 函 数 名 
(如 “printf”) 的 真实 地 址 。 至 此 目标 函数 在 第 一 次 被 访问 时 就 可 以 
得 到 正确 的 解析 了 。 


e 当 printf 非 首次 执行 时 
有 了 上 一 步 的 努力 后 ，G0T 表 中 已 经 保存 好 pri ntf 的 真实 地 址 了 。 
换 句 话说 ， 当 程序 再 次 执行 到 0x400410 这 个 位 置 时 就 不 会 再 绕 回 
0x400416， 而 是 可 以 直接 跳 转 到 目标 对 象 的 真实 地 址 了 。 


我 们 以 图 21-38 来 帮助 大 家 更 好 地 理解 上 述 讲解 的 整个 过 程 〈 实 际 
情况 会 更 复杂 一 些 ， 但 原理 是 一 样 的 ) : 


mam.) 
void maim () 
| 
l 
add(1, 2); 
print! { “This isan example”); 


\ 
J 






moron (GOTHx18) 










=j- 
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全 图 21-38 GOT 和 PLT 机 制 示 意图 


值得 一 提 的 是 ， 不 少 开发 人 员 经 常 分 不 清 编译 器 提供 的 -fpic 选 项 
的 作用 。 T 如 上 理解 是 “Position Independent 
Code”， 即 位 置 无 关 代 码 。 确 切 地 讲 ， 是 指 代码 段 (. text) 在 运行 时 
不 需要 重新 定位 (Relocation) 。 从 本 小 节 的 分 析 中 我 们 知道 这 一 点 是 
实现 模块 真正 共享 的 关键 ， 因 为 代码 段 的 重新 定位 意味 着 使 用 者 们 需要 


各 自 拥 有 一 份 模块 的 复制 ， 这 显然 是 一 种 无 谓 的 资源 浪费 。 另 外 ， 地 址 
无 关 技 术 不 光 适 用 于 动态 链接 库 ， 对 可 执行 文件 也 是 同样 有 效 的 〈 此 时 
对 应 的 选项 是 -fpie) 。 


我 们 在 这 两 个 小 节 中 讲解 的 内 容 都 是 围绕 C 语 言 展开 的 ， 那 么 c++ 中 
的 情况 会 不 会 有 所 差异 呢 ? 总 体 来 讲 ， 它 们 二 者 在 最 终 形式 上 是 大 同 小 
异 的 ， 主 要 的 区 别 会 体现 在 如 下 几 个 方面 : 


(1) Name Mangling 


Mangle 的 字面 意思 是 “损坏 ”， 不 难 理解 这 是 C++ 针对 函数 和 变量 
采用 的 一 种 改名 机 制 。 这 样 做 的 原因 有 很 多 个 ， 壁 如 为 了 支撑 C++ 的 重 
载 功能 一 一 因为 函数 如 果 名 字 相 同 但 参数 不 同 ， 那 么 编译 后 的 函数 如 果 
采用 原先 的 名 字 就 会 出 现 重 名 现象 。Name Mangling 可 以 有 效 解决 这 个 
问题 ， 它 会 综合 考虑 函数 名 和 函数 相关 的 信息 〈 如 人 参数 ) 从 而 合成 出 一 
个 全 新 的 函数 名 称 。C++ 标 准 中 并 没有 对 Mangl ing 的 具体 做 法 做 强制 约 
束 ， 这 就 意味 着 合成 规则 主要 取决 于 编译 器 本 身 的 设计 。 这 一 点 对 开发 
者 的 可 能 影响 是 我 们 无 法 通过 子 数 名 预先 准确 判断 出 它 在 Name 
Mangling 后 的 结果 ， 如 此 一 来 dl sym 这 样 的 函数 在 某 些 场景 下 可 能 就 无 
计 可 施 了 解决 这 个 问题 的 一 个 可 选 的 方法 是 在 C++ 代码 中 使 用 
extern “0”， 以 防止 Name Mangling 的 发 生 。 


(2) 类 的 加 载 


我 们 知道 ，C++ 是 一 门面 向 对 象 的 语言 ， 类 的 使 用 非常 普遍 。 但 是 
如 何 从 一 个 C++ 代码 生成 的 库 中 创建 对 象 实例 并 不 是 件 容 易 的 事 。 不 过 
这 个 问题 已 经 有 不 少 人 给 出 了 答案 ， 限 于 篇 幅 我 们 不 做 深入 分 析 ， 有 兴 
趣 的 读者 可 以 自行 搜寻 相关 资料 了 解 详情 。 





21.3.3 Android Linker 和 动态 链接 库 
21.3.3.1 Android 中 动态 库 的 隐 式 调用 与 链接 


通过 前 面 小 节 的 学 习 ， 我 们 知道 ELF 格 式 的 可 执行 程序 会 提供 一 个 
名 为 . interp 的 区 段 ， 用 于 记录 程序 运行 时 所 使 用 的 动态 链接 器 。 当 ELF 
程序 从 内 核 态 切换 到 用 户 态 运 行 时 ， 首 先 被 启动 的 就 是 它 所 指定 的 
Linker 《如 果 这 个 程序 依赖 于 动态 链接 库 的 话 ) 。 紧 接着 动态 链接 器 会 
主动 帮助 程序 加 载 支 撑 其 正常 工作 的 动态 链接 库 文件 ， 这 一 过 程 我 们 称 


为 动态 库 的 隐 式 调用 。 


从 Android 程 序 提供 的 . interp 区 段 中 ， 我 们 不 难 发 现 它 所 指定 的 
Linker 是 /system/binZlinker， 那 么 这 是 在 什么 时 候 做 的 配置 呢 ? 


事实 上 Android 系 统 在 编译 过 程 中 做 了 充分 的 封装 隐藏 ， 因 而 上 述 
配置 过 程 对 开发 人 员 而 言 几 乎 是 透明 的 一 一 编译 系统 利用 统一 的 模板 来 
帮助 程序 完成 对 . interp 区 域 的 填充 ， 如 下 所 示 : 


/*build/core/definitions.mk*/ 
define transform-o-to-executable-inner 
$(hide) $(PRIVATE_CXX) -pie \ 
-nostdlib -Bdynamic \ 
-W1, -dynamic-linker,$(PRIVATE_LINKER) \ 
-W1l,--gc-sections \ 
-W1,-zZ,nocopyreloc \ 


其 中 “-dynamic-linker” 选 项 就 用 于 指定 程序 所 需 的 动态 链接 
器 ， 后 面 紧 跟着 的 $ (PRIVATE_LINKER) 变量 通常 会 被 赋值 
为 : /system/bin/linker (32 位 平台 的 情况 ) 或 
%/system/bin/linker64 〈64 位 平台 的 情况 ) o 


Android Linker 在 A0SP 源 码 工 程 中 所 对 应 的 路 径 
是 /bionic/1inker， 由 它 的 编译 脚本 不 难看 出 ，Linker 也 是 一 个 ELF 可 
执行 文件 : 
/*bionic/linker/Android.mk*/ 
LOCAL_MODULE := linker 
LOCAL_MODULE_STEM_32 := linker 


LOCAL_MODULE_STEM_64 := linker64 
LOCAL_MULTILIB := both 


include $(BUILD_EXECUTABLE) 


接 下 来 我 们 结合 Li nker 来 讲解 Android 中 动态 库 的 隐 式 调用 和 链接 
流程 。Android 系 统 中 的 进程 和 普通 的 Linux 进 程 本 质 上 并 没有 什么 不 
同 ， 它 们 在 启动 时 都 会 调用 系统 接口 execv 来 执行 具体 的 程序 代码 。 孙 
数 execv 经 过 一 系列 处 理 后 ， 先 进入 load_elf_binary 加 载 ELF 文 件 ， 继 
而 又 调用 1oad_elf_interp。 后 面 这 个 函数 负责 从 目标 程序 的 . interp 区 
段 中 将 指定 的 动态 链接 器 加 载 到 内 存 中 ， 并 进入 1oad_elf_interp 的 返 


回 值 “也 就 是 Linker 的 入 口 点 ) 中 执行 。 这 和 我 们 前 面 小 节 分 析 的 
Linux 中 动态 库 的 加 载 过 程 是 一 致 的 。 


此 时 程序 就 成 功 地 从 内 核 态 转 入 用 户 态 了 一 一 换 句 话说 ， 程 序 主体 
部 分 的 加 载 工 作 是 由 操作 系统 在 内 核 态 直接 完成 的 ， 而 对 于 动态 链接 库 
的 加 载 和 处 理 权 利 则 将 交 由 “用 户 ”， 即 Linker 来 掌控 。 


Linker 的 入 口 地址 对 应 的 是 begin. S$ 中 的 _start 函 数 ， 它 会 进一步 
调用 _1inker_init 来 进行 初始 化 ， 包 括 解决 Linker 自 身 的 重 定位 问 
题 。 这 里 就 出 现 了 一 个 有 趣 的 现象 : 因为 Linker 的 职责 之 一 就 是 帮助 程 
序 的 其 他 模块 实现 对 外 部 对 象 的 引用 问题 ， 所 以 在 它 初始 化 时 ， 能 完成 
重 定 位 任务 的 “ 鸡 ” 显 然 还 没 “ 生 ”出 来 〈 解 决 这 类 问题 的 方法 又 被 称 
为 自 举 代码 ) 。 所 以 在 _1inker_init 初 始 化 完成 之 前 ，Linker 不 能 访 
问 任何 外 部 变量 、 函 数 ， 否 则 将 导致 segfault 的 运行 时 错误 。 


因为 Linker 本 身 也 是 一 个 ELF 格 式 的 文件 ， 所 以 其 内 部 结构 亦 遵 从 
ELF 规 范 ， 这 些 信息 会 被 收集 到 一 个 名 为 1inker_so 的 soinfo 结 构 体 变量 
中 。 接 着 linker init 通 过 prelink_image 来 解析 1inker 文 件 中 的 
dynamic 区 段 信 息 ， 并 做 好 各 项 Sanity Checks 〈 例 如 : Linker 不 能 依赖 
于 其 他 动态 库 ， 因 而 DT_NEEDED 的 数量 只 能 为 0， 否 则 就 会 触发 Sanity 错 
误 ) 。 紧 接着 1inker 就 可 以 在 1ink_image 中 进行 针对 自身 的 重 定位 工作 
了 ， 大 家 可 以 阅读 源码 了 解 具 体 的 实现 细节 。 一 旦 Linker 的 自 举 成 功 完 
成 后 ， 它 就 可 以 放心 地 调用 外 部 男 数 来 实现 其 核心 功能 动态 链接 
了 ， 上 有 具体 的 函数 实现 在 _|1inker_init_post_relocation 中 。 简 单 而 
言 ，Linker 会 按 如 下 优先 级 去 多 个 路 径 下 查找 程序 所 依赖 的 动态 库 : 


e DT RPATH 





这 是 包含 在 dynamic 区 段 中 的 一 个 表 项 信息 。 


LD_LIBRARY_PATH 


这 是 一 个 系统 环境 变量 ， 可 以 通过 getenv 函 数 来 获取 。 


LD_PRELOAD 


这 也 是 一 个 系统 环境 变量 。 不 过 出 于 安全 原因 的 考虑 ， 如 果 程 序 设 
置 了 setuid/setgid， 那 么 这 两 个 环境 变量 都 会 被 忽略 。 


。 其 他 缺 省 目录 


这 个 查找 过 程 同 时 还 会 按照 广度 优先 的 搜索 顺序 来 递归 解决 动态 库 
对 其 他 库 的 依赖 关系 。 另 外 ， 加 载 动态 库 文件 只 是 其 中 的 一 个 环节 ， 另 
一 个 关键 步骤 就 是 对 这 些 库 执行 链接 操作 ， 即 soinfo: :1ink_image 所 需 
要 完成 的 任务 。 这 同时 也 是 Android 系 统 和 Linux 内 核 有 差异 的 地 方 : 后 
者 采用 的 是 Lazy Binding 的 方式 ， 意 即 只 有 等 到 PLT 表 中 的 元 素 第 一 次 
被 执行 时 ， 才 会 去 解析 获取 真实 的 地 址 ; 而 Android 系 统 则 在 开始 时 就 
直接 将 G0T 中 的 元 素 全 部 解析 完成 。 这 一 点 我 们 从 Linker. cpp 代 码 中 也 
可 以 得 到 验证 ， 如 下 所 示 : 


/*bionic/linker/linker.cpp*/ 
bool soinfo::prelink_image() {... 
case DT_PLTGOT: 
#if defined(__mips__) 
// Used by mips and mips64. 
plt_got_ = reinterpret_cast<Elfw(Addr)**>(load_bias + d-> 
#endif 
// Ignore for other platforms... (because RTLD_LAZY is no 
break; 


一 旦 Link 工 作成 功 完成 ， 程 序 束 可 以 正常 使 用 这 些 隐 式 调用 的 动态 
链接 库 了 。 其 中 还 有 很 多 实现 细节 ， 建 议 大 家 可 以 自行 结合 源码 来 阅读 
理解 。 
21.3.3.2 Android 中 动态 库 的 显 式 调用 与 链接 


动态 链接 库 的 显 式 调用 指 的 是 程序 利用 操作 系统 提供 的 接口 ， 在 运 
行 过 程 中 主动 加 载 动态 链接 库 的 过 程 。Android 系 统 提供 的 动态 库 的 显 
式 调用 方法 包括 但 不 限于 : 


e Java 层 : System.loadLibtary 和 System.load 


如 果 开 发 人 员 需 要 在 Java 层 发 起 对 so 动态 链接 库 的 加 载 动 作 ， 那 么 
可 以 使 用 System 包 提 供 的 loadLibrary 或 者 1oad 接 口 。 这 两 个 函数 的 原 
型 如 下 : 


static void loadLibrary (String libName); 
static void load (String pathName ) ; 


loadLibrary 和 1oad 之 间 的 差异 主要 体现 在 函数 人 参数 上 一 一 前 者 只 
需要 指出 动态 链接 库 的 名 称 就 可 以 了 ， 系 统 会 负责 在 预先 设置 的 路 径 中 
去 查找 并 加 载 正 确 的 so 库 ; 相对 而 言 1oad 则 为 开发 者 提供 了 更 灵活 的 方 
式 ， 人 允许 开发 者 将 动态 库存 储 到 任何 程序 有 权限 访问 的 地 方 ， 并 由 
pathName 给 出 完整 的 加 载 路 径 。 


值得 一 提 的 是 ，1oadLibrary 和 1oad 这 两 个 涵 数 在 Native 层 也 一 定 
会 有 对 应 的 实现 一 一 那么 包含 它们 的 so 库 又 是 在 什么 时 候 、 如 何 被 加 载 
的 呢 ? 答案 是 Runt ime 在 局 动 过 程 中 通过 LoadNative Library 来 加 载 名 
FRA “libjavacore. so” 的 动态 链接 库 ， 后 者 就 是 Java 层 这 两 个 常用 加 
载 函 数 的 实现 主体 。 


e Native 层 : dlopen 等 标准 接口 


Android 是 基于 Linux 实 现 的 ， 因 而 它 也 支持 类 似 dlopen、dlsym 等 
标准 的 动态 链接 库 操作 接口 。 


建议 大 家 可 以 从 虚拟 机 全 局 的 角度 来 理解 Android 中 的 动态 链接 
库 ， 或 许可 以 取得 更 好 的 效果 。 示 意 如 图 21-39 所 示 。 





Android 程序 


AA21-39 ”从 虚拟 机 层面 理解 动态 链接 库 


本 小 证 接 下 来 的 内 容 将 按照 以 下 两 条 线索 来 组 织 : 


第 一 ， 我 们 将 向 大 家 介绍 Android N 版 本 中 一 个 重要 的 特性 更 新 : 
即 如 何 利用 命名 空间 (Namespace) 来 阻止 程序 访问 非法 的 NDK 接 口 ; 


第 二 ，System. loadLibrary 是 应 用 程序 最 常用 的 动态 库 加 载 消 数 ， 
所 以 我 们 将 以 此 为 突破 口 ， 通 过 分 析 它 的 内 部 实现 来 达到 两 个 目的 : 向 
大 家 展示 上 述 Namespace 机 制 是 如 何 发 挥 作 用 的 ; 以 及 理解 Android 系 统 
对 动态 链接 库 的 显 式 调用 链接 过 程 。 


Goog1e 为 什么 在 Android N 版 本 限制 程序 访问 非法 〈 如 Non- 
Public) 的 NDK 接 口 呢 ? 


这 是 因为 非法 〈 如 Non-Public) 的 NDK 无 论 从 接口 形式 或 是 内 部 实 
现 来 看 都 有 可 能 随 着 Android 版 本 的 更 新 换代 而 发 生 改 变 ， 从 而 导致 依 
赖 它们 的 程序 产生 不 可 预期 的 致命 问题 。Android 系 统 从 0penSSL 切 换 到 
Bor ingSSL 就 是 一 个 很 好 的 范例 一 一 所 有 直接 依赖 于 前 者 所 提供 的 动态 
库 文 件 的 程序 都 有 可 能 在 某 些 Android 设 备 上 无 法 正常 工作 。 


个 过 Android N 版 本 暂时 没有 采用 “一 棒子 打 死 ”的 暴力 机 制 〈 即 
直接 禁止 这 种 非法 事件 的 发 生 ) ， 而 是 为 那些 执行 了 非法 引用 的 程序 提 
供 了 各 种 警告 信息 。 所 以 当 程序 中 出 现 了 如 下 所 示 的 Error 日 志 时 ， 开 
发 人 员 就 应 该 特别 注意 了 : 


(1) Example Java error: 


java. lang. UnsatisfiedLinkError: dlopen failed: library 
"/system/|ib/|ibcutils. so" 


is not accessible for the namespace "class|oader- 
namespace" 


(2) Example NDK error: 


dlopen failed: cannot locate symbol 
"system property get" referenced by ... 


另外 警告 信息 还 会 以 U1 弹 窗 的 方式 在 Android 设 备 中 显示 ， 以 达到 
更 好 的 警示 效果 。 


那么 Android 系 统 判定 程序 引用 了 非法 接口 的 依据 是 什么 呢 ? 接 下 


来 我 们 将 结合 System，1oadLibrary 的 内 部 实现 来 为 大 家 揭 开 谜底 。 


Java 国 数 System. 1oadLibrary 首 先 会 调用 
Runtime. getRuntime(). 1oadLibrary0， 后 者 又 分 别 经 过 doLoad 和 
nativeLoad 进 入 到 Native 层 ， 对 应 代码 如 下 : 


/*libcore/ojluni/src/main/native/Runtime.c*/ 
Runtime_nativeLoad(JNIEnv* env, jclass ignored, jstring javaFilen 

jobject javaLoader, jstring javaLibrarySearchPath 
{ 


} 


return JVM_NativeLoad(env, javaFilename, javaLoader, javaLibr 


为 了 保证 后 向 兼容 性 ，JVM_Nat i veLoad 会 根据 当前 程序 所 面向 的 
SDK 版 本 来 决定 是 否 要 沿用 之 前 的 动态 库 处 理 方式 Cversion<=23) ， 即 
不 强制 采用 Namespace 机 制 |。 


随后 JVM_Nat iveLoad 通 过 JavaVM 中 的 LoadNat iveLibrary 进 入 下 一 
步 工 作 ， 其 核心 源码 实现 如 下 所 示 : 


/*art/runtime/java_vm_ext.cc*/ 
bool JavaVMExt::LoadNativeLibrary(JNIEnv* env, 
const std::string& path, 
jobject class_loader, 
jstring library_path, 
std::string* error_msg) {... 
SharedLibrary* library; 
Thread* self = Thread::Current(); 


// TODO: move the locking (and more of this logic) into Libra 
MutexLock mu(self, *Locks::jni_libraries_lock_); 
library = libraries_->Get(path); // 首 先 判断 是 否 已 经 加 载 过 这 个 Libr: 





} 


Locks: :mutator_lock_->AssertNotHeld(self); 

const char* path_str = path.empty() ? nullptr : path.c_str(); 

void* handle = android: :OpenNativeLibrary(env, 
runtime_->GetTargetSdkVersio 
path_str, 
class_loader, 
library_path);// 





bool needs_native_bridge = false; // 是 否 需要 Native Bridge 的 辅助 
if (handle == nullptr) {// 进 入 此 分 支 说 明 前 述 通 过 正常 途径 打开 1ibrary 失 








if (android: :NativeBridgeIsSupported(path_str)) { 
handle = android: :NativeBridgeLoadLibrary(path_str, RTLD_NO 
needs_native_bridge = true; 
} 
} 


bool created_library = false; 


// Create SharedLibrary ahead of taking the libraries lock to 
ordering. 
std: :unique_ptr<SharedLibrary> new_library( 
new SharedLibrary(env, self, path, handle, class_loader, 
class_loader_allocator)); 
/* 可 能 有 多 个 线程 都 在 尝试 打开 1ibrary, 需要 保证 竞争 条 件 下 的 正确 性 */ 
MutexLock mu(self, *Locks::jni_libraries_lock_); 
library = libraries_->Get(path); 
if (library == nullptr) { // We won race to get libraries_lo 
library = new_library.release(); 
libraries_->Put(path, library); 
created_library = true; 


























} 


bool was_successful = false; 

void* sym; 

if (needs_native_bridge) { 
library->SetNeedsNativeBridge(); 


} 
sym = library->FindSymbol("JNI_OnLoad", nullptr); 


library->SetResult(was_successful); 
return was_successful; 


LoadNativeLibrary 的 目标 用 一 句 话 来 概况 ， 就 是 党 试 利 用 各 种 可 
能 的 手段 去 加 载 动态 链接 库 ， 然 后 找到 并 执行 其 中 的 JN1_0nLoad 接 口 
这 个 函数 是 Jni 库 的 首选 入 口 ， 开 发 人 员 通 常会 利用 它 来 完成 一 系 
列 的 初始 化 操作 。 不 过 系统 并 不 要 求 它 必须 存在 ， 所 以 即便 是 最 终 找 不 
P a a 
IEX) 。 


细心 的 读者 一 定 已 经 发 现 了 LoadNativeLibrary 中 充斥 着 大 

量 “Native Bridge” 相 关 的 代码 。 简 单 来 说 这 项 技术 用 于 处 理 当 前 系 
统 平 台 的 指令 集 和 目标 对 象 (Library) 的 指令 集 不 一 致 时 的 兼容 性 问 
题 。 举 个 例子 来 说 ，Android 模 拟 器 为 了 达到 提速 的 目的 ， 通 常会 编译 





成 X86 版 本 来 直接 运行 于 开发 机 之 上 ; 那么 问题 就 来 了 ， 对 于 一 个 只 提 
供 了 Arm 版 本 的 动态 链接 库 文 件 的 APK 来 说 ， 如 何 保证 它 也 可 以 在 X86 模 
拟 器 上 正常 运行 呢 ? 这 就 是 Native Bridge 所 要 解决 的 问题 了 ， 它 负责 
在 两 种 不 同 的 指令 集 之 间 建 立 起 一 个 “桥梁 ”， 以 此 来 保证 双方 的 兼容 
性 Se ive Bridge 还 有 专门 的 介绍 ， 我 们 这 里 先 不 做 过 多 
[Siz 


抛 开 与 Native Bridge 相 关 的 处 理 ，LoadNativeBridge 就 容易 理解 
了 。 它 首先 会 判断 目标 Library 是 否 曾 经 已 经 被 加 载 过 ， 依 据 在 于 
libraries—->Get (path) 是 否 为 空 。 其 中 libraries 是 用 于 管理 所 有 已 
加 载 链 接 库 的 全 局 变量 。 不 过 即便 Library 曾 经 被 加 载 过 ， 也 还 需要 特 
别 注意 以 下 两 种 情况 : 


。 之 前 加 载 Library 时 使 用 的 Class Loader 和 当前 的 Class Loadet 不 一 致 时 
根据 Java 规 范 的 要 求 ， 同 一 个 Library 是 不 能 被 多 个 Class Loader 


所 加 载 的 。 因 而 这 种 情况 下 LoadNativeBridge 的 返回 值 是 false， 表 示 
本 次 Class Loader EZ EM. 





e 两 个 Class Loadet 一 致 的 情况 


说 明之 前 这 个 Class Loader 已 经 “拥有 ”了 目标 Library 的 “控制 
权 ”， 所 以 LoadNativeBr idge 直 接 返 回 true。 


交 由 1ibraries_ 管 理 的 实际 上 是 一 个 SharedLibrary 对 象 ， 后 者 包 
含 了 与 目标 库 相 关 的 更 多 信息 。 例 如 Library 对 应 的 Class Loader 是 
谁 ， 是 否 需 要 Native Bridge， 对 象 库 的 路 径 等 。 创 建 SharedLiabrary 
的 过 程 中 还 有 一 个 需要 注意 的 地 方 ， 即 如 果 有 其 他 线程 也 在 尝试 加 载 相 
同 的 动态 链接 库 时 ， 就 需要 使 用 Locks::jni_libraries_lock_ 锁 来 保护 
资源 竞争 的 情况 下 不 出 异常 。 


从 LoadNativeLibrary 的 源码 不 难看 出 ， 正 常 途 径 下 加 载 1ibrary 利 
用 的 是 0penNativeLibrary 这 个 函数 。 这 同时 也 是 Android N 版 本 中 新 增 
的 一 个 函数 ， 用 于 替代 旧版 本 中 直接 使 用 dlopen 来 加 载 动 态 库 的 方式 : 


/*system/core/libnativeloader/native_loader.cpp*/ 
void* OpenNativeLibrary(JNIEnv* env, 
int32_t target_sdk_version, 
const char* path, 


jobject class_loader, 
jstring library_path) { 
#if defined(__ANDROID__ ) 
UNUSED(target_sdk_version); 
if (class_loader == nullptr) { 
return dlopen(path, RTLD_NOW); 
} 


std::lock_guard<std: :mutex> guard(g_namespaces_mutex); 
android_namespace_t* ns = g_namespaces->FindNamespaceByClassLoa 


if (ns == nullptr) { 

ns = g_namespaces->Create(env, class_loader, false, library_p 

if (ns == nullptr) { 
return nullptr; 


} 
} 


android_dlextinfo extinfo; 
extinfo.flags = ANDROID_DLEXT_USE NAMESPACE; 
extinfo.library_namespace = ns; 


return android_dlopen_ext(path, RTLD_NOW, &extinfo); 

#else 
UNUSED(env, target_sdk_version, class_loader, library_path); 
return dlopen(path, RTLD_NOW); 

#endif 


t 


iA ACES ES AY AES $8 CCAR eB: 首先 利用 
FindNamespaceByClassLoader 来 查找 当前 ClassLoader 是 否 有 相关 联 的 
Namespace (所 有 Namespace 都 保存 在 LibraryNamespaces 中 一 个 名 为 
namespaces_ 的 全 局 变量 中 ) 。 如 果 答 案 是 肯定 的 话 ， 那 么 接 下 来 就 可 
以 调用 android_dlopen_ext 直 接 进 入 下 一 步 ; 否则 我 们 还 需要 通过 
g_namespaces->Create 来 创建 一 个 Namespace。 需 要 注意 的 是 ， 因 为 系 
统 在 创建 ClassLoader 时 会 同时 申请 Namespace (ARATE py Aye 
CreateClass LoaderNamespace) ， 所 以 只 有 某 些 特殊 情况 下 才 会 出 现 
ns==nul |ptr 的 情况 。 


NameSpace 的 数据 结构 定义 如 下 所 示 : 


struct android_namespace_t {... 
private: 
const char* name_; //NameSpace% x 














bool is_isolated_; // 是 否 需要 隔离 。 非 隔离 情况 下 可 以 访问 所 有 1Library 
std::vector<std:!:string> 1d_libprary_paths_，V// 程 序 的 链接 路 径 
std::vector<std::string> default_library_paths_; // 默 认可 访问 的 路 
std::vector<std::string> permitted_paths_; // 被 允许 访问 的 路 径 
soinfo::soinfo_list_t soinfo_1list_，V// 己 经 加 载 了 的 Library 所 组 成 的 责 


按照 Android 系 统 的 设计 ，NameSpace 主 要 包括 下 面 4 类 : public, 


default, anonymous, classloader. 


它们 的 定义 分 别 如 下 所 示 : 





e (1) Public Namespace 


Pub | ic 类 型 的 Namespace 实 际 上 并 不 属于 android_namespace 七 对 
象 ， 而 只 是 一 个 公共 的 1ibrary 库 列表 。 通 常情 况 下 ， 系 统 会 从 以 下 两 
个 路 径 中 加 载 获取 公共 库 列 表 : 


/etc/public.libraries.txt 
/vendor/etc/public.libraries.txt 


e (2) Default Namespace 


const char* name_: "(default)" 
bool is_isolated_: false 


std: :vector<std: :string> Id_library_paths_:kDefaultLdPaths 
或 者 kAsanDefaultLdPaths 


e kDefaultLdPaths 和 kAsanDefaultLdPaths 是 两 个 预 设 的 列表 ， 根 据 当 前 
所 用 linket 种 类 的 不 同 来 区 分 。 其 中 kDefaultLdPaths 的 定义 如 下 : 


static const char* const kDefaultLdPaths[] = { 
#if defined(__LP64_ ) 
"/system/1ib64", 
"/vendor/1ib64", 
#else 
"/system/1lib", 
"/vendor/lib", 
#endif 
nullptr 


}; 


std: :vector<std::string> default library paths : 和 上 述 
Id library paths 赋值 相同 


std: :vector<std: :string> permitted_paths_: NULL 


e (3) Classloader Namespace 


前 面 提 到 的 g_namespaces->Create 虽 然 也 用 于 生成 这 种 类 型 的 
Namespace， 不 过 正常 情况 下 系统 会 在 加 载 APK 时 就 预先 创建 一 个 
ClassLoader 以 及 与 之 关联 的 Namespace。 这 个 过 程 的 流程 图 如 图 21-40 
所 示 。 
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全 图 21-40 APK 加 载 过 程 中 的 hamespace 创 建 


LoadedApk 用 于 管理 应 用 程序 的 APK 资 源 ， 它 通过 
ApplicationLoaders 来 管理 应 用 层 创建 的 ClassLoaders 这 些 Class 
Loader 多 数 属 于 PathClassLoader， 而 且 还 会 同步 生成 与 之 相关 联 的 
NameSpace。 





我 们 将 getClassLoader@LoadedApk. java 函 数 中 与 Namespace 相 关 的 
部 分 摘录 如 下 : 


public ClassLoader getClassLoader() {... 
mClassLoader = ApplicationLoaders.getDefault().getCla 
mApplicationIinfo.targetSdkVersion, isBundledA 
librarySearchPath, libraryPermittedPath, mBas 


其 中 1ibrarySearchPath 是 指 App 中 JNI Libraries 所 存放 的 路 径 
(lnstrumentation 的 情况 会 略 有 差异 ) ; libraryPermittedPath 则 是 
系统 分 配给 App 的 /data 目 录 下 用 于 保存 数据 的 具体 路 径 。 另 外 ， 系 统 程 
序 可 访问 的 1ib 范 围 比 第 三 方程 序 要 大 得 多 ， 这 是 利用 如 下 语句 做 到 

的 : 


if (mApplicationInfo.isSystemApp()) { 
isBundledApp = true; 
libPaths.add(System.getProperty("java.library.path 
libraryPermittedPath += File.pathSeparator + 
System.getProperty("java. 
} 


这 样 一 来 ，Class Loader Namespace 中 各 项 参数 的 定义 如 下 : 
const char* name_: " classloader-namespace" 

bool is_isolated_: true 

std: :vector<std::string> Id_library_paths_: NULL 


std: :vector<std::string> default library paths : 同上 面 的 
| ibrarySearchPath 


std: :vector<std::string> permitted paths_: 同上 面 的 


| ibraryPermittedPath 


我 们 再 回 到 0penNat iveLibrary 中 继续 分 析 。 如 果 当 前 环境 是 
Android 系 统 ， 那 么 下 一 步 将 调用 android_dlopen_ext; 否则 直接 使 用 
dlopen 这 个 标准 接口 。 这 两 个 函数 的 功能 是 基本 一 致 的 ， 因 而 我 们 挑选 
dlopen 来 做 一 下 讲解 。 它 的 函数 原型 如 下 : 


void* dlopen(const char* filename, int flag); 


第 一 个 参数 fi lename 表 示 要 打开 的 动态 库 的 名 称 ; 另 一 个 参数 flag 
的 可 选 值 和 释义 如 表 21-7 所 示 。 


表 21-7 dlopen 的 flag 参 数 释义 


延迟 绑 定 ， 即 直到 引用 对 象 被 执行 时 再 
进行 解析 操作 。 换 句 话 说， 如 果 目 标 对 
象 一 直 未 被 执行 ， 那 么 它 将 永远 不 会 得 
到 解析 。 需 要 注意 的 是 ， 这 个 选项 只 对 
函数 引用 有 效 ， 变 量 引用 则 总 是 会 被 立 
即 解析 

当 指 定 了 此 标志 ， 或 者 设置 了 环境 变量 
LD_BIND_NOW， 那 么 动态 库 中 的 所 有 
pe emer eet 














这 个 动态 库 中 定义 的 符号 对 于 后 续 加 载 
的 其 他 动态 库 都 是 可 用 的 

作用 范围 的 默认 值 。 它 的 含义 和 上 面 一 
项 正好 相反 ， 即 当前 动态 库 中 定义 的 符 
a 
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另外 ，dlopen 还 支持 将 它 的 第 一 个 函数 参数 设置 为 NULL， 这 种 情况 





下 获取 到 的 返回 值 代表 的 是 主 程序 的 句柄 。 利 用 这 个 返回 值 来 进一步 调 
用 dl sym() ， 意 味 着 开发 者 希望 在 主 程序 中 搜索 Symbols 搜寻 顺序 首 
先是 考虑 程序 启动 时 加 载 的 所 有 动态 共享 库 ， 然 后 是 那些 通过 dlopen 打 
开 且 指定 了 RTLD_GLOBAL 标 志 的 动态 库 。 


在 Android 系 统 中 ，android dlopen_ext 又 将 调用 dlopen_ext， 继 
而 进入 do_dlopen 执 行动 态 库 的 加 载 和 链接 过 程 〈 其 原理 与 前 面 小 节 介 
绍 的 显 式 加 载 和 链接 过 程 本 质 上 并 没有 太 多 区 别 ， 有 兴趣 的 读者 可 以 自 
行 分 析 其 中 的 代码 实现 ) 。 


我 们 这 里 重点 分 析 一 下 do_dlopen 中 与 Namespace 相 关 的 实现 : 


/*bionic/linker/linker.cpp*/ 
void* do_dlopen(const char* name, int flags, const android_dlexti 
void* caller_addr) { 
soinfo* const caller = find_containing_library(caller_addr); 





android_namespace_t* ns = caller != nullptr ? caller->get_names 
if (extinfo != nullptr) 4.. 
if ((extinfo->flags & ANDROID_DLEXT_USE_NAMESPACE) != 0) { 

if (extinfo->library_namespace == nullptr) { 
DL_ERR(...); 
return nullptr; 

} 

ns = extinfo->library_namespace; 


} 


soinfo* si = find_library(ns, name, flags, extinfo, caller); 
if (si != nullptr) { 

si->call_constructors(); 

return si->to_handle(); 
} 


return nullptr; 


首先 通过 find_containing_library 来 找 出 调用 者 所 属 的 模块 ， 判 
断 的 依据 是 调用 者 所 在 的 地 址 属于 哪个 区 域 。 紧 接 着 可 以 分 为 两 种 情 


YL: 


e caller != nullptr 


这 种 情况 下 我 们 直接 利用 get_namespace 来 获取 调用 者 的 NameSpace 
对 象 ， 后 者 则 是 So 文件 在 加 载 过 程 中 分 配 的 ， 而 且 通 常 被 调用 者 的 Name 
Space 还 会 继承 于 它 的 调用 者 。 换 名 话说 ，ELF 中 的 首 个 程序 模块 〈 即 程 
序 主体 ) 是 本 程序 所 能 获得 的 权限 范围 的 关键 。 


按照 Android 系 统 的 设计 ， 首 个 程序 模块 〈 带 有 标志 FLAG_EXE) 将 
在 _1inker_init_post_relocation 中 完成 它 的 默认 权限 配置 ， 并 将 结 
果 保 存在 名 为 g_default_namespace 的 全 局 变量 中 。 


e caller == nullptr 


如 果 调 用 方 没有 相关 联 的 Namespace， 那 么 直接 使 用 Anonymous 
Name Space， 这 或 许 也 是 它 的 名 称 中 “匿名 ”所 要 表达 的 含义 。 


不 过 上 述 得 到 的 Namespace 可 能 还 不 是 最 终 的 结果 ， 这 取决 于 
extinfo 中 的 标志 ANDRO1D_DLEXT_USE_NAMESPACE 是 否 有 效 。 比 如 在 我 们 
这 个 场景 下 ，0penNativeLibrary 就 设置 了 自己 的 ClassLoader 
Namespace， 因 而 此 时 将 优先 使 用 后 面 这 个 值 。 


经 过 上 述 这 些 步骤 ， 现 在 我 们 已 经 可 以 确定 出 此 次 加 载 动态 库 的 所 
对 应 的 正确 的 Name Space 了 。 接 下 来 要 做 的 就 是 把 这 个 结果 应 用 到 查找 
过 程 中 ， 即 find_library 的 实现 里 。 搜 寻 单 个 1ibrary 或 者 多 个 |ibrary 
实际 上 都 会 调用 到 find_libraries， 只 不 过 它们 在 调用 函数 时 的 参数 会 
有 所 区 别 。 


函数 find_libraries 也 同样 适用 于 隐 式 调用 过 程 。 它 的 处 理 过 程 比 
较 复 杂 ， 主 要 分 为 5 个 核心 步骤 ， 其 中 与 动态 库 加 载 操作 有 直接 关联 的 
是 find_library_internal。 后 者 首先 会 分 析 需 要 被 加 载 的 动态 库 是 否 
在 Public Namespace (g public_namespace) 中 ， 如 果 是 的 话 就 表示 目 
标 对 象 已 经 加 载 成 功 了 【因为 这 些 公共 库 会 被 预先 加 载 ); 否则 就 通过 
load_library 来 定位 并 加 载 目 标 动态 库 。 不 过 前 提 条 件 是 程序 通过 了 非 
法 接口 访问 的 检查 ， 具 体 的 判断 远 辑 如 下 所 示 : 


如 果 NameSpace 不 是 isolated 的 话 ， 则 有 权限 访问 指定 的 libtatry; 
否则 如 果 library 在 ld 路 径 下 ， 也 有 权限 访问 ; 

否则 如 果 library 在 Default Library Paths 目 录 中 ， 也 有 权限 访问 ; 
# Ml AA library% Permitted Paths 中 ， 同 样 有 权限 访问 ; 


。 除 以 上 几 种 情况 外 ， 都 无 权 访 问 指定 的 libraty。 


一 切 准 备 就 绪 后 ， 我 们 就 可 以 通过 dlsym 来 查找 加 载 的 动态 库 中 是 
否 包 含 JNI1_0nLoad 入 口 函 数 了 。 如 前 所 述 ，JNI_0nLoad 并 非 强 制 要 求 
的 ， 所 以 即便 没有 找到 也 不 会 产生 致命 问题 。 


为 了 帮助 大 家 理解 System. 1oad 的 整个 处 理 逻 辑 ， 我 们 特别 提供 下 
面 的 流程 图 ， 如 图 21-41 所 示 。 





JavaVMExt | | native loader 
| 






| 
| 
| 
| 
| 
| 
| 
| 
| 
a | 
LoadNativeLibrary | 
| 


OpeaNatveLibraty 








| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
Finda La 
| 






find libraries 


find. library intemal 


全 图 21-41 动态 库 的 显 式 调 用 流程 


理解 了 动态 链接 库 的 加 载 流 程 后 ， 本 小 节 的 最 后 我 们 再 进一步 分 析 
Java 中 声明 为 native 的 函数 是 如 何 与 本 地 层 中 的 具体 实现 建立 起 正确 的 
映射 关系 的 。 这 同时 也 是 JNI 所 要 解决 的 核心 问题 之 一 。 通 过 前 面 内 容 
的 学 习 我 们 知道 ，JNI1_0nLoad 是 动态 链接 库 的 “入 口 地 址 ”， 通 常用 于 
完成 一 些 初始 化 操作 〈 包 括 注册 JN1 函 数 ) 。 壁 如 下 面 是 从 Android 工 程 
中 摘 取 的 其 中 一 个 典型 范例 : 


/*frameworks/base/media/jni/android_media_MediaPlayer .cpp*/ 
jint JNI_OnLoad(JavaVM* vm, void* /* reserved */) 


{ 
JNIEnv* env 
jint result 


NULL; 
-1 


. 
了 


if (register_android_media_MediaPlayer(env) < 0) { 
ALOGE( "ERROR: MediaPlayer native registration failed\n"); 
goto bail; 

} 


MediaPlayer 的 JNI_0nLoad 实 现 中 有 很 多 register XX XX 格式 的 注 
Hee, Ele FERNI eA: 


/*frameworks/base/media/jni/android_media_MediaPlayer.cpp*/ 
static int register_android_media_MediaPlayer(JNIEnv *env) 


return AndroidRuntime: :registerNativeMethods(env, 
"android/media/MediaPlayer", gMethods, NELEM(gMet 


Media Player 通 过 AndroidRuntime:: registerNativeMethods 来 将 
JNI 中 的 函数 注册 到 虚拟 机 中 ， 这 个 函数 实际 上 是 对 
jniRegisterNativeMethods 的 一 个 中 转 〈 在 条 件 允 许 的 情况 下 ，JNI 也 
可 以 直接 调用 jniRegisterNativeMethods) ， 后 者 的 实现 如 下 : 


/*libnativehelper/JNIHelp.cpp*/ 
extern "C" int jniRegisterNativeMethods(C_JNIEnv* env, const char 
const JNINativeMethod* gMethods, int numMethods) 


JNIEnv* e = reinterpret_cast<JNIEnv*>(env); 
ALOGV("Registering %s's %d native methods...", className, num 


scoped_local_ref<jclass> c(env, findClass(env, className) ); 


if ((*env)->RegisterNatives(e, c.get(), gMethods, numMethods) 
char* msg; 
asprintf(&msg, "RegisterNatives failed for '%s'; aborting 
e->FatalError(msg); 


i 


return 0; 


变量 env 是 一 个 JNIEnv 对 象 ， 它 是 在 JNI_0nLoad 中 通过 JavaVM 获 取 
到 的 ， 而 且 是 线程 独立 的 : 


/*art/runtime/jni_internal.cc*/ 
static jint RegisterNatives(JNIEnv* env, jclass java class, const 
methods, jint method_count) { 
return RegisterNativeMethods(env, java_class, methods, method 


} 


static jint RegisterNativeMethods(JNIEnv* env, jclass java_clas 
JNINativeMethod* methods, jint method_count, bool return_errors) 
CHECK_NON_NULL_ARGUMENT_FN_NAME("RegisterNatives", java_class 
ScopedObjectAccess soa(env); 
mirror::Class* c = soa.Decode<mirror::Class*>(java_class); 





CHECK_NON_NULL_ARGUMENT_FN_NAME("RegisterNatives", methods, J 
for (jint i = 0; i < method_count; ++i) { 

const char* name = methods[i].name; 

const char* sig = methods[i].signature; 

const void* fnPtr = methods[i].fnPtr; 





bool is_fast = false; 


if (*sig == '!') { 
is_fast = true; 
++S1g; 

} 


ArtMethod* m = nullptr; 
bool warn_on_going_to_parent = 
down_cast<JNIEnvExt*>(env) ->vm->IsCheckJniEnabled(); 
for (mirror::Class* current_class = Cc; 
current_class != nullptr; 
current_class = current_class->GetSuperClass()) { 
// Search first only comparing methods which are native. 
m = FindMethod<true>(current_class, name, sig); 
if (m != nullptr) { 


break; 


} 


// Search again comparing to all methods, to find non-nat 
m = FindMethod<false>(current_class, name, sig); 
if (m != nullptr) { 

break; 


t 
} 
m->RegisterNative(fnPtr, is_fast); 


} 
return JNI_OK; 


注册 过 程 的 目的 是 建立 Java 了 水 数 与 Native 逊 数 之 间 的 对 应 关系 ， 
此 不 难 推断 出 Register NativeMethods 上 首先 要 解决 的 问题 是 如 何 查找 到 
Class% (Bljava_class) 中 的 Java 层 函数 。 另 外 ， 
Regi sterNativeMethods 面 对 的 并 非 单 个 函数 ， 而 是 一 个 范 数 集合 
methods。 集 合 中 的 每 个 元 素 都 是 JNINativeMethod 对 象 ， 它 们 包含 了 
Java 函 数 名 ，Signature 〈 将 Java 函 数 的 返回 值 和 参数 表述 成 字符 串 的 
一 种 方式 ) 以 及 native 国 数 原 型 ， 范 例如 下 : 


{"_setDataSource","(Ljava/io/FileDescriptor;JJ)V", (void *)androi 


以 Media Player 中 这 个 例子 来 说 ， 需 要 查找 的 是 名 为 
_setDataSource 的 Java 国 数 ， 它 的 Signature 刚 
是 “(Ljava/io/FileDescriptor:JJ)V”。Art 虚 拟 机 中 要 查找 的 是 一 个 
ArtMethod 对 象 ， 并 由 FindMethod 负 责 。FindMethod 我 们 后 续 还 会 有 详 
细 分 析 ， 这 里 只 要 知道 它 的 职责 就 可 以 了 。 


查找 到 ArtMethod 后 ， 我 们 可 以 直接 调用 它 的 Regi sterNative 来 完 
成 注册 工作 。ArtMethod 内 部 有 两 个 配套 的 接口 函数 SetEntryPoi nt 和 
GetEntryPoint， 它 们 分 别 用 于 设置 和 读 取 这 个 ArtMethod 的 “入 口 代 
人 码 ”。 换 名 话说，RegisterNative 所 要 做 的 就 是 将 Native Method 在 内 
存 中 的 地 址 通过 SetEntryPoint 设 置 为 对 应 ArtMethod 的 “JNI 入 口 ”; 
在 JN1 的 环境 下 ， 当 Java 层 中 的 函数 被 调用 后 ， 首 先 会 找到 它 的 
ArtMethod 对 象 ， 然 后 通过 GetEntryPoint 得 到 JN1 入 口 代码 的 地 址 。 


这 样 就 成 功 地 完成 Java 层 函数 与 Native 层 函数 的 JN1 映 射 了 。 


21.3.4 Signal Handler 和 Fault Manager 


MAL i nux 操 作 系统 的 角度 来 看 ，Android 虚 拟 机 可 以 理解 为 它 的 一 个 
应 用 程序 ， 因 而 Li nux 的 信号 处 理 机 制 在 虚拟 机 中 也 同样 适用 。 


Art 虚 拟 机 中 有 一 个 专门 处 理 异常 信号 的 “总 管 ”， 名 为 
fault_manager。 它 会 在 Runtime: :init 中 进行 同步 初始 化 ， 如 下 所 示 : 
/*art/runtime/runtime.cc*/ 


if (!no_sig_chain_) {// 由 虚拟 机 参数 决定 ， 通 常 只 有 在 dex2oat 时 才 会 要 求 不 启 
InitializeSignalChain(); 














if (implicit_null_checks_ || implicit_so_checks_ || implicit_ 
fault_manager .Init(); 
if (implicit_suspend_checks_) { 
new SuspensionHandler (&fault_manager ); 


if (implicit_so_checks_) { 
new StackOverflowHandler(&fault_manager ) ; 


t 


if (implicit_null_checks_) { 
new NullPointerHandler (&fault_manager ); 


if (kEnableJavaStackTraceHandler) { 
new JavaStackTraceHandler (&fault_manager ); 


InitializeSignalChain 简 单 来 说 只 做 了 两 件 事 情 ， 即 : 


dlsym(RTLD_NEXT, "Sigaction"); 
dlsym(RTLD_NEXT, "Sigprocmask"); 


RTLD_NEXT 是 一 个 特殊 的 句柄 参数， 表示 查找 链接 库 中 的 “下 一 
个 ”目标 符号 出 现 的 地 方 。 它 的 典型 使 用 场景 是 程序 希望 自 定 义 一 个 新 
的 函数 来 代替 原先 库 中 的 实现 《有 点 类 似 于 Hook〉。 例 如 ， 上 述 的 
sigaction 和 sigprocmask 都 是 1ibc 库 中 的 固有 函数 ， 而 Android 虚 拟 机 
的 信号 处 理子 系统 对 它们 的 功能 有 所 改进 ， 这 时 候 就 可 以 使 用 
LD_PRELOAD 来 保证 同名 新 函数 所 在 库 〈 即 1ibsigchain) 优先 得 到 加 


载 ， 并 且 利用 RTLD_NEXT 来 寻找 到 原先 的 老 函 数 (分 别 记录 到 全 局 变量 
linked_sigaction_sym 和 |inked_sigprocmask_sym 中 ) . AJN, 
libsigchain 需 要 通过 LOCAL_WHOLE_STATI1C_L1BRAR1ES 链 接 到 
app_process 中 。 


FaultManager 在 初始 化 过 程 中 会 利用 Linux 提 供 的 signal 机 制 来 建 
立信 号 处 理 机 制 |: 


/*art/runtime/fault_manager.cc*/ 
void FaultManager::Init() { 
CHECK(!initialized_); 
struct sigaction action; 
SetUpArtAction(&action);// 


int e = Sigaction(SIGSEGV, &action, &oldaction_); 
if (e != 0) { 
VLOG(signals) << "Failed to claim SEGV: " << strerror(errno); 


// Make sure our signal handler is called before any user handl 
ClaimSignalChain(SIGSEGV, &oldaction_); 
initialized_ = true; 


上 述 的 代码 段 逻 辑 是 ;首先 创建 一 个 sigaction 对 象 GEE: 这 里 
的 sigact ion 是 一 个 struct 结 构 ， 要 与 后 续 的 sigaction 函 数 区 分 开 
来 ) ， 然 后 通过 SetUpArtAct ion 来 对 其 进行 设置 。 紧 接 下 来 的 
sigaction 理 论 上 是 Linux 提 供 的 用 于 登记 信和 号 处 理 函 数 的 AP1 一 一 但 是 
大 家 应 该 要 清楚 这 个 函数 已 经 被 |ibsigchain 中 提供 的 新 函数 替换 掉 
了 ， 新 函数 的 实现 如 人 下: 


/*art/sigchainlib/sigchain.cc*/ 


extern "C" int sigaction(int signal, const struct sigaction* new_ 
if (signal > 0 && signal < _NSIG && user_sigactions[signal].IsC 


(new_action == nullptr || new_action->sa_handler != SIG_DFL 
struct sigaction saved_action = user_sigactions[signal].GetAc 
if (new_action != nullptr) { 


user_Sigactions[signal].SetAction(*new_action, false); 


} 
if (old action != nullptr) { 
*old_action = saved_action; 


J 


return 0; 


if (linked_sigaction_sym == nullptr) { 
InitializeSignalChain()j; 
} 


if (linked_sigaction_sym == nullptr) { 
log("Unable to find next sigaction in signal chain"); 
abort(); 


SigActionFnPtr linked_sigaction = 
reinterpret_cast<SigActionFnPtr>(linked_sigaction_sym); 
return linked_sigaction(signal, new_action, old_action); 


} 
ABZ | libsigchain#3ksigactioneyWA) AA EHAhHE? 


在 计算 机 安全 领域 ，Hacker 们 也 经 常会 通过 截获 函数 〈 人 参考 本 书 安 

全 章节 的 详细 分 析 ) 来 提取 一 些 重要 的 信息 〈 或 者 完成 自己 期 望 的 操 
作 ) ， 而 且 还 不 能 破坏 原先 的 函数 调用 。 这 里 的 做 法 也 是 类 似 的 自 
定义 的 sigaction 在 截获 原水 数 后 ， 会 将 新 的 action 记 录 到 内 部 的 
user_sigactions 数 组 中 ， 然 后 再 调用 真正 的 sigaction 鹃 数 

(linked sigaction) 。 这 样 做 的 目的 是 保证 signal chain 可 以 优先 获 
得 处 理 它 感 兴 趣 的 信号 的 权利 ， 而 不 会 被 上 层 用 户 自己 定义 的 action 所 
复 盖 。 当 然 ， 如 果 在 实际 处 理 信号 的 过 程 中 出 现 signal chain“ 无 能 大 
力 ” 的 情况 ， 那 么 此 时 我 们 也 会 综合 考虑 用 户 设置 的 action 一 一 这 也 是 
设计 user_sigactions 数 组 的 初衷 之 一 。 另 外 ， 大 家 应 该 特别 关注 的 是 
art fault handler， 它 会 作为 $1GSEGV 信 号 的 sa_sigaction 传 递 给 
kerne1， 是 FaultManager 管 理 Handler 的 驱动 力 。 


目前 fault_manager 最 多 管理 4 种 Handler， 它 们 分 别 用 于 处 理 不 同 
的 事件 ， 并 且 全 部 继承 自 FaultHandler。 各 Handler 在 构造 函数 中 会 主 
动 调 用 AddHandler 来 将 自己 添加 到 fault_manager 的 管理 中 。 以 Suspend 
Check 为 例 ， 它 的 主要 作用 是 实现 线程 挂 起 〈 可 以 参见 后 续 的 分 析 ) 。 


当 S1GSEGV 信 和 号 发 生 时 ，kerne1 首 先 会 调用 静态 范 数 
art_fault_handler， 后 者 则 直接 将 信息 传递 给 全 局 变量 fault_manager 


/*art/runtime/fault_handler.cc*/ 
void FaultManager::HandleFault(int sig, siginfo_t* info, void* co 
if (IsInGeneratedCode(info, context, true)) { 
VLOG(Ssignals) << "in generated code, looking for handler"; 








for (const auto& handler : generated_code_handlers_) { 
VLOG(signals) << "invoking Action on handler " << handler; 
if (handler->Action(sig, info, context)) {.. 


} 


} 

if (HandleFaultByOtherHandlers(sig, info, context)) { 
return, 

} 


} 


// Set a breakpoint in this function to catch unhandled signals 
art_sigsegv_fault(); 


// Pass this on to the next handler in the chain, or the defaul 
InvokeUserSignalHandler(sig, info, context); 


从 上 述 代码 段 我 们 可 以 看 出 ， 事 件 处 理 的 优先 级 顺序 如 下 : 


e generated_code_handlers_; 
e other handlers_， 即 HandleFaultByOtherHandlers; 
。 用 户 自 定义 的 处 理 ， 即 InvokeUsetSignalHandlet。 


前 两 个 Handler 数 组 都 是 在 AddHandler 时 添加 的 ， 并 且 根 据 第 二 
参数 generated_code 来 划分 。 下 面 我 们 重点 分 析 最 常见 的 情况 ， 即 针对 
generated code handlers 是 如 何 处 理 的 。 





还 是 以 Suspension Check 为 例 ， 它 的 Action (arm 平 台 ) 定义 如 
下 : 


/*art/runtime/arch/arm/fault_handler_arm.cc*/ 
bool SuspensionHandler: :Action(int sig ATTRIBUTE_UNUSED, 
Siginfo_t* info ATTRIBUTE_UNUSED, void* contex 
uint32_t checkinst1 = Oxf8d90000 + 
Thread: : ThreadSuspendTriggerOffset<4 
uint16 t checkinst2 = 0x6800; 


struct ucontext* uc = reinterpret_cast<struct ucontext*>(contex 
struct sigcontext *sc = reinterpret_cast<struct sigcontext*>(&u 
uint8_t* ptr2 = reinterpret_cast<uint8_t*>(sc->arm_pc);//34+tKA 
uint8_t* ptri = ptr2 - 4; 

VLOG(signals) << "checking suspend"; 





uint1i6_t inst2 = ptr2[0] | ptr2[1] << 8; 


VLOG(Signals) << "inst2: " << std::hex << inst2 << " checkinst2 
if (inst2 != checkinst2) { 

return false; 
} 


uint8_t* limit = ptri - 40; // Compiler will hoist to a max o 
bool found = false; 
while (ptri > limit) { 
uint32_t insti = ((ptri[0O] | ptri[1] << 8) << 16) | (ptr1[2] 
VLOG(signals) << "insti: " << std::hex << insti << " checkins 
if (insti == checkinst1) { 
found = true; 
break; 


ptr1 -= 2; // Min instruction size is 2 bytes. 


} 
if (found) {// 当 前 是 Suspend Check 
VLOG(signals) << "suspend check match"; 


VLOG(Ssignals) << "arm lr: " << std: :hex << sc->arm_lr; 
VLOG(Signals) << "arm pc: " << std: :hex << sc->arm_pc; 
sc->arm_lr = sc->arm_pc + 3; // +2 + 1 (for thumb) 


sc->arm_pc = reinterpret_cast<uintptr_t>(art_quick_implicit_s 


// Now remove the suspend trigger that caused this fault. 
Thread: :Current()->RemoveSuspendTrigger (); 

VLOG(Ssignals) << "removed suspend trigger invoking test suspe 
return true; 


return false; 


} 
在 讲解 action 函 数 之 前 ， 我 们 先 来 补充 一 些 背景 知识 。 


当 kerne1 回 调用 户 空 间 的 信号 处 理 函 数 时 ， 它 首先 会 为 本 次 事件 准 
备 必 要 的 参数 信息 ， 其 中 就 包括 了 sigcontext。 这 个 数据 结构 中 详细 记 
录 了 事件 发 生 时 各 个 寄存 器 的 状态 〈 因 而 是 平台 相关 的 ) ， 以 及 错误 码 
等 内 容 。 由 于 sigcontext. h 属 于 kerne1 中 的 头 文件 ， 为 了 保证 用 户 空 间 
也 可 以 正常 使 用 它 ，Android 系 统 特别 将 kerne1 层 的 原始 头 文件 放置 在 
AOSP 工 程 的 /externalVkerne1-headers 里 ， 并 通过 
bionic/| ibc/kernel/tools/update_all. py 来 将 它们 自动 编辑 、 改 造成 
上 层 可 用 的 头 文件 形式 ， 并 保存 在 \bionic\1ibc\kerne1 对 应 目录 下 。 


如 果 是 因为 Suspension Check 而 引发 的 S1GSEGV， 从 前 面 的 描述 可 
‘Thread: :suspend trigger 必 定 为 nullptr。 那 么 我 们 如 何 检 查 当 前 的 


信号 事件 是 访问 了 suspend_trigger 这 个 nullptr 触 发 的 呢 ? 答案 就 是 通 
过 sigcontext 结 构 体 。 


另外 ， 我 们 还 可 以 进一步 思考 的 是 ， 程 序 是 在 什么 时 候 调 用 的 
Thread: :suspend trigger， 对 应 的 机 器 指令 是 什么 ? 


以 arm 平 台 为 例 ， 就 是 如 下 所 示 的 指令 序列 : 


// 0xf723cob2: f8d902c0 Ildr.w rO, [r9, #704] ; suspend_trigge 
// .， 一 些 中 间 过 程 
// Oxf723c0b6: 6800 ldr ro, [r0, #0] 


其 中 第 一 行 表示 加 载 Thread: :suspend_trigger (在 虚拟 机 的 调用 
约束 中 ，r9 代 表 当 前 线程 ) 指针 ， 而 最 后 一 行 〈 两 者 地 址 差 为 4) 就 是 
去 取 指 针 所 指向 的 内 容 一 一 可 想 而 知 ， 这 就 是 引发 S1GSEGV 的 地 方 。 


这 样 一 来 就 不 难 理 解 SuspensionHandler : :Action 国 数 的 处 理 远 辑 
T: 指针 ptr1 和 ptr2 就 分 别 对 应 着 指令 序列 的 首尾 ， 所 以 我 们 要 做 的 就 
ar e ae 令 是 否 和 预想 的 一 致 ， 从 而 判断 出 本 次 事件 


如 果 确 认 的 结果 是 Suspension Check， 那 么 接 下 来 程序 会 调用 
art_quick_implicit_suspend 来 执行 线程 挂 起 事件 (后 续 小 节 已 经 有 详 
ZANT, IX BERBER) ， 并 通过 RemoveSuspendTrigger 来 避免 后 续 再 
因此 产生 S1GSEGV。 


假如 signal chain 没 有 办 法 处 理 当 前 事件 ， 那 么 它 会 进一步 通过 
InvokeUserSignalHandler 来 将 控制 权 传递 给 用 户 注 册 的 事件 处 理 范 
数 ， 此 时 就 需要 使 用 到 user_sigactions 数 组 。 而 如 果 User Action 也 无 
法 处 理 这 一 Peis. 那么 InvokeUserSignalHandler 将 通过 signal 和 系统 调 
a 参数 设置 为 S16_DFL) 来 保证 事件 可 以 被 以 系统 默认 的 方式 
进行 处 理 。 


值得 一 提 的 是 ，Android 提 供 了 一 个 名 为 dubuggerd 的 daemon 来 负责 
所 有 程序 的 crash 事 件 ， 大 家 所 熟知 的 tombstone 文 件 就 是 由 它 产生 的 。 
因为 debuggerd 是 作为 Server 端 存在 的 ， 它 需要 程序 在 crash 时 主动 与 之 
取得 联系 。 扮 演 这 个 Client 角 色 的 模块 就 存在 于 Linker 中 ， 后 者 也 会 利 
用 Linux 的 信和 号 处 理 机 制 来 注册 自己 感 兴趣 的 信号 ， 并 在 适当 的 时 机 将 
消息 报告 给 debuggerd， 以 便 这 个 全 局 daemon 程 序 可 以 及 时 记录 系统 中 





发 生 的 crash 问 题 ， 为 开发 人 员 定 位 和 解决 问题 提供 必要 的 辅助 信息 。 





21.4 Android 虚 拟 机 核心 文件 格式 “ 主 军 者 ”0AT 


经 过 前 面 几 个 小 节 的 知识 铺垫， 现在 我 们 可 以 正式 进入 Art 虚 拟 机 
中 0AT 的 学 习 了 。 


21.4.1 0AT 文 件 格式 解析 
与 0AT 相 关 的 文件 后 缀 有 如 下 几 种 : 
@ art 


在 Android M 版 本 中 只 有 一 个 ， 即 boot. art， 存 储 路 径 
在 /system/framework/oat 或 者 /data/dalvik- cache/ 中 。 这 个 文件 也 
被 称 为 iImage， 是 由 dex20at 工 具 生 成 的 。 它 的 内 部 包含 了 很 多 Dex 文 
件 ，Zygote 在 启动 过 程 中 会 加 载 boot. art. 


在 Android N 版 本 中 ， 因 为 Application 也 可 以 有 image， 所 以 情况 
会 稍 有 不 同 。 


e oat 


0AT 是 由 dex2oat 产 生 的 。 不 少 读者 会 有 这 样 的 疑问 ， 即 boot. art 和 
boot. oat 有 什么 区 别 和 联系 呢 ? 如 果 我 们 把 boot. oat 比 作 一 个 exe 文 件 
的 话 ， 那 么 boot. art 则 类 似 于 exe 程 序 的 运行 时 实例 。 因 为 boot. art 中 
包含 了 很 多 已 经 预 初 始 化 了 的 类 和 对 象 ， 这 样 无 疑 可 以 加 快 启动 速度 

〈 但 同时 也 会 带 来 10MB 左 右 的 额外 空间 占用 ) 。 关 于 它们 二 者 之 间 的 联 
系 ， 本 小 节 后 续 内 容 中 还 有 更 多 详细 讲解 。 


e .odex 


在 Dalvik 中 ，odex 表 示 被 优化 后 的 Dex 文 件 ; Art 虚 拟 机 中 也 同样 存 
在 odex 文 件 ， 但 和 Dalvik 中 的 情况 不 同 ， 它 们 实际 上 也 是 . oat 文 件 。 


很 显然 dex2oat 会 耗费 一 定 的 时 间 特别 是 当 系 统 第 一 次 开机 时 ， 
或 者 是 恢复 了 出 三 设置 后 ， 此 时 会 对 所 有 的 用 户 应 用 程序 进行 重新 编 
F) ， 因 而 我 们 可 以 将 一 部 分 编译 工作 以 预 优 化 (pre-optimized) 的 
方式 在 ROM 构 建 时 完成 ; 这 种 做 法 的 一 个 缺点 是 会 占用 System 分 区 额外 


的 存储 空间 一 一 所 以 我 们 希望 在 这 二 者 间 寻 求 一 种 平衡 。Android 系 统 
特别 提供 了 如 下 编译 选项 供 开 发 人 员 选 择 : 


e (1) WITH_DEXPREOPT 


是 否 开启 预 优化 开关 ， 在 Android LolliPop 之 前 编译 user 版 本 时 是 
默认 打开 的 ， 而 Android 上 L 版 本 之 后 需要 在 BoardConf ig. mk 中 主动 打 
开 。 这 个 开关 是 后 续 几 个 含有 “PRE0PT” 开 头 的 选项 的 基础 ， 它 表示 
system image 中 的 所 有 对 象 〈 例 如 apk、jar 文 件 等 ) 都 需要 被 执行 预 优 
ies 


e (2) DONT_DEXPREOPT_PREBUILTS 


Prebui lt 的 程序 不 希望 参加 预 优化 ， 此 时 可 以 使 用 这 个 选项 。 使 用 


范例 : 


WITH_DEXPREOPT := true 
DONT_DEXPREOPT_PREBUILTS := true 


e (3) WITH_DEXPREOPT_BOOT_IMG_ONLY 


除了 boot image 外 ， 其 他 所 有 对 象 都 不 参加 预 优 化 。 使 用 范例 : 


WITH_DEXPREOPT := true 
WITH_DEXPREOPT_BOOT_IMG_ONLY := true 





e (4) LOCAL_DEX_PREOPT 


对 象 可 以 单独 指定 自己 是 否 人 参加 预 优化 。 这 个 选项 支 
持 “true”“false” 和 “nostripping” (表示 不 把 classes. dex 从 apk 
或 者 jar 文 件 中 剔除 ) 等 值 。 


在 Dalvik 虚 拟 机 时 代 ， 与 系统 framework 相 关联 的 odex 会 保存 在 设 
备 的 /system/framework 子 文件 夹 中 ; Art 虚 拟 机 则 略 有 差异 ， 它 将 这 些 
文件 〈 包 括 boot. art 和 boot. oat) 统一 保存 到 /system/ 
framework/arm 〈 或 者 arm64) 中 ， 示 例如 图 21-42 所 示 。 


-/system/t ramewor 


android.test .runner.odex 
applist .odex 

appops .odex 

appwidget .odex 


-android.contacts.separated.odex 
-android.future.ushb.accessory.odex 
-android. location. provider .odex 
-android.media.remotedisplay.odex 
-android.mediadrm.signer.odex 


-android.nfc_extras .odex 
-google.android.maps .odex 

-google .android.media.effects.odex 
-google .widevine.software .drm.odex 
-huawei.systemmanager.separated.odex 





全 图 21-42 Art 虚 拟 机 中 odex 和 oat 文 件 的 存储 路 径 


需要 特别 注意 的 是 ， 即 便 是 我 们 预先 在 System 分 区 中 生成 了 odex 文 
件 ， 系 统 还 是 会 在 Data 分 区 中 产生 对 应 的 Dex 文 件 。 而 且 odex 和 Dex 事 实 
上 都 是 0AT 文 件 ， 那么 为 什么 需要 两 份 呢 ? 简单 来 说 Dex 是 由 0dex 文 件 加 
上 一 个 偏 移 量 〈 对 于 每 个 设备 来 说 是 随机 的 ) 得 到 的 ， 原 因 是 为 了 系统 
因为 如 果 所 有 设备 都 采用 同一 ELE Mik s 38 曹 受 非法 
I a 


OAT 并 没有 什么 神秘 的 ， 它 本 质 上 也 属于 前 面 小 节 中 我 们 介绍 的 ELF 
文件 ， 具 体 关 系 如 图 21-43 所 示 。 


Oat Header 


-dex file count 






Dex File Meta(0...dex_file_count_) 
-dex file location size 
-dex file location data 


-dex_file_checksum 
ELF Header -dex file offset 









-methods_offsets pointer acs defs size 
-methods offsets pointer 


DexFile Content 


Oat Class 
-Status 
-OatMethod Off sets 


a }method defs size 
-OatMethod Off sets O aae 


-code_offest_ 


Native Code 


全 图 21-43 OAT 文 件 与 elf 文 件 之 间 的 联系 (引用 自 2014 年 Google [/O 上 的 演示 文档 ) 


由 Google 1/0 大 会 上 披露 的 0AT 文 件 格式 图 可 知 ，0AT 既 遵循 ELF 文 
件 规 范 ， 同 时 又 根据 虚拟 机 的 实际 需求 进行 了 扩展 最 大 的 区 别 在 于 
它 添加 了 两 个 重要 的 区 段 ， 即 “0at Data Section” JA “Oat Exec 
Section”。 其 中 “Data Section” 保 存 的 是 原 Dex 文 件 中 的 字 节 码 数 
据 ， 而 “Exec Section” 则 是 Dex 经 过 dex20at 翻 译 后 生成 的 机 器 代码 

(Native Code) 的 存储 区 域 。 并 且 我 们 可 以 从 Data Section 中 通过 一 

定 的 对 应 关系 可 以 迅速 找到 某 个 Class/Function 在 Exec Section PAYAL 
aa 04. 

FE RKTT AT—ThABLAOAT ISK IRAR ATER. XS 
例子 在 A0SP 工 程 中 的 out 目 录 下 ， 


BN]/out/target/product/generice/symbols/system/framework/arm/bor 
我 们 可 以 对 它 执 行 reade1f 操 作 ， 显 示 结 果 如 下 所 示 : 





ELF Header: 
Magic: 
Class: 
Data: 
Version: 
0S/ABI: 
ABI Version: 

Type: 

Machine: 

Version: 

Entry point address: 

Start of program headers: 
Start of section headers: 
Flags: 

Size of this header: 

Size of program headers: 
Number of program headers: 
Size of section headers: 
Number of section headers: 


Section header string table index: 


Section Headers: 


[Nr] Name Type 

[ 0] NULL 

[ 1] .dynsym DYNSYM 

[ 2] .dynstr STRTAB 

[ 3] .hash HASH 

[ 4] .rodata PROGBITS 
[ 5] .text PROGBITS 
[ 6] .dynamic DYNAMIC 
[ 7] .text.oat_patches LOUSER+0 
[ 8] .shstrtab STRTAB 


Key to Flags: 


u fered tat A allae) V lauaens +a\ 


7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00 


ELF32 

2's complement, little endian 
1 (current) 

UNIX - GNU 

0 

DYN (Shared object file) 
ARM 

ox1| 

0x0 

52 (bytes into file) 
53679876 (bytes into file) 
0x5000000, VersionS EABI 


52 (bytes) 

32 (bytes) 

5 

40 (bytes) 

9 

8 
Addr Off Size ES Flg Lk Inf Al 
00000000 000000 000000 00 0 0 0 
70945134 000134 000040 10 A 2 0 4 
70945174 000174 000026 00 AO 0 1 
7094519c 00019c 000020 04 A 1 0 4 
70946000 001000 1d10000 00 A © © 4096 
72656000 1411000 15daab0 00 AX © 0 4096 
73c31000 32ec000 000038 08 A 2 0 4096 
00000000 32ec038 045681 00 0 0 1 
00000000 33316b9 00004a 00 0 01 


leteinae\ 


由 上 图 可 知 ，boot. oat 确 实 是 一 个 ELF 格 式 的 文件 ， 并 且 包 含 了 多 
D. text 相 关 的 字段 。 那 么 0at Data Section 和 0at Exec Section 具 体 


对 应 哪些 区 段 呢 ? 


Symbol 
Num: 
0: 00000000 


73c30aac 


table ' dynsyn' contains 4 entries: 

Value Size Type 
© NOTYPE LOCAL DEFAULT UND 
1: 70946000 0x1d10000 OBJECT GLOBAL DEFAULT 
2: 72656000 0x15daab0 OBJECT GLOBAL DEFAULT 
3: 4 OBJECT GLOBAL DEFAULT 


Bind Vis Ndx Name 
4 oatdata 
5 oatexec 


5 oatlastword 


这 个 问题 的 答案 可 以 从 “. dynsym” 一 一 DYNSYM 类 型 的 动态 符号 表 
中 找到 。 与 Data 和 Exec Section 相 关联 的 有 3 个 重要 变量 ， 即 oatdata、 
oatexec 和 oatlastword。 其 中 oatdata 指 向 的 是 0atdata Section 的 起 始 
地 址 ; 而 oatexec 指 向 的 是 0atexec Setion 的 起 始 地 址 一 一 翻译 后 的 机 
器 指令 保存 在 这 个 区 域 。 另 外 一 个 符号 oatlastword 则 用 于 指示 0atexec 
Setion 的 结束 地 址 。 因 为 Data 和 Exec 两 个 区 域 是 紧 挨 着 的 ， 所 以 ， 
[oatdata, oatexec] 自然 就 是 Dex 的 存储 范围 ， 同 时 
[oatexec, oat1astwordj 就 是 机 器 指令 的 存储 区 域 了 。 


这 些 知 识 点 我 们 从 加 载 O0AT 文 件 的 Diopen 函 数 中 也 同样 可 以 得 到 印 
证 ， 核 心 源码 如 下 所 示 : 


/*art/runtime/oat_file.cc*/ 
bool OatFile::Dlopen(const std::string& elf_filename, byte* reque 
std::string* error_msg) { 
char* absolute_path = realpath(elf_filename.c_str(), NULL); 
if (absolute_path == NULL) { 
*error_msg = StringPrintf("Failed to find absolute path for '%s'" 
elf_filename.c_str()); 





return false; 


} 
dlopen_handle_ = dlopen(absolute_path, RTLD_NOW); 
free(absolute_path); 
if (dlopen_handle_ == NULL) { 
*error_msg = StringPrintf("Failed to dlopen '%s': %s", elf_fi 
dlerror()); 
return false; 


} 
begin_ = reinterpret_cast<byte*>(dlsym(dlopen_handle_, "oatdata 
if (begin_ == NULL) { 


*error_msg = StringPrintf("Failed to find oatdata symbol in '' 
elf_filename.c_str(),dlerror()); 
return false; 


if (requested_base != NULL && begin_ != requested_base) { 
*error_msg = StringPrintf("Failed to find oatdata symbol at e 
"oatdata=%p != expected=%p /proc/self/ma 
begin_, requested_base); 
ReadFileToString("/proc/self/maps", error_msg); 
return false; 


} 
end_ = reinterpret_cast<byte*>(dlsym(dlopen_handle_, "oatlastwo 
if (end_ == NULL) { 


*error_msg = StringPrintf("Failed to find oatlastword symbol 
elf_filename.c_str(),dlerror()); 


return false; 


// Readjust to be non-inclusive upper bound. 
end_ += sizeof(uint32_t); 
return Setup(error_msg); 


面 这 段 代码 的 逻辑 是 : 首先 获取 ELF (oat) 文件 的 绝对 路 径 ， 然 75 
后 通 a 文件 句柄 则 保存 在 dlopen_handle_ 变 量 
中 。 接 着 两 次 调用 dlsym 函 数 ， 分 别 查找 
到 “oatdata” 和 “oat1lastword” 这 两 个 Dynamic Symbol, FHF EME 
存 到 全 局 变量 begin_ 和 end_ 中 。 有 了 这 两 个 变量 ， 当 然 就 可 以 确定 
oatdata 和 oatexec 两 个 区 段 的 起 止 地 址 了 。 最 后 再 调用 Setup 来 进入 下 
一 步 的 工作 。 


Setup 函 数 比较 长 ， 我 们 重点 关注 与 0AT 文 件 格式 相关 的 内 容 : 


/*art/runtime/oat_file.cc*/ 
bool OatFile::Setup(std::string* error_msg) { 
if (!GetOatHeader().IsValid()) {// 检 查 0AT 文 件 的 magic number, KAS 
*error_msg = StringPrintf("Invalid oat magic for '%s'", GetLo 
return false; 








} 
const byte* oat = Begin(); // 获 取 begin_ 全 局 变量 的 值 ， 即 0atdata 
oat += sizeof(OatHeader); // 跳 过 0atHeader 所 占 空间 
if (oat > End()) {//End() 返 回 end_ 全 局 变量 的 值 ， 即 0atlastword 
*error_msg = StringPrintf("In oat file '%s' found truncated 0 
GetLocation().c_str()); 








return false; 


} 


oat += GetOatHeader(). a ere 
if (oat > End()) {//0AT 文 件 大 小 异 


x 





return false; 


ih 


uint32_t dex_file_count = GetOatHeader().GetDexFileCount();//0A 
oat_dex_files_storage_.reserve(dex_file_ count); 
for (size_t i = 0; i < dex_file_count; i++) { 
uint32_t dex_file_location_size = *reinterpret_cast<const uin 
/VDex 文 件 路 各 





oat += sizeof(dex_file_location_size);// 跳 过 文件 路 径 字 符 串 所 占 的 分 


t 


} 


const char* dex_file_location_data = reinterpret_cast<const c 
//Dex 文 件 路 径 
oat += dex_file_location_size; 


std::string dex_file_location(dex_file_location_data, dex_fil 


uint32_t dex_file_checksum = *reinterpret_cast<const uint32_t 
oat += sizeof(dex_file_checksum) ; //Dex CEM REIKI 


uint32_t dex_file_offset = *reinterpret_cast<const uint32_t*> 


//Dex 文 件 的 偏 移 量 





oat += sizeof(dex file offset); 


const uint8_t* dex_file_pointer = Begin() + dex_file_offset; 
//Dex 文件 的 起 始 地 址 ， 注 意 它 是 在 dex_file_offset 芯 
/*Dex 的 合法 性 检查 */ 
if (UNLIKELY(!DexFile: :IsMagicValid(dex_file_pointer))) {.. 
return false; 








} 
if (UNLIKELY(!DexFile::IsVersionValid(dex_file_pointer))) {.. 
return false; 
} 
const DexFile::Header* header = 
reinterpret_cast<const DexFile: :Header*>(dex_file_poin 
const uint32_t* methods_offsets_pointer = reinterpret_cast<co 


oat += (sizeof(*methods_offsets_pointer) * header->class_defs 


OatDexFile* oat_dex_file = new OatDexFile(this, dex_file_loca 
canonical_location, dex_fil 
dex_file_pointer,methods_of 

oat_dex_files_storage_.push_back(oat_dex_file); 


// Add the location and canonical location (if different) to 
StringPiece key(oat_dex_file->GetDexFileLocation()); 
oat_dex_files_.Put(key, oat_dex_file); 
if (canonical_location != dex_file_location) { 
StringPiece canonical_key(oat_dex_file->GetCanonicalDexFile 
oat_dex_files_.Put(canonical_key, oat_dex_file); 


} 


return true; 


这 个 函数 为 我 们 很 好 地 描绘 出 了 0AT 文 件 格式 的 全 景 图 。 相 信 大 家 


在 一 行 行 阅读 代码 的 同时 ，0AT 的 整体 框架 就 已 经 在 脑海 中 形成 了 。 


首先 ， 我 们 通过 Get0atHeader (). IsValid 0 来 判断 当前 的 0AT 文 件 
否 合法 。 检 查 项 包括 文件 的 魔 数 是 否 为 “oat”; 版 本 号 是 否 等 
于 “039”， 是 否 页 对 齐 等 。Get0atHeader 实 际 上 就 是 将 begin 变量 所 
指向 的 地 址 做 了 一 次 0atHeader 的 强制 类 型 转换 。 这 里 要 提 醋 大 家 注意 
区 分 EIf Header 和 0at Header 这 两 个 格式 头 一 一 它们 分 别 代 表 ELF 文 件 
格式 的 头 部 以 及 Art 虚 拟 机 中 可 执行 文件 Coat) 的 头 部 ， 而 且 后 者 “ 潜 
伏 ” 于 前 者 之 中 。 


如 果 合 法 性 检查 没有 问题 的 话 ， 那 么 紧 接着 我 们 就 可 以 利用 
Begin() 返回 的 begin_ 全 局 变量 来 得 到 0AT 区 域 的 起 始点 〈 这 也 是 “全 景 
图 ”的 起 点 ) 。 随 后 0AT 变 量 跳 过 0atHeader 所 占 的 空间 大 小 。 此 时 如 果 
OAT 忆 经 超过 end， 则 表示 文件 出 现 了 异常 ， 此 时 函数 将 直接 返回 fal se 


和 Apk 中 的 情况 类 似 ，0AT 中 也 可 能 有 不 止 一 个 Dex 文 件 ， 具 体 数 量 
可 以 通过 GetDexFi le Count 获 取 到 。 对 于 每 一 个 DexFi le， 我 们 都 需要 
把 它们 逐一 从 OAT 文 件 中 “ 扑 ” 出 来 ， 实 现 统一 的 管理 。 因 而 Setup 函 数 
需要 通过 一 个 for 循 环 来 完成 对 这 些 Dex 的 处 理 。 这 同时 也 要 求 O0AT 在 存 
储 这 些 Dex 数 据 时 一 定 得 采用 一 种 固定 的 格式 一 一 具体 而 言 ， 
dex file location size4 sizeof (uint32_t) 的 空间 大 小 ， 代 表 了 
Dex 文 件 路 径 字 符 串 所 占 的 空间 大 小 。 指 针 0AT 在 起 始 时 指向 的 是 第 一 个 
Dex 文 件 信息 所 在 地 ， 接 着 它 读 取 Dex 文 件 路 径 名 所 占 空 间 大 小 保存 到 
dex file _location_size 变 量 中 ， 以 及 路 径 字 符 串 所 在 位 置 
dex file_location_ data， 并 由 此 组 成 dex_file_location 字 符 串 对 
象 。 紧 随 dex_ file location _ data 之 后 的 是 dex_file_checksum， 即 Dex 
文件 的 校 验 和 ， 这 个 变量 在 创建 0atDexFi le 时 会 派 上 用 场 。 完 成 了 这 些 
变量 的 计算 后 ，Dex 文 件 的 基本 信息 就 比较 清楚 了 。 那 么 Dex 文 件 的 具体 
内 容 存 储 在 0AT 文 件 中 的 哪个 位 置 呢 ? 这 就 是 dex_file_offset 变 量 所 承 
担 的 角色 。 如 其 名 所 示 ， 它 代表 的 是 Dex File 在 0AT 中 的 偏 移 量 。 所 以 
存储 Dex 文 件 内 容 的 起 始 地 址 应 该 是 dex_file pointer = Begin() + 
dex_file_offset。 得 到 了 Dex 文 件 的 起 始 地 址 后 ， 我 们 需要 先 通过 
DexFile: :1sMagicValid 和 |1sVersionValid 来 确保 这 个 Dex 文 件 的 合法 
性 。1sMagicValid 会 读 取 并 确保 文件 的 魔 数 是 否 为 “Dex”， 而 
1sVersionValid 则 负责 检查 该 Dex 文 件 的 版 本 号 是 否 为 “035”。 


Dex 文 件 同样 提供 了 一 个 头 部 信息 ， 即 DexFi le: :Header。 
意 此 时 0AT 变 量 仍然 指向 dex_file_offset 结 束 的 位 置 ， 紧 随 其 后 的 变 


是 methods_offsets_pointer。 通 常情 况 下 Dex 文 件 中 都 包含 了 非常 多 的 
class 和 各 种 成 员 函 数 ， 这 些 信 息 都 保存 在 0AT 文 件 中 。 


oat += (sizeof(*methods_offsets_pointer) * header->class_defs_siz 


上 面 这 条 语句 用 于 跳 过 Dex 文 件 的 函数 信息 段 ， 其 中 
methods offsets_pointer 指 向 的 是 某 个 函数 在 Dex Content 中 的 具体 实 
现 ; 函数 的 总 数量 则 是 header->class_defs_size_。 最 后 ， 我 们 创建 一 
个 0atDexFi le 对 象 来 容纳 Dex 文 件 ， 并 将 结果 统一 保存 到 
oat_dex_ files_storage_ 和 oat_dex_files 中 一 一 前 者 是 std: :vector 
类 型 的 全 局 变量 ， 用 于 保存 所 有 Dex File; 后 者 负责 为 DexFile 和 它 的 
路 径 建立 map 关 联 。 


0atDexFi le 对象 保 存 了 Dex 文 件 的 所 有 属性 和 内 容 数 据 ， 这 些 信息 
将 在 OAT 的 运行 过 程 中 发 挥 重 要 作用 。0atDexFi1e 的 构造 函数 如 下 所 
7N: 


/*art/runtime/oat_file.cc*/ 

OatFile: :OatDexFile: :OatDexFile(const OatFile* oat_file, 
const std::string& dex_file_location, 
const std::string& canonical_dex_file 





uint32_t dex_file_location_checksum, 

const byte* dex_file_pointer, 

const uint32_t* oat_class_offsets_poin 

: oat_file_(oat_file), 

dex_file_location_(dex_file_location), 
canonical_dex_file_location_(canonical_dex_file_ location), 
dex_file_location_checksum_(dex_file_location_checksum), 
dex_file_pointer_(dex_file_pointer), 
oat_class_offsets_pointer_(oat_class_offsets_pointer) {} 


Hoat_filettC#zANZO0ATICH, ERE Hsetupe ay PAthisi§ 
针 所 指向 的 对 象 ; oat_class_offsets_pointer 对 应 的 是 setup 中 的 
methods_offsets_pointer (这 个 名 字 容 易 引 起 误解 ， 大 家 特别 注 
意 ) ， 代 表 的 是 一 个 0at Class 的 偏 移 地 址 。 


我 们 知道 ， 一 个 OAT 中 包含 N 个 〈N 可 能 不 止 一 个 ) Dex 文 件 ， 而 每 个 
Dex 中 又 包含 N 个 Class， 每 个 Class 则 又 包含 N 个 了 浮 数 。 


可 能 读者 会 有 疑问 ， 既 然 Art 已 经 将 Dex 提 前 编译 成 0AT 文 件 ， 那 么 
为 什么 还 要 保留 原始 的 Dex 呢 ?Art 如 此 设计 主要 基于 如 下 几 点 考虑 : 

















(1) 为 了 提供 一 个 便利 的 Class 到 Native Code 的 对 应 关系 ， 从 而 
加 速 代 码 的 执行 时 间 。 关 于 这 点 我 们 在 后 续 讲解 代码 的 运行 流程 时 还 有 
更 详细 的 分 析 。 


(2) 为 开发 者 的 调试 过 程 提供 更 准确 的 源码 定位 。 


(3) 我 们 在 很 多 情况 下 仍然 需要 依靠 interpreter 解 析 字 节 码 的 方 
式 来 执行 应 用 程序 。 


通过 上 面 的 分 析 ， 相 信 大 家 对 于 0AT 文 件 已 经 有 了 全 局 的 认识 了 。 
我 们 再 来 通过 图 21-44 做 一 下 总 结 ， 大 家 可 以 看 一 下 是 否 和 脑海 中 绘制 
的 结构 图 完全 一 致 。 


class defs size_ 


dex_file_pointer 


| exe Met O | 


Dex File MetaN 


DexFile:: Header 


Dex File Content 


1 
OAT Class 





全 图 21-44 OAT 文 件 结构 (1/2) 


理解 了 0AT 文 件 的 内 部 结构 后 ， 我 们 再 深入 地 解答 一 下 本 小 节 开 头 
提 到 的 问题 ， 即 boot. art 和 boot. oat 之 间 的 联系 。 


Boot. art 简 单 来 说 是 “An image file with a heap of 
preinitialized classes and objects”。 它 和 boot. oat 都 存储 
在 /system/framework/《isa>/ 文 件 夹 下 。 根 据 Art 虚 拟 机 的 设计 ， 
Boot. art 和 boot. oat 之 间 是 可 以 相互 引用 的 ， 而 且 它 们 在 内 存 中 的 加 载 
位 置 是 紧 挨 着 的 。 图 21-45 是 根据 art/runtime/image. h 文 件 总 结 出 来 的 
结构 图 。 


image 被 中 射 到 的 内 存 基地 址 
image 所 本 室 间 大 小 ， 没 有 页 对 间 
指向 oat 文件 的 加 载 起 始 地 址 
Oatdata section 的 起 始 地 址 


仅 针 对 app image headers 有 效 
= 


OAT file end_ 





全 图 21-45 ”结构 图 (2/2) 


反 过 来 0AT 文 件 也 可 以 访问 image 中 的 内 容 ， 示 意 如 图 21-46 所 示 。 


Frameworks Image 
Frameworks Code 


qCOAUUUUUNIEDDUUODUUUUEGUUNIDEUUNSOUUUUSEULSEOUUUSEDOUUUESL LDL DDL LDL LLL LL LL LL LLL LLL DLL LL LL LL LD 
” 站 
. . 


; ELF File ELF Header 
: oatdata symbol 


Header 


Todata 
Dex File 1 


Dex File D 
Class 1 Metadata 
Class C Metadata 


text Compiled Method 1 
i Compiled Method M 
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全 图 21-46 Image 和 OAT 之 间 的 引用 关系 {-:-} 引 用 自 2014 年 Google IO 大 会 上 的 分 享 


因为 Boot. art 中 包含 的 Frameworks lmage 和 Frameworks Code 可 以 
供 0AT 中 的 Compi led Method 直 接 调用 和 访问 ， 而 不 需要 在 程序 启动 时 再 
去 动态 创建 ; 而 且 Framework 中 包含 的 很 多 数据 对 于 大 部 分 Art 应 用 程序 
都 是 必需 的 ， 访 问 频 度 相当 高 ， 所 以 这 样 的 设计 无 疑 可 以 在 很 大 程度 上 
提升 程序 的 启动 和 运行 时 速度 。 


21.4.2 0AT 的 两 个 编译 时 机 


在 Android N 版 本 之 前 (Android N 版 本 中 对 0AT 的 编译 时 机 和 方式 
进行 了 调整 ， 可 以 参见 后 续 JIT 小 节 的 详细 分 析 ) ，dex2oat 主 要 发 生 在 
两 个 阶段 : 在 Android 系 统 构建 过 程 中 执行 〈 主 要 针对 预 装 的 应 用 程序 
和 系统 应 用 程序 ) ; 以 及 第 三 方 应 用 程序 安装 过 程 中 执行 《只 针对 第 三 
方 应 用 程序 ) 。 主 要 过 程 摘 述 如 下 : 


。 KAW HR ME IF 


Android 本 身 预 装 有 各 种 系统 程序 和 应 用 程序 ， 这 些 APK 在 设备 出 三 
之 前 就 已 经 确定 下 来 了 通常 是 各 设备 厂商 在 原生 Android 版 本 上 完成 
一 定 程 度 的 定制 。 例 如 引入 自家 的 U1 实现 ， 增 删 应 用 程序 等 ) 。 更 为 重 
要 的 是 ， 系 统 编译 时 其 所 针对 的 硬件 平台 显然 是 确定 的 一 一 这 是 0AT 能 
正常 开展 编译 工作 的 前 提 条 件 之 一 〈0AT 是 一 种 扩展 的 ELF 文 件 ， 它 们 所 
包含 的 代码 指令 都 是 需要 针对 具体 硬件 平台 来 编译 产生 的 ) 


。 第 三 方 应 用 程序 


我 们 知道 Art 虚 拟 机 在 运行 效率 上 取胜 的 “独门 秘诀 ”是 AoT， 即 事 
先 就 把 Java 代 码 编译 成 机 器 指令 的 一 种 技术 手段 。 但 是 这 里 存在 一 个 问 
题 一 一 对 于 第 三 方 应 用 程序 例如 微 信 、QQ 等 ;来 说 ， 它 们 将 来 会 被 用 
户 在 哪个 硬件 平台 上 安装 运行 是 未 知 的。 所 以 这 种 情况 下 没有 办 法 采用 
ee 即 在 应 用 程序 的 开发 构建 阶段 就 把 它们 编译 

COAT 文件 。 


另外 ， 我 们 还 需要 考虑 第 三 方 应 用 程序 与 Android 系 统 版 本 的 兼容 
性 问题 。 因 为 终端 用 户 所 使 用 的 Android 设 备 的 系统 版 本 既 可 能 是 
6.0《〈 此 时 Art 虚 拟 机 已 经 完全 取代 了 Dalvik 虚 拟 机 ) ， 也 可 能 是 


4.4 (Art 和 Dalvik 虚 拟 机 并 存 的 情况 ) ， 甚 至 是 2. 3 〈 只 支持 Dalvik 虐 
拟 机 的 情况 ) 无 论 哪 一 个 版 本 ， 应 用 程序 都 应 该 要 能 正常 工作 。 综 
上 所 述 ， 编 译 0AT 的 工作 显然 无 法 由 第 3 方 应 用 程序 来 完成 。 所 以 一 个 比 
较 理 想 的 解决 方案 是 在 用 户 安装 第 三 方 应 用 程序 的 过 程 中 ， 通 过 
dex20at 将 其 编译 成 OAT 文 件 。 





21.4.2.1 Andtoid 系 统 构建 过 程 中 的 OAT 编 译 


从 Android 4. 4 版 本 开始 ， 在 Android 系 统 构建 的 最 后 阶段 都 会 执行 
我 们 可 以 首先 从 编译 脚本 的 角度 顽 探 出 这 其 中 的 “来 龙 
脉 ” ， 


/*build/core/main.mk*/ 


include $(BUILD_SYSTEM) /dex_preopt .mk 


由 于 历史 原因 ，dex_preopt. mk 脚本 中 挫 杂 了 很 多 dex 和 opt 相 关 的 
操作 ， 大 家 注意 区 分 对 待 。 上 述 语句 通过 一 个 统一 的 dex_preopt. mk 来 
决定 如 何 对 dex 文 件 进行 “ 预 优 化 ”操作 一 一 这 其 中 就 包含 了 我 们 关心 
的 dex2oat 编 译 : 


/*build/core/dex_preopt.mk*/ 
include $(BUILD_SYSTEM) /dex_preopt_libart.mk 


# Define dexpreopt-one-file based on current default runtime. 
# $(1): the input .jar or .apk file 

# $(2): the output .odex file 

define dexpreopt -one-file 

$(call dex2oat -one- file, $(1),$(2) ) 

endef 


上 述 脚本 中 有 两 个 地 方 需要 我 们 特别 注意 : 
。 Dalv 让 和 Artt 虚 拟 机 都 有 各 自 的 预 优化 脚本 


在 Android 老 版 本 中 ， 对 Dalvik 的 预 优化 是 有 条 件 的 编译 系统 
会 利用 一 个 名 为 DALVIK_VM_LIB 的 变量 来 判断 是 否 需要 执行 
dexopt (DALVIK_VM_LIB 等 于 1ibdvm. so 的 时 候 ) ; 而 Art 虚 拟 机 下 的 预 
编译 则 是 无 条 件 的 。 





Android N 版 本 已 经 彻底 按 弃 了 Dalvik 虚 拟 机 ， 所 以 只 留 下 了 Art 程 
序 的 预 优化 脚本 dex_preopt libart. mk. 


e dexpteopt-one-file 函 数 


ek i dexpreopt—one-f i le 用 于 完成 对 dex2oat-one-file 的 调用 ， 后 
者 的 定义 则 在 dex_preopt_libart. mk 中 一 一 简单 来 讲 它 为 dex2oat 程 序 
的 执行 提供 了 上 下 文 环境 。 我 们 稍 后 会 做 进一步 分 析 。 


大 家 先 来 思考 一 下 ， 我 们 应 该 在 编译 的 哪个 阶段 执行 dex2oat 这 个 
预 优化 操作 呢 ? 


至 少 有 两 种 可 选 的 方案 : 其 一 是 在 Android 系 统 编译 的 最 后 一 刻 针 
对 所 有 需要 预 优化 的 对 象 做 统一 处 理 ; 另 一 种 方案 则 是 “ 卡 住 ”需要 执 
行 优化 操作 的 所 有 模块 如. jar, . apk) 的 “咽喉 要 道 ”， 然 后 由 它们 
自行 完成 任务 一 一 Android 编 译 系统 采用 的 是 后 面 这 种 方式 。 


这 些 模 块 的 “咽喉 要 道 ” 是 什么 呢 ? 我 们 知道 dex2oat 的 输入 源 是 
Dex 程 序 ， 那 么 问题 就 自然 而 然 转 化 为 一 一 产生 Dex 的 地 方 都 可 能 成 为 我 
们 的 目标 对 象 。 相 信 读 者 们 已 经 能 想到 Android 是 怎么 做 的 了 注意 : 
是 否 需 要 做 预 优化 ， 以 及 针对 哪些 元 素 展开 预 优化 都 是 可 以 配置 的 。 鉴 
oe eee 下 面 的 内 容 中 我 们 直接 假设 预 优化 操 

7E m : : 








(1) java_library. mk 


我 们 知道 ， 通 过 编译 系统 预先 提供 的 诸如 BUILD_JAVA_LI1BRARY、 
BUILD_STATIC_JAVA_LIBRARY、BUILD_PACKAGE 之 类 的 模板 可 以 方便 地 完 
成 不 同类 型 模块 的 编译 。 其 中 $ (BUILD_JAVA_LIBRARY) 用 于 编译 共享 
的 Java 库 〈 例 如 framework. jar, am. jar, services. jar 等 ， 它 们 都 会 
存储 到 终端 设备 的 /system/framework 目 录 中 ) ， 它 实际 上 也 是 利用 
java_library. mk 实现 的 。 这 个 脚本 中 与 dex2oat 相 关 的 部 分 如 下 所 示 : 


/*build/core/java_library.mk*/ 


$(built_odex) : $(dir $(LOCAL_BUILT_MODULE) )% : $(common_javalib. 
@echo "Dexpreopt Jar: $(PRIVATE_MODULE) ($@)" 
$(call dexpreopt -one-file, $<, $@) 


上 述 脚本 片段 中 使 用 的 是 makefi le 的 静态 模式 ， 主 要 目的 在 于 处 理 
多 个 Bui It 0dex 的 情况 。 函 数 dexpreopt-one-file 我 们 在 前 面 已 经 看 到 
过 了 ; 它 的 第 1 个 参数 $< 表 示 首 个 Prerequisite， 即 
$(common_javalib. jar); 男 一 个 参数 $@ 表 示 目 标 对 象 ， 即 通过 $ dir 
$ (LOCAL_BUILT_MODULE) ) % 模 式 来 匹配 $ (bui It_odex) 集合 而 得 到 的 目 
标 。 


现在 是 时 候 分 析 dexpreopt-one-file 的 内 部 实现 了 : 


/*build/core/dex_preopt_libart.mk*/ 

# $(1): the input ,jar or .apk file 

# $(2): the output .odex file 

define dex2o0at-one-file 

$(hide) rm -f $(2) 

$(hide) mkdir -p $(dir $(2)) 

$(hide) $(DEX20AT) \ 
--runtime-arg -Xms$(DEX20AT_XMS) --runtime-arg -Xmx$(DEX20AT 
-- boot -image=$(PRIVATE_DEX_PREOPT_IMAGE_LOCATION) \ 
--dex-file=$(1) \ 
--dex-location=$(PRIVATE_DEX_LOCATION) \ 
--oat-file=$(2) \ 
--android-root=$(PRODUCT_OUT)/system \ 
--instruction-set=$($(PRIVATE_2ND_ARCH_VAR_PREFIX)DEX20AT_TA 
--instruction-set-variant=$($(PRIVATE_2ND_ARCH_VAR_PREFIX)DE 
--instruction-set-features=$($(PRIVATE_2ND_ARCH_VAR_PREFIX)D 
--include-patch-information --runtime-arg -Xnorelocate --no- 
--abort-on-hard-verifier-error \ 
$(PRIVATE_DEX_PREOPT_FLAGS ) 

endef 


上 述 函 数 的 实现 重心 在 $ (DEX20ATD) 这 个 变量 。 顾 名 思 义 ， 它 的 工 
作 就 是 将 Dex (或 者 Jar) 转化 为 0AT， 上 有 具体 对 应 的 是 名 为 dex2oatd 的 应 
用 程序 。 另 外 ， 细 心 的 读者 可 能 会 发 现 脚本 中 其 实 还 有 一 个 与 之 很 类 似 
的 变量 dex20at 一 一 简单 来 讲 ， 结 尾 所 含 的 “D” 代 表 DEBUG， 因 而 它们 
二 者 之 间 的 区 别 就 在 于 是 否 开启 了 DEBUG 模 式 。 


无 论 是 dex2oat 还 是 dex2oat， 在 Android 系 统 编译 的 场景 下 都 属于 
HOST EXECUTABLE， 即 运行 于 开发 机 器 之 上 的 可 执行 程序 。 而 适用 于 第 3 
方 应 用 程序 的 dex20at 则 需要 运行 于 终端 设备 平台 上 ， 请 大 家 特别 注意 
这 些 区 别 。 


dex2oat 接 受 两 种 类 型 的 输入 : .jar 或者. apk 〈 内 部 包含 . dex) , 














FAS (1) 参数 指定 ; 输出 的 是 . odex 文 件 ， 由 $ (2) 指定 。 在 
java_library. mk 这 个 场景 中 ，$ (1) 具体 指 的 是 . jar 文 件 (如 
framework. jar), $(2) 对 应 的 是 $ (bui It_odex) 。 


dex20at 的 源码 目录 是 /art/dex20at， 它 的 Android. mk 中 的 核心 摘 
述 语 句 〈 非 DEBUG，H0ST 的 情况 ) 如 下 所 示 : 


/*art/dex2o0at/Android.mk*/ 


ifeq ($(Art_BUILD_HOST_NDEBUG), true) 
$(eval $(call build-art-executable, dex20at, $(DEX20AT_SRC_FILES) 
endif 


表面 上 dex2oat 子 项 目 只 包含 dex2oat. cc 一 个 源 文件 ， 但 事实 上 它 
还 依赖 于 很 多 其 他 模块 ， 例 如 art/compiler、1ibcuti1s 等 。 另 外 ， 
dex20at 是 基于 LLVM 这 个 通用 的 编译 框 染 完成 的 。 它 的 内 部 实现 涉及 的 
技术 面 很 广 ， 并 非 本 小 节 所 需要 关心 的 内 容 ， 所 以 我 们 暂时 不 做 深入 解 
析 ， 有 兴趣 的 读者 可 以 自行 阅读 源码 了 解 详情 。 


(2) Package_internal.mk 


Fl java_library. mk 的 情况 类 似 ，package_internal. mk 是 为 
BUILD_PACKAGE 服 务 的 ， 即 用 于 生成 APK 文 件 。 这 个 脚本 中 与 dex2oat 编 
译 相 关 的 核心 语句 如 下 所 示 : 


/*build/core/package_internal.mk*/ 


ifdef LOCAL_DEX_PREOPT 
$(built_odex): PRIVATE_DEX_FILE := $(built_dex) 
# Use pattern rule - we may have multiple built odex files. 
$(built_odex) : $(dir $(LOCAL_BUILT_MODULE))% : $(built_dex) 
$(hide) mkdir -p $(dir $Q) && rm -f $@ 
$(add-dex-to-package) 
$(hide) mv $@ $@.input 
$(call dexpreopt -one- file, $@. input, $@) 
$(hide) rm $@. input 
endif 


在 这 个 场景 下 ，PRIVATE_DEX_FILE 是 一 种 Target-Specific 
Variable， 以 确保 PRIVATE_DEX_FILE 只 对 $ (bui 1t_dex) 这 个 特定 的 目标 
对 象 有 效 。 这 种 用 法 我 们 在 本 书 编译 系统 章节 中 已 经 做 过 分 析 ， 大 家 可 
以 结合 起 来 阅读 。 


PRIVATE_DEX_FILE 是 add-dex-to-package 中 所 必需 的 变量 ; 后 者 是 
一 个 defi ne 实现 ， 它 的 主要 功能 是 打包 Dex《〈 即 bui lt_dex) ， 如 下 所 
示 : 


/*build/core/definitions.mk*/ 

define add-dex-to-package 

$(hide) zip -qj $@ $(dir $(PRIVATE_DEX_FILE) )classes*.dex 
endef 


经 过 add-dex-to-package 调 用 后 ，$@ 代 表 的 是 classes*. dex (可 能 
有 多 个 ) 形成 的 zip 包 一 一 紧 接着 我 们 就 利用 mv 命令 来 将 其 改名 为 
$@. input. 。 这 同时 也 是 dexpreopt-one-file 的 第 一 个 参数 ， 以 及 
dex2oat 程 序 的 “输入 源 ”; 另 一 个 参数 则 是 $@， 同 时 也 是 dex2oat 
的 “输出 源 ”。 


这 样 一 来 Android 工 程 中 的 APK 通 过 引用 BUILD_PACKAGE 这 个 模板 ， 
就 可 以 同时 实现 dex2oat 编 译 了 。 


(3) Prebuilt_internal. mk 


Prebui It 是 对 已 预先 编译 好 的 模块 所 采取 的 一 种 处 理 手段 ， 对 应 的 
模板 是 BUILT_PREBUILT 和 BUILD_MULTI_PREBUILT 〈 它 们 的 区 别 在 于 模块 
的 数量 ) o Prebuilt_internal. mk 则 是 Prebui 1t 的 内 部 实现 ， 其 中 与 
dex2oat 相 关 的 核心 脚本 如 下 所 示 : 


/*build/core/prebuilt_internal.mk*/ 

ifdef LOCAL_DEX_PREOPT 

$(built_odex) : $(my_prebuilt_src_file) 
$(call dexpreopt-one- file, $<, $@) 

endif 


Prebui It 本 身 功 能 比较 简单 ， 在 调用 dexpreopt-one-file 时 传 入 的 
第 1 个 参数 是 4<4， 代 表 第 1 个 目标 依赖 对 象 $ my_prebui lt_src_file) ; 
第 2 个 参数 $@ 代 表 dex2o0at 的 输出 结果 。 这 和 前 面 两 种 脚本 模板 中 的 情况 
是 大 同 小 异 的 ， 因 而 我 们 不 再 矿 述 。 


21.4.2.2 ”dex20at 的 用 法 


dex2oat 的 内 部 实现 涉及 编译 原理 、LLVM 等 很 多 知识 点 ， 限 于 篇 幅 
我 们 不 做 深入 介绍 。 但 是 大 家 最 少 应 该 对 dex2oat 做 到 “ 知 其 然 ”， 所 


以 本 小 节 的 重点 是 讲解 dex2oat 这 个 工具 的 用 法 。 

dex20at 根 据 目标 平台 的 不 同 分 为 两 个 版 本 ， 即 Host 端 和 Tar get 
端 。 不 过 它们 二 者 的 内 部 实现 是 大 同 小 异 的 ， 所 以 接 下 来 的 分 析 以 Host 
端的 dex2oat 为 主 。 

表 21-8 所 示 是 dex2oat 程 序 所 支持 的 选项 参数 。 


表 21-8 dex2oat 的 核心 选项 


指定 执行 编译 操作 所 需 的 线程 数量 


--dex-file=<dex-file> 〈 输 入 参数 ) 










指定 需要 被 编译 的 .dex,.jar 或 者 .apk5 
范例 : --dex-file=/system/framework/ 


指定 一 个 zip 文 件 ( 其 中 包含 了 需要 
的 classes.dex) 的 文件 描述 符 。 范 例 
fd=5 


--zip-fd=<file-descriptor> 〈 输 入 参 
数 ) 


为 --zip-fd 文 件 指 定 一 个 符号 名 。 范 人 
zip-location=/system/app/Calculator.a] 


--zip-location=<zip-location> (输入 
参数 ) 





以 文件 名 的 形式 指定 OAT 的 输出 目 帮 


aes -fijle=<fi ra EER 
paile < loa ea 例 : --oat-file=/system/framework/boc 


--oat-fd=<number> (输出 参数 ) 


--oat-location=<oat-name> (输出 参 | 为 --oat-fd 文 件 指定 一 个 符号 名 。 范 f 
数 ) oat-location=/data/dalvik- 
cache/system@app@Calculator.apk.0o¢ 


b e Ae PS 太太 O : A 
--oat-symbols=<file.oat> (输出 参 pee 的 OAT 输 出 目 + 
数 ) Oa 


symbols=/symbols/system/framework/ 


指定 bitcode 文 件 名 《可 选 ) 范例 : - 


bitcode=/system/framework/boot.bc 





指定 image GAE) 目标。 范例 : -- 


-i 二 < 人 > ‘ay 参 RB 
image=<file.art> (输出 参数 ) image=/system/framework/boot.art 


--image-classes=<classname- 指定 image} ween classes. Y 
Jes (tea ABE image-classes=frameworks/base/preloi 
file> (输入 参数 ) classes 


生成 boot image 时 所 采用 的 基地 址 。 


--base=<hex-address> fil: --base=0x50000000 


指定 包含 了 启动 时 类 路 径 的 Image 文 
--boot-image=<file.art> 例 : --boot- 
image=/system/framework/boot.art 





为 Portable Linking #8 xe FAVA FE YE 
--android-root=<path> android-root=out/host/linux-x86. 45 
定 的 话 ， 默 认 值 是 $ANDROID_ROC 





--instruction-set= 指定 编译 所 针对 的 机 器 指令 集 。Exs 
(arm|arm64|mips|x86|x86_64) instruction-set=x8 默 认 值 是 arm 


§ 今 集 特性 。 范 例 : --instruction-set 
features=div 





--instruction-set-features=... 


106 Te Ja PE aie EN Je AKA CONRES 
的 LLVM 编 译 框架 的 后 端 ) o YB: 
compiler-backend=Portable 默 认 值 是 ( 


--compiler-backend= 
(Quick|Optimizing|Portable) 


--compiler-filter=(verify- 指定 编译 器 的 过 滤 选 项 。 范 例 ，--cc 


nonelinterpret- Ed 
only|space|balanced|speed|everything) filter-everything 


--include-debug-symbols 分 别 用 于 指定 需要 或 者 不 需要 在 OA 
--no-include-debug-symbols 中 包含 ELF Symbols 


用 于 指定 运行 时 态 的 各 类 参数 ， 壁 ? 


--runtime-arg <argument> à cae . 
pe 堆 大 小 等 。 范 例 : --runtime-arg -Xm 





总 结 起 来 ，dex2oat 的 输入 输出 关系 如 图 21-47 所 示 。 
dezjarapk | 


image classes 





全 图 21-47 dex2oat 的 输入 输出 关系 


其 中 image 文 件 中 包含 了 一 些 预 初始 化 过 的 类 ， 这 样 可 以 保证 
Zygote 在 加 载 阶段 的 速度 得 到 提升 〈 虽 然 会 带 来 10MB 左 右 的 存储 空间 消 
耗 ) 。 预 初始 化 类 的 来 源 主 要 有 两 个 地 方 : 


(1) eR stg hl (可 以 参见 本 书 
的 “Android 启 动 过 程 简 析 ”章节 


(2) --image-classes 


值得 一 提 的 是 ，dex2oat 的 输出 结果 多 数 以 . odex 的 后 缀 名 来 存储 
(CAndroidM 版 本 ) 这 一 点 往往 会 让 开发 人 员 产 生 误 解 ， 将 它们 和 
Dalvik 中 的 优化 结果 相 混 淆 。Android 工 程 提 供 了 不 少 工具 来 辅助 大 家 
分 析 0AT 和 Dex， 存 储 路 径 是 A0SP 源 码 工 程 下 的 /out/host/PLATFORM/bin 
中 《比如 oatdump、dex2oat 等 ) 。 下 面 我 们 就 利用 oatdump 来 分 析 一 个 
实际 的 范 | Art product 
gener ic/system/app/Calculator/oat/Calculator. odex， 输 出 结果 如 
下 : 





MAGIC: 
oat 
064 


CHECKSUM: 
Oxe0f6120b 


INSTRUCTION SET: 
Thumb2 


INSTRUCTION SET FEATURES: 
smp,-div,-atomic_ldrd_strd 


oatdump 出 来 的 内 容 很 多 ， 包 括 Calculator 这 个 程序 里 所 有 的 实现 
体 、 体 系 结构 及 运行 时 的 地 址 信息 。 从 上 图 中 的 MAG1C NUMBER 不 难 发 
现 ， Calculator. odex 确 实 属 于 “oat” 文 件 。 或 者 我 们 也 可 以 使 用 fi le 
命令 来 做 进一步 观察 : 


s@ubuntu:~/Android_M/out/host/linux-x86/bin$ file Calculator .odex 
Calculator.odex: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux) 





, dynamically linked, stripped 


file 命 令 的 输出 结果 表示 Calculator. odex 不 仅 是 一 个 0AT 文 件 ， 而 
且 还 是 一 个 “ELF Shared 0bject”。 


21.4.2.3 ”第 三 方 应 用 程序 安装 过 程 中 的 OAT 编 译 


前 面 两 个 小 节 我 们 学 习 了 Android 系 统 工程 ROM 构 建 阶 段 生 成 OAT 文 
件 的 整个 流程 。 除 了 系统 ROM 中 内 置 的 Jar 包 和 预 装 的 APK 外 ， 还 有 一 个 
庞大 的 “Java 群 体 ” 也 需要 执行 dex2oat 编 译 一 一 即 第 三 方 应 用 程序 。 


对 第 三 方 应 用 程序 执行 dex2oat 最 合适 的 时 机 是 什么 时 候 ? 


显然 不 该 由 应 用 程序 厂商 完成 。dex2oat 必 须 是 针对 具体 的 硬件 平 
台 展 开 的 ， 而 APK 在 发 布 之 前 根本 无 法 精准 预测 用 户 手 中 的 硬件 设备 配 
置 。 基 于 以 上 原因 考虑 ， 由 Android 系 统 来 完成 针对 第 3 方 应 用 程序 的 
dex2oat 操 作 应 该 就 是 “情理 之 中 ”了 。 更 确切 地 说 ， 在 APK 应 用 程序 的 
安装 过 程 中 执行 dex2oat 就 是 最 佳 时 机 。 


接 下 来 我 们 先 从 普通 用 户 的 角度 出 发 ， 熟 悉 一 下 Android 应 用 程序 
的 安装 过 程 。 


用 户 在 通过 各 种 渠道 〈 璧 如 Google Play、 网 络 搜 索 、SD 卡 复制 
等 ) 获取 到 自己 需要 的 APK 文 件 后 ， 单 击 APK 文 件 打 开 ， 此 时 Android 系 
统 就 会 自动 启动 安装 流程 了 。 


那么 用 户 点 击 打 开 APK 文 件 时 ， 为 什么 会 自动 关联 到 Android 系 统 的 
安装 服务 呢 ? 


这 种 自动 关联 的 能 力 实 际 上 是 由 文件 管理 器 之 类 的 程序 通过 
startActivity 实 现 的 。 典 型 范例 如 下 : 


Uri uri = Uri.fromFile(new File("/mnt/sdcard/TestApk.apk")); 
Intent intent = new Intent(Intent.ACTION VIEW); 
intent.setDataAndType(uri, "application/vnd.android.package-archiv 
startActivity(intent); 


Android 系 统 中 啊 应 上 述 1ntent 的 是 一 个 叫做 
PackagelnstallerActivity 的 Activity， 其 源码 路 径 
是 /A0SP/packages/apps/packageinstaller。Package lnstal er 本身 
也 是 一 个 应 用 程序 ， 在 这 一 点 上 它 和 SystemU1 等 众多 系统 服务 的 实现 方 


式 是 一 致 的 。 


PackagelnstallerActivity 是 带 有 UI 显示 界面 的 ， 以 便 可 以 引导 用 
户 来 执行 安装 过 程 。 一 旦 用 户 在 客 面 上 点 选 了 同意 安装 协议 ， 那 么 它 就 
会 调用 另 一 个 组 件 Instal1AppProgress 来 进入 下 一 步 的 工作 。 


Instal1AppProgress 一 方面 会 在 前 台 青 面 显示 安装 的 进度 ， 另 一 方 
面 还 会 利用 Android 系 统 暴露 出 来 的 包 管 理 器 接口 (PackageManager ) 
来 执行 具体 的 安装 过 程 。PackageManager 是 一 个 本 地 代理 ， 其 最 终 对 应 
的 系统 服务 则 是 PackageManagerService。 


大 家 应 该 还 记得 Android 中 的 系统 服务 会 在 两 个 阶段 被 集中 启动 : 
e init.tc 


在 这 里 被 启动 的 多 数 是 本 地 程序 ， 如 vold、instal1d、 


Par 
ServiceManager ==. 


e SystemServer.java 


在 这 里 被 启动 的 多 数 为 Java 层 的 系统 服务 ， 如 LightsService、 
BatteryService 等 。 与 应 用 程序 安装 相关 联 的 PackageManagerService 
也 是 在 这 里 被 局 动 的 ， 核 心 代 码 如 下 所 示 : 


// Start the package manager. 

Slog.i(TAG, "Package Manager"); 

mPackageManagerService = PackageManagerService.main(mSyst 
mInstaller, mFactoryTestMode != FactoryTest.FACTORY_TES 


和 其 他 系统 服务 一 样 ，PackageManagerService 也 会 在 
ServiceManager 中 注册 ， 所 取 的 名 称 为 “package”。 这 样 其 他 进程 通 
过 ServiceManager. getService ( “package” ) 就 可 以 访问 它 所 提供 的 
服务 了 。 不 过 应 用 程序 通常 不 需要 直接 与 ServiceManager 打 交道 。 
Android 系 统 在 Context 环 境 (具体 的 实现 在 Context1lmp1)〉 中 提供 了 
getPackageManager 来 让 用 户 间 接 使 用 PackageManagerService 提 供 的 服 
务 。 另 外 ，getPackageManager 得 到 的 对 象 是 PackageManager 接 口 在 本 
地 的 实现 ， 即 AppblicationPackageManager 。 这 个 对 象 为 应 用 程序 使 用 
PackageManager 提 供 了 进一步 的 封装 。 


紧 接着 安装 程序 就 可 以 调用 PackageMangerServi ce 提供 的 
instal1ExistingPackageAsUser 或 instal1ExistingPackageAsUser 接 口 
来 进入 下 一 个 环节 了 。 其 中 前 者 针对 的 是 需要 安装 的 应 用 程序 在 系统 中 
CAFE BEES) 的 情况 ， 后 者 则 用 于 处 理 全 新 安装 时 的 情况 。 


到 目前 为 止 ， 应 用 程序 的 安装 流程 如 图 21-48 所 示 。 
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全 图 21-48 应 用 程序 的 安装 流程 (1/2) 


接 下 来 就 该 PackageManagerService“ 粉 墨 登 场 ” 了 。 


PackageManagerService 在 安装 APK 应 用 程序 的 过 程 中 ， 需 要 与 


init. rc 中 启动 的 另 一 个 名 为 installd (Install Daemon) 的 系统 服务 
进行 通信 : 


/*system/core/rootdir/init.rc*/ 
service installd /system/bin/installd 
class main 
socket installd stream 600 system system 


这 个 服务 对 应 的 源码 路 径 是 :frameworks/native/cmds/installd。 


PackageManagerService 中 持 有 一 个 成 员 变 量 mlnstaller， 如 下 所 


小: 


final Installer mInstaller; 


这 个 变量 是 PackageManagerService 与 instal1d 之 间 的 沟通 桥梁 
2 BSystanServer #e#yi#PackazeManagerServicekt Ei 弟 给 后 者 的 ， = 
质 上 是 一 个 SystemServi ce 的 实现 体 ; 


mInstaller = mSystemServiceManager.startService(Installer.class); 


SystemServer 负 责 启 动 上 述 的 Instal ler 服 务 ， 后 者 则 在 内 部 通过 
Instal lerConnect ion 与 jnstal1d 建 立 通信 连接 。 这 种 连接 是 基于 UNIX 
Domain Socket 完 成 的 ， 这 一 点 在 init. rc 启动 instal1d 时 所 用 的 脚本 语 
句 中 也 可 以 看 出 来 : 


socket installd stream 600 system system 


InstallerConnection 连 接 instal1d 的 核心 语句 如 下 所 示 : 


/*frameworks/base/core/java/com/android/internal/os/InstallerConn 
private boolean connect() { 
if (mSocket != null) {// 如 果 已 经 成 功 建立 连接 ， 那 么 无 需 重复 操作 
return true; 








Slog.i(TAG, "connecting..."); 


try { 
mSocket = new LocalSocket();//Unix Domain Socket 


LocalSocketAddress address = new LocalSocketAddress(" 
LocalSocketAddress.Namespace.RESERVED) ; 


mSocket .connect(address);// 开 始 连 接 ， 直 到 成 功 才 会 返回 。 如 是 





mIn = mSocket.getInputStream(); //HFMinstalldii ay 
mOut = mSocket.getOutputStream(); // 用 于 向 installd 写 入 关 
} catch (IOException ex) { 
disconnect(); 
return false; 
} 


return true; 


J 


Connect WZ RA, Installer 5instal dè EaP MEMI nA 
m0ut 来 互相 传送 数据 了 。 我 们 以 本 小 节 需 要 解答 的 ， 如 何 对 第 三 方 应 用 
程序 进行 0AT 编 译 的 问题 为 例 ， 看 下 Installer Connection 和 instal1d 
两 者 之 间 的 大 致 交互 过 程 一 一 首先 PackageMangerServi ce 会 判断 被 安装 
的 APK 是 否 需要 进行 dex2oat 编 译 。 如 果 答 案 是 肯定 的 话 ， 它 会 进一步 调 
AB CAR Smlnstal ler PANdexopt AŽ : 


/*frameworks/base/services/core/java/com/android/server/pm/Instal 
public int dexopt(String apkPath, int uid, boolean isPublic, Stri 
if (!isValidInstructionSet(instructionSet)) {// 指 令 集 是 否 合 
Slog.e(TAG, "Invalid instruction set: " + instruction 

return -1; 


} 


return mInstaller.dexopt(apkPath, uid, isPublic, instruct 


} 


大 家 要 注意 有 两 个 mlnstaller 变 量 ， 上 述 dexopt 遂 数 中 出 现 的 
mlnstaller 指 的 是 Installer Connection 对 象 。 它 所 对 应 的 dexopt 实 现 
三 | 
是 : 


/*frameworks/base/core/java/com/android/internal/os/InstallerConn 
public int dexopt(String apkPath, int uid, boolean isPublic, 
String instructionSet, boolean vmSafeMode) { 
StringBuilder builder = new StringBuilder ("dexopt"); 
builder.append(' '); 
builder .append(apkPath) ; 


builder. 
builder. 
builder. 
builder. 
builder. 
builder. 
builder. 
builder. 
builder. 


append(' '); 
append(uid); 
append(isPublic ? " 1" 
append(' '); 
append(pkgName); 
append(' '); 
append(instructionSet ); 
append(' '); 
append(vmSafeMode ? " 1" 


" 0"); 


" 0"); 


return execute(builder.toString()); 


} 


StringBuilder 负 责 构造 需要 向 instal1d 传 弟 的 命令 和 详细 参数 ， 
譬如 apkPath、pkgName 等 。 因 为 jnstal1d 是 一 个 Linux 平 台 上 的 可 执行 
程序 ， 所 以 我 们 在 函数 的 末尾 调用 execute 来 执行 它 。execute 只 是 做 了 
一 个 简单 的 封装 ， 旋 即 又 会 调用 transact 函 数 ， 如 下 所 示 : 


/*frameworks/base/core/java/com/android/internal/os/InstallerConn 
public synchronized String transact(String cmd) { 
if (!connect()) {// 如 果 目 前 有 可 用 连接 ， 那 么 connect 会 直接 返回 true 
Slog.e(TAG, "connection failed"); 
return "-1"; 








} 


if (!writeCommand(cmd)) {// 向 instal1d 写 入 带 参数 的 命令 
Slog.e(TAG, "write command failed? reconnect!"); 
if (!connect() || !writeCommand(cmd) ) {// 如 果 写 入 失败 ， 可 
// 常 ， 此 时 尝试 重新 





return "-1";V// 仍 然 失 败 ， 返 回 错误 码 
} 
} 


final int replyLength = readReplLy();// 读 取 instal1d 的 执行 结 绿 
if (replyLength > 0) { 
String s = new String(buf, 0, replyLength); 
if (LOCAL_DEBUG) { 
Slog.i(TAG, "recv: '" +s + "'"); 





return s; 
} else { 
if (LOCAL_DEBUG) { 
Slog.i(TAG, "fail"); 
} 


return "-1"; 


这 样 一 来 PMS 就 成 功 地 把 安装 命令 发 送 给 instal1ld 了 。 


和 其 他 多 数 系 统 Daemon 程 序 类 似 ，instal1d 的 工作 流程 也 是 : 局 
动 -> 等 待 连接 -> 接收 命令 -> 处 理 命令 ， 如 此 循环 往复 。 其 中 instal1d 中 
处 理 命令 的 具体 函数 是 execute: 


/*frameworks/native/cmds/installd/installd.c*/ 


static int execute(int s, char cmd[BUFFER_MAX] ) 
{ 

char reply[REPLY_MAX]; 

char *arg[TOKEN_MAX+1]; 

unsigned i; 

unsigned n = 0; 

unsigned short count; 

int ret = -1; 

reply[0] = 0; 


/* n is number of args (not counting arg[0]) */ 
arg[0] = cmd; 
while (*cmd) { // 处 理 所 有 调用 参数 ， 并 保存 到 arg 数 组 (注意 : 数组 最 大 容量 
if (isspace(*cmd)) {// 以 空格 为 分 隔 符 ， 这 点 和 InstallerConnectic 
*cmd++ = 0; 
nt++; 
arg[n] = cmd; 
if (n == TOKEN_MAX) { 
ALOGE("too many arguments\n"); 
goto done; 























cmd++; 


} 


for (i = 0; i < sizeof(cmds) / sizeof(cmds[0]); i++) {//cmds 数 组 用 
//Hand1ler ek 
if (!strcmp(cmds[i].name,arg[0])) { 
if (n != cmds[i].numargs) {// 函 数 参数 是 否 合法 
ALOGE("%s requires %d arguments (%d given)\n", 
cmds[i].name, cmds[i].numargs, n); 
} else { 
ret = cmds[i].func(arg + 1, reply);//#\4sHandler 
} 


goto done; 





I 


ALOGE( "unsupported command '%s'\n", arg[0]); 


done: 
wl JASE FES 


return 0; 

















Instal1d 内 部 维护 着 一 个 cmds 数 组 ， 用 于 管理 command 和 正确 的 
Handler 之 间 的 映射 〈 璧 如 “dexopt” 命 令 对 应 的 处 理 函 数 是 
do_dexopt) 。 这 种 写法 在 daemon 类 型 的 程序 中 很 常见 ， 大 家 可 以 留意 


一 人 下。 不 过 do_dexopt 并 没有 做 很 多 工作 ， 它 会 进一步 调用 dexopt 郴 
数 。 后 者 的 代码 实现 比较 长 ， 我 们 重点 关注 与 dex2oat 编 译 相关 的 部 
ZN 


J]: 


/*frameworks/native/cmds/installd/commands.c*/ 

int dexopt(const char *apk_path, uid_t uid, bool is_public, 
const char *pkgname, const char *instruction_set, 
bool vm_safe_mode, bool is_patchoat) 


struct utimbuf ut; 

struct stat input_stat, dex_stat; 

char out_path[PKG_PATH_MAX]; 

char persist_sys_dalvik_vm_lib[PROPERTY_VALUE_MAX]; 
char *end; 

const char *input_file; 

char in_odex_path[PKG_PATH_MAX]; 

int res, input_fd=-1, out_fd=-1; 


if (strlen(apk_path) >= (PKG_PATH_MAX - 8)) { 
return -1; 
} 


property_get("persist.sys.dalvik.vm.lib.2",persist_sys_dalvik_vm_ 
"libart.so");// 确 认 虚 拟 机 类 型 

















strcpy(out_path, apk_path); 
end = strrchr(out_path，'.');// 和 寻找 路 径 中 最 后 一 个 “.” 
if (end != NULL && !is_patchoat) { 

strcpy(end, ".odex"); 

if (stat(out_path, &dex_stat) == 0) { 


return 0; 
} 
} 
if (create_cache_path(out_path, apk_path, instruction_set)) { 
return -1; 
} 
if (is_patchoat) 4... 
} else { 
input_file = apk_path; 
} 


memset(&input_stat, ©, sizeof(input_stat) ); 
stat(input_file, &input_stat); 


input_fd = open(input_file，0_RDONLY，0);// 打 开 输 入 文件 ， 即 APK 文 
if (input_fd < 0) { 


ALOGE("installd cannot open '%s' for input during dexopt\ 
return -1; 


} 


unlink(out_path); 
out_fd = open(out_path, O_RDWR | O_CREAT | O_EXCL, 0644);// 创 |]? 
if (out_fd < 0) { 
ALOGE("installd cannot open '%s' for output during dexopt 
goto fail; 


} 
if (fchmod(out_fd, 
S_IRUSR|S_IWUSR|S_IRGRP | 
(is_public ? S_IROTH : 0)) < 0) {// 改 变 文件 权限 
ALOGE("installd cannot chmod '%s' during dexopt\n", out_p 
goto fail; 


} 

if (fchown(out_fd, AID_SYSTEM, uid) < 0) {// 改 变 owner 
ALOGE("installd cannot chown '%s' during dexopt\n", out_p 
goto fail; 

} 


// Create profile file if there is a package name present. 

if (strcmp(pkgname, "*") != 0) { 
create_profile_file(pkgname, uid); 

} 


// 开 始 执行 转换 工作 
pid_t pid; 
pid = fork(); 
if (pid == 0) {// 子 进程 ， 这 是 真正 执行 dex20at 编 译 的 地 方 
if (setgid(uid) != 0) {// 设 置 group id 
ALOGE("setgid(%d) failed in installd during dexopt\n" 
exit(64); 




















} 

if (setuid(uid) != 0) {// 设 置 user id 
ALOGE("setuid(%d) failed in installd during dexopt\n" 
exit(65); 

} 


if (strncmp(persist_sys_dalvik_vm_lib, "libdvm", 6) == 0) 
run_dexopt(input_fd, out_fd, input_file, out_path); 
} else if (strncmp(persist_sys_dalvik_vm_lib, "libart", 6 
if (is_patchoat) { 
run_patchoat(input_fd, out_fd, input_file, out_pa 
} else { 
run_dex2oat(input_fd, out_fd, input_file, out_pat 
set, vm_safe_mode) ; 


} else { 
exit(69); /* Unexpected persist.sys.dalvik.vm.lib v 


exit(68); /* only get here on exec failure */ 
} else {// 父 进程 ， 需 要 等 待 子 进程 任务 完成 

res = wait_child(pid); 

if (res == 0) { 





ALOGV("DexInv: --- END '%s' (success) ---\n", input_f 
} else { 

ALOGE("DexInv: --- END '%s' --- status=0x%04x, proces 

goto fail; 


} 


ut.actime = input_stat.st_atime; 
ut.modtime = input_stat.st_mtime; 
utime(out_path, &ut); 


close(out_fd); 
close(input_fd); 
return 0; 


fail: 
// 出 错 处 理 
return -1; 





上 述 代码 段 中 ， 系 统 属性 值 “persist. sys. dalvik. vm. lib. 2” AA 
于 指示 当前 系统 使 用 的 虚拟 机 类 型 〈 如 Art 或 dalvik 虚 拟 机 ) ; ARE 
量 out_path 和 input_file 分 别 用 于 表示 dexopt 的 输出 结果 和 输入 文件 。 
其 中 out_path 简 单 来 说 就 是 把 apk_path 的 后 缀 名 更 改 为 “. odex”， 而 
input_file 则 表示 APK 文 件 的 存储 路 径 。 不 过 out_path 的 最 终 值 要 在 调 
用 了 create cache_path 之 后 才能 被 确认 下 来 。 


0ut_path 路 径 的 样式 如 下 所 示 : 
/data/dalvik-cache/[instruction_set]/[LA“@”" (t#apk_pathPHy”/” J 

随后 dexopt 尝 试 打开 APK 文 件 ， 同 时 根据 out_path 生 成 一 个 odex 输 
出 文件 。 同 时 我 们 需要 对 这 两 个 输入 输出 文件 做 多 个 设置 步骤 才能 保证 
它们 能 被 正常 使 用 ， 辟 如 更 改 它们 的 文件 权限 、 文 件 所 有 者 等 。 


通过 前 面 几 个 小 节 的 学 习 ， 我 们 知道 OAT 编 译 最 终 是 由 dex20at 完 成 
的 。 后 者 是 一 个 独立 的 程序 ， 因 而 需要 为 它 的 运行 创建 一 个 新 的 进程 。 


紧 接着 dexopt 需 要 针对 当前 平台 的 具体 情况 来 做 进一步 处 理 一 一 假 
设 是 Dalvik 虚 拟 机 的 话 ， 执 行 的 是 run_dexopt; 否则 才 是 调用 


run_dex2oat: 


/*frameworks/native/cmds/installd/Commands.c*/ 

static void run_dex2oat(int zip_fd, int oat_fd, const char* input. 
const char* output_file_name, const char *pkgname, const char 
bool vm_safe_mode) 


{ 
static const char* DEX20AT_BIN = "/system/bin/dex2oat"; 
sprintf(zip_fd_arg, "--zip-fd=%d", zip fd); 
sprintf(zip_location_arg, "--zip-location=%s", input_file_nam 
execv(DEX20AT_BIN, (char* const *)argv); 
ALOGE("execl(%s) failed: %s\n", DEX20AT_BIN, strerror(errno) ) 
} 


上 述 这 个 函数 的 大 部 分 篇 幅 是 在 处 理 dex2oat 所 需 的 参数 ， 例 如 “一 
-zip-fd”、“--zip=location” 等 。 这 些 参 数 与 我 们 在 Android 系 统 构 
建 过 程 中 讲解 的 dex2oat 编 译 选 项 是 完全 一 致 的 ， 大 家 如 果 有 疑问 的 话 
可 以 回头 复习 一 个 。 


可 以 看 到 ，dex2oat 在 设备 中 的 存储 位 置 是 /system/b in/dex2oat。 
APK 应 用 程序 对 应 的 文件 摘 述 符 会 通过 “--zip-fd” 选项 传递 给 
dex2oat， 这 是 因为 APK 本 身 就 是 一 个 Zip 压 缩 包 。 最 终 execv 调 用 
dex2oat， 并 通过 已 经 包含 了 各 种 参数 的 argv 来 为 转换 工作 提供 各 种 上 
下 文 环境 。 整 个 转换 工作 完成 了 以 后 ，dexopt 这 个 父 进程 才能 返回 ， 并 
报告 处 理 结果 。 

至 此 ， 针 对 第 三 方 应 用 程序 的 dex20at 编 译 就 顺利 完成 了 ， 它 需 
涉及 文件 管理 器 (或 者 其 他 启动 系统 安装 流程 的 程序 ) 、Package 
Manager Service、instal1d 等 多 个 系统 组 件 。 


图 21-49 是 整个 处 理 流 程 的 下 半 部 分 ， 供 大 家 杭 理 参考 。 












Tun_dexdoat 


Package ManagerService cc sede Comin sede Comin S p Chis Process 
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instellPackage | | | 
— 4 
| | | 
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ml | | 
| cxexule | | 
| 
| | 
| | 
| | 
| | 
| | 
| | 
! writeCommand | 
| | 
| | 
| | 
do dexopt | 
| | 
| | 
| | 
| exopt | 
| 
| 
| 
| 
| 


fork 





| 
| 
| | execy (/systennybin/dex2oat) 
| 


全 图 21-49 应 用 程序 的 安装 流程 (2/2) 


21.5 Android 虚 拟 机 的 典型 启动 流程 


我 们 知道 每 一 个 应 用 程序 都 有 自己 独立 的 虚拟 机 运行 时 环境 , 那么 
具体 是 由 谁 来 负责 启动 虚拟 机 ， 又 是 如 何 启 动 的 呢 ? 


我 们 首先 回顾 一 下 Android 系 统 的 开机 流程 ， 特 别 是 内 核 局 动 完成 
后 系统 所 做 的 工作 ， 或 许 立 即 就 会 有 管 案 了 ， 如 图 21-50 所 示 。 


system 


SerVICes 





全 图 21-50 “系统 启动 ”流程 


Android 系 统 中 的 第 一 个 进程 是 init， 后 者 又 通过 解析 init. rc 脚本 
来 启动 关键 的 守护 进程 和 各 种 系统 服务 一 一 其 中 就 包括 了 zygote 这 个 
Android 应 用 程序 的 “ 旷 化 器 ”。 值 得 一 提 的 是 ，zygote 本 身 也 是 由 
Java 语 言 编 写 的 ， 所 以 同样 需要 虚拟 机 环境 。 而 系统 中 后 续 启 动 的 应 用 
程序 多 数 〈 注 意 : 这 并 不 是 绝对 的 ) 是 从 zygote 中 fork 出 来 的 。 


脚本 init. rc 中 与 zygote 相 关 的 内 容 如 下 : 


service zygote /system/bin/app_process -Xzygote /system/bin --zyg 


class main 

socket zygote stream 660 root system 

onrestart write /sys/android_power/request_state wake 
Onrestart write /sys/power/state on 

onrestart restart media 

onrestart restart netd 


进程 app_process 是 zygote 的 载体 ， 其 源码 对 应 的 目录 


是 /frameworks/base/cmds/app_process。 当 app_process 启 动 后 ， 会 调 
用 AndroidRuntime 的 start 国 数 ， 如 下 所 示 : 


/*frameworks/base/cmds/app_process / app_main.cpp*/ 
int main(int argc, char* const argv[]) 


{ 
"if (zygote) { 
runtime.start("com.android.internal.os.ZygoteInit", args) 
} else if (className) { 
runtime.start("com.android.internal.os.RuntimeInit", args 
} else { 
} 
由 上 述 代码 段 可 以 看 到 ，zygote 的 入 口 
是 “com. android. internal.os.Zygotelnit” ; AndroidRuntime: : 


start 则 负责 启动 并 管理 Android 虚 拟 机 : 


/*frameworks/base/core/jni/AndroidRuntime.cpp*/ 
void AndroidRuntime::start(const char* className, const Vector<St 


i 


/*Step1. 初始 化 JNI 环 境 */ 

JniInvocation jni_invocation; 

jni_invocation.Init(NULL);//Init 函 数 的 参数 为 library 库 名 ， 参 见 后 续 i 

JNIEnv* env; 

if (startVm(&mJavaVM, &env) != 0) {/*Step2. 启动 虚拟 机 ，mJavaVM 
return; 








} 
onvmCreated(env);/*Step3. 虚拟 机 创建 成 功 ， 执 行 回调 函数 通知 调用 者 */ 


if (startReg(env) < 0) {/*Step4. 注册 native 函 数 。 这 些 都 是 预 设 的 jn 
ALOGE("Unable to register all android natives\n"); 
return; 


} 


jclass stringClass; 
jobjectArray strArray; 
jstring classNameStr; 


stringClass = env->FindClass("java/lang/String"); 
assert(stringClass != NULL); 

strArray = env->NewObjectArray(options.size() + 1, stringClas 
assert(strArray != NULL); 

classNameStr = env->NewStringUTF(className) ; 
assert(classNameStr != NULL); 
env->SetObjectArrayElement(strArray, 0, classNameStr); 


for (size_t i = 0; i < options.size(); ++1) { 
jstring optionsStr = env->NewStringUTF(options.itemAt(1). 
assert(optionsStr != NULL); 
env->SetObjectArrayElement(strArray, i + 1, optionsStr); 


} 
/*Step5 .开始 执行 目标 对 象 的 主 函 数 
*/ 


char* slashClassName = toSlashClassName(className); 
jclass startClass = env->FindClass(slashClassName) ; 
if (startClass == NULL) { 
ALOGE("JavaVM unable to locate class '%s'\n", slashClassN 
/* keep going */ 
} else { 
jmethodID startMeth = env->GetStaticMethodID(startClass, 
"(LLjava/lang/String; )V"); 
if (startMeth == NULL) { 
ALOGE("JavaVM unable to find main() in '%s'\n", class 
/* keep going */ 
} else { 
env->CallStaticVoidMethod(startClass, startMeth, strA 
} 


上 述 代码 段 就 是 Android 中 使 用 和 管理 虚拟 机 的 典型 流程 。 而 且 不 


论 是 Dalvik 或 者 Art 《或 者 是 未 来 其 他 可 能 的 新 型 虚拟 机 ) ， 它 们 都 必 


须 遵 循 一 致 的 管理 方式 





这 是 保证 Android 虚 拟 机 兼容 性 的 关键 所 


接 下 来 我 们 将 主要 针对 这 5 个 步骤 展开 。 表 面 上 看 似 简单 的 几 步 ， 


但 其 内 部 实现 却 异 Fe SER 所 以 我 们 需要 花 多 个 小 节 的 阐述 才能 履 盖 它 
DBAS, Hae “ZR” ERY 采 入 的 方式 可 以 更 好 地 为 大 
家 Te r ae. 


Step1@ AndroidRuntime: :start。 在 启动 虚拟 机 之 前 ， 需 要 初始 化 
当前 的 运行 环境 。 具体 是 由 Jni lnvocation 的 Init 函 数 完 成 的 ， 如 下 所 
示 : 


/*libnativehelp/JniInvocation.cpp*/ 
bool JniInvocation::Init(const char* library) { 
library = GetLibrary(library); TEE E BER HE BR 


handle_ = dlopen(library, RTLD_NOW) ;// 打 开 虚 拟 机 动态 链接 库 


/* 接 下 来 分 别 查 找 VM 库 中 的 3 个 重要 接口 实现 */ 
if (!FindSymbol(reinterpret_cast<void**>(&JNI_GetDefault JavaVMI 
"JNI_GetDefaultJavaVMInitArgs")) { 
return false; 





if (!FindSymbol(reinterpret_cast<void**>(&JNI_CreateJavaVM_), 
"JNI_CreateJavaVM")) { 
return false; 


} 
if (!FindSymbol(reinterpret cast<void**>(&JNI_ GetCreatedJavaVMs 


"JNI_GetCreatedJavaVMs")) { 
return false; 


l 


return true; 


ERRA A m GetLibrary KAANAA EAR. MIF 
EPERERA, libraryS E BAEK Ini tHAHASHREA, (BH 
实际 值 去 p 是 NULL。 

GetLibrary 中 的 处 理 逻 辑 又 细 分 为 如 下 两 种 情 ) 

e 如 果 系 统 属性 tro.debuggable 为 0 
表示 当前 不 是 可 调试 版 本 ， 此 时 1ibrary 直 接 赋 值 为 1ibart. so. 


。 系统 属性 ro.debuggable 为 1 


此 时 将 1ibrary 设 置 为 用 户 通 过 persist. sys. dalvik. vm. lib. 2 设 定 
的 值 一 一 如 果 这 个 属性 没有 被 赋值 的 话 ， 默 认 仍 然 采用 1ibart. so. 


在 Art 和 Dalvik 并 存 的 时 期 (如 Android 4.4) ， 用 户 可 以 在 系统 菜 
单 中 提供 的 选项 来 选择 希望 采用 的 虚拟 机 类 型 。 用 户 的 选择 同时 会 被 保 
存 成 系统 属性 值 ， 并 在 上 述 1nit 函 数 中 作为 虚拟 机 类 型 的 判断 依据 CORK 
认 值 是 Dalvik) 。 当 Art 虚 拟 机 趋 于 稳定 以 后 ， 两 种 虚拟 机 并 存 的 关系 
就 被 打破 了 (Android 5. 1 以 上 ) 系统 已 经 不 再 支持 Dalvik， 而 改 
由 Art “一枝 独 秀 ”。 


Art 和 Dalvik 虚 拟 机 动态 库 之 间 的 关系 可 以 用 图 21-51 来 表示 。 





Applications 
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全 图 21-51 Dalvik 和 Att 庶 拟 机 库 的 并 存 关 系 


获取 到 1ibrary 库 的 名 称 后 〈 通 常情 况 下 就 是 “libart. so”) ,我 
们 需要 先 通 过 dlopen (library，RTLD_NOW) 把 它 打 开 并 加 载 到 内 存 
中 。5C 语 言 为 处 理 动 态 链接 库 提 供 了 很 多 便利 的 函数 ， 包 括 dlopen、 
dlsym、dladdr 等 ， 它 们 统一 由 bionic/1inker 提 供 。 其 中 dlopen 用 于 以 
指定 的 模式 来 打开 动态 链接 库 ; RTLD_NOW 则 表示 在 dlopen () 时 就 直接 解 
析 所 有 未 定义 的 符号 。 


成 功 打 开 虐 拟 机 的 动态 链接 库 libart. so) 以 后 ， 我 们 紧 接 着 
需要 查找 它 所 包含 的 3 个 关键 的 接口 实现 ， 即 
JN| GetDefaultJavaVMInitArgs、JNI CreateJavaVM 和 和 
JNI1_GetCreatedJavaVMs， 并 分 别 保 存在 对 应 的 变量 中 (需要 特别 注意 
一 下 ， 这 些 变 量 名 最 后 会 以 下 划 线 结尾 ， 如 JNI_CreateJavaVM ) > X 
几 个 函数 有 什么 作用 了 呢 ? 一 一 我 们 可 以 将 它们 理解 为 任何 Android 虚 拟 
机 都 必须 实现 的 “门户 入 口 ”。 换 句 话 说， 无 论 是 Art、Dalvik 抑 或 是 
未 来 可 能 的 其 他 Android 虚 拟 机 ， 都 必须 实现 这 3 个 接口 ， 这 样 才能 保证 
Android 系 统 正确 地 使 用 和 控制 它们 。 所 以 如 果 通 过 FindSymbol 无 法 找 
到 它们 中 的 任何 一 个 接口 函数 的 话 ， 都 将 导致 失败 。 


Step2@ AndroidRuntime: :start。 国 数 startVM 虽 然 很 长 ， 但 实际 
完成 的 核心 工作 只 有 如 下 两 个 : 
o 初始 化 虚拟 机 人 参数 


和 Hotspot 等 JDK 标 准 虚 拟 机 一 样 ，Dalvik/Art 同 样 支持 一 系列 的 配 
置 参数 ， 而 且 它 们 在 很 多 参数 属性 上 是 相似 的 ， 辟 如 “-Xms”“- 
Xmx” “-XX:BackgroundGC=” 等 。Android 初 始 化 这 些 参 数 所 采用 的 默 
认 值 通常 来 源 于 系统 变量 ， 例 如 下 面 所 示 的 两 条 语句 : 


parseRuntimeOption("dalvik.vm.heapstartsize", heapstartsizeOp 
parseRuntimeOption("dalvik.vm.heapsize", heapsizeOptsBuf, "-Xmx", 


分 别 指定 了 堆 空 间 的 起 始 值 和 最 大 值 。 
e 调用 JNI_CreateJavaVM 
上 述 步骤 中 的 所 有 人 参数 值 将 保存 在 mn0ptions@AndroidRunt ime 中 ， 


这 是 一 个 JavaVM0ption 类 型 的 全 局 变量 ， 然 后 通过 JN1_CreateJavaVM 这 
一 标准 接口 传递 给 具体 的 虚拟 机 实现 。 


一 旦 JNI1_CreateJavaVM 成 功 返 回 后 ， 那 么 就 可 以 认为 虚拟 机 已 经 处 
于 就 绪 状 态 ， 并 可 以 接受 一 系列 的 JN1 调 用 了 。 


小 结 : 


要 点 1，Android 虚 拟 机 无 论 是 Dalvik 或 是 Art 都 以 动态 链接 库 
的 形式 提供 功能 ， 并 且 需 要 实现 固定 的 3 个 接口 以 保证 兼容 性 。 


要 点 2， 从 操作 系统 的 角度 来 讲 ， 虚 拟 机 程序 和 普通 的 进程 并 
没有 什么 本 质 区 别 。 


要 点 3， 虚 拟 机 分 为 Java 和 Native 两 个 层面 ， 它 们 之 间 需 要 有 
效 的 通信 互 访 机 制 ， 即 JN1。 通 常情 况 下 虚拟 机 的 创建 者 和 管理 者 
位 于 Native 中 ， 然 后 利用 JNI 来 与 Java 进 行 访问 操作 ; 反之 亦 然 。 
在 startVm 这 个 场景 下 ，JNI1_CreateJavaVM 成 功 执行 后 会 得 到 一 个 
JNIEnv 的 指针 变量 ， 这 是 后 续 访问 JVM 的 关键 所 在 。 


JNIEnv 的 定义 在 jni. h 中 ， 它 是 对 JNINativelnterface 的 
typedef， 而 最 终 的 实现 类 则 是 JNIEnvExt。 


Step3@ AndroidRuntime::start。 经 过 上 面 两 个 步骤 的 努力 ， 虚 拟 
机 已 经 成 功 创 建 〈“ 具 体 过 程 后 续 小 节 有 详细 分 析 ) 完成 了 ， 此 时 我 们 需 
要 通过 回调 函数 通知 用 户 ， 即 onymCreated。 在 app_process 这 个 场景 
中 ， 用 户 是 指 继承 于 AndroidRuntime 的 AppRuntime， 后 者 则 实现 了 自己 
的 onVmCreated。 上 有 具体 代码 可 以 参见 App_main. cpp 文 件 。 


Step4@ AndroidRuntime: :start。 为 虚拟 机 注册 本 地 函数 ， 代 码 如 
TF: 
/*static*/ int AndroidRuntime::startReg(JNIEnv* env) 


{ 
/* 这 条 语句 是 保证 后 续 线 程 的 创建 都 可 以 被 attach 到 虚拟 机 上 的 关键 */ 
androidSetCreateThreadFunc((android_create_thread_fn) javaCre 














env->PushLocalFrame(200) ; 

if (register_jni_procs(gRegJNI, NELEM(gRegJNI), env) < 0) { 
env->PopLocalFrame(NULL); 
return -1; 


env->PopLocalFrame(NULL) ; 


return 0; 


PushLocalFrame 和 PopLocalFrame 的 作用 是 管理 局 部 引用 的 生命 周 
期 ， 它 们 必须 配套 出 现 。 所 以 一 旦 我 们 在 某 个 函数 中 使 用 了 
PushLocalFrame， 那 么 在 此 函数 的 每 一 个 可 能 的 出 口 〈 如 return 语 句 ) 
都 必须 要 有 相应 的 pop 操作， 否则 会 引发 程序 异常 。 


级 数 register_jni_procs 用 IRec 列 表 中 包含 的 所 
有 Native Method， 包 括 下 述 所 示 的 节选 


static const RegJNIRec gRegJNI[] = { 
REG_JNI(register_com_android_internal_os_RuntimeInit), 
REG_JNI(register_android_os_SystemClock), 
REG_JNI(register_android_util_EventLog), 
REG_JNI(register_android_util_Log), 


Llregister_android util Log 为 例 ， 它 最 终 调 用 的 是 Java 虐 拟 机 
中 的 Regi sterNativeMethods， 并 且 将 a EPT AALS ARH eK 
数 注册 到 Java 层 的 “管理 者 ”中 ， 如 下 所 示 : 


static JNINativeMethod gMethods[] = { 
/* name, Signature, funcPtr */ 
{ "isLoggable", "(Ljava/lang/String;1I)Z", (void*) androi 
{ "println_native", "(IILjava/lang/String;Ljava/lang/String; 
}; 


我 们 再 对 照 分 析 一 下 Java 层 提供 的 Log 接 口 : 


/*frameworks/base/core/java/android/util/Log.java*/ 
public static native boolean isLoggable(String tag, int level); 


public static native int println_native(int bufID,int priority, S 


通过 上 面 的 注册 过 程 ，Java 层 的 jsLoggable 及 println_native 就 与 
本 地 层 的 实现 Candroid_util Log isLoggable 以 及 
android_util_Log println_native) “对 接 ” 成 功 了 。 从 JNI 的 内 部 实 
现 角 度 来 看 ，JVM“ 管 理 者 ”所 做 的 工作 是 将 这 些 本 地 函数 设置 为 
ArtMethod 的 JNI 入 口 。 我 们 在 后 续 小 节 中 还 会 有 进一步 分 析 。 


Step5@ AndroidRuntime: :start。“ 万 事 俱 备 ， 只 和 欠 东 风 ” 一 一 现 
在 我 们 要 做 的 就 是 把 任务 下 发 给 虚拟 机 了 。 大 致 流程 是 先 利用 
GetStaticMethod1D 找 到 目标 类 (Zygotelnit) 中 的 main 函 数 ， 然 后 再 
通过 Cal1StaticVoidMethod 来 执行 它 ， 从 而 开启 一 个 Java 程 序 的 “生命 
之 旅 ”。 我 们 会 在 后 续 小 节 进 行 详细 解析 ， 这 里 先 不 蒙 述 。 


这 样 一 来 典型 的 Android 虚 拟 机 的 启动 过 程 就 讲解 完了 。 从 调用 者 
的 角度 来 看 ， 使 用 Android 平 台 的 虚拟 机 只 有 5 个 核心 步骤 ; 从 系统 内 部 
实现 的 角度 看 ， 隐 藏 在 这 5 个 步骤 后 的 原理 却 是 相当 复杂 的 。 所 以 接 下 
来 我 们 就 要 深入 到 它们 的 内 部 来 为 大 家 呈现 一 场 虚 拟 机 的 “内 部 盛 
mB” 了 : 


。 启动 和 初始 化 虚拟 机 的 内 部 实现 过 程 
即 上 述 的 Step1-Step3, 将 在 本 小 节 剩 余 内 容 中 做 详细 分 析 。 
。 虚拟 机 是 如 何 执行 Java 程 序 的 
对 应 上 述 Step4-Step5 的 内 部 实现 ， 将 在 后 续 小 节 中 进行 讲解 。 


其 中 Step1-Step3 的 最 核心 工作 又 体现 在 startym 这 个 函数 中 ， 因 而 
我 们 针对 它 来 做 重点 分 析 : 


/*frameworks/base/core/jni/AndroidRuntime.cpp*/ 
int AndroidRuntime::startVm(JavaVM** pJavaVM, JNIEnv** pEnv) 


if (JNI_CreateJavaVM(pJavaVM, pEnv, &initArgs) < 0) { 
ALOGE("JNI_CreateJavaVM failed\n"); 
goto bail; 


前 面 我 们 提 到 过 ，startym 函 数 的 大 部 分 篇 幅 都 是 在 处 理 
JavaVMOpt ion 对 象 一 一 从 名 称 不 难看 出 ， 它 是 Java 虚 拟 机 的 配置 选项 集 
合 ， 包 括 “-Xms” “-Xmx” “-XX:BackgroundGC” 等 。 大 家 不 难 发 现 
Android 虚 拟 机 和 标准 的 Java 虚 拟 机 所 支持 的 参数 种 类 和 样式 都 是 非常 
相似 的 。 除 了 处 理 配置 参数 之 外 ，startVm 鹃 数 会 在 末尾 调用 到 
libart. so 或 者 1ibdvm. so 提供 的 一 个 重要 接口 ， 即 JNI_CreateJavaVM。 





在 Art 虚 拟 机 场景 下 ，JNI1_CreateJavaVM 郧 数 是 由 java_vm ext. cc 


文件 提供 的 ， 具 体 对 应 的 源码 目录 是 /art/runtime， 如 下 所 示 : 


/*art/runtime/java_vm_ext.cc*/ 
extern "C" jint JNI_CreateJavaVM(JavaVM** p_vm, JNIEnv** p_env, v 


RuntimeOptions options; 
for (int i = 0; i < args->nOptions; ++i) {// 解 析 所 有 的 虚拟 机 选项 
JavaVMOption* option = &args->options[i]; 
options.push_back(std::make_pair(std::string(option->optionSt 
option->extralInfo) ); 





bool ignore_unrecognized = args->ignoreUnrecognized; 

if (!Runtime::Create(options, ignore_unrecognized)) {// 创 建 一 个 Rl 
ATRACE_END(); 
return JNI_ERR; 

} 


Runtime* runtime = Runtime::Current(); 
bool started = runtime->Start();// 通 过 Runtime 来 启动 其 所 管理 的 虚拟 机 
if (!started) {// 处 理 启动 失败 的 情况 


s 


*p_env = Thread: :Current()->GetJniEnv(); 
*p_vm = runtime->Get JavavM();//3k7$ G2 双 启 动 完 成 的 虚拟 机 实例 ， 并 通过 函 
// 以 便 后 者 可 以 在 需要 的 时 候 访问 和 控制 ER 



























































ATRACE_END(); 
return JNI_OK; 


JNI _CreateJavaVM 首 先 会 通过 一 个 Static 函 数 Runt ime: :Create 来 
创建 单 实例 对 象 Runtime 〈 和 希望 大 家 已 经 能 “条 件 反 射 ” 般 地 联想 到 这 
是 单 实例 的 典型 样式 ) ， 并 调用 Runtime: :1nit 来 初始 =, 
括 Image 的 加 载 、 垃圾 回收 器 的 雏形 等 。 我 们 可 以 把 Runt ime 理 解 为 
Android 虚 拟 机 的 “大 总 管 ”， 它 负责 提供 Dav1ick/Art 的 运行 时 环境 。 
用 户 提供 的 所 有 虚拟 机 选项 世 都 会 交 由 Runtime 处 理 。 


Runtime: :1nit 郧 数 很 长 ， 其 中 最 值 和 导 我 们 关心 的 是 它 对 boot. art 
和 boot. oat 的 加 载 过 THE, 如 下 所 示 是 节选 的 核心 代码 : 


/*art/runtime/runtime.cc*/ 
bool Runtime::Init(const RuntimeOptions& raw_options, bool ignore 

















l heap_ = new gc::Heap(...);//Step1. 创建 堆 管 理 对 象 














java_vm_ = new JavaVMExt(this, options.get());//Step2. 创建 Java 上 


=| 
Fe 


有 


Thread: :Startup(); 
Thread* self = Thread: :Attach("main", false, nullptr, false);// 





class_linker_ = new ClassLinker(intern_table_); //Step4. 新 建 Cla 
//Step5. 初始 化 Class Linker 
if (GetHeap()->HasBootImageSpace()) {// 当 前 Heap 中 是 否 包含 Boot Imac 
std::string error_msg; 
bool result = class_linker_->InitFromBootImage(&error_msg); 





} else { 
std::vector<std::string> dex_filenames; 
Split(boot_class_path_string_, ':', &dex_filenames); 


std::vector<std::string> dex_locations; 

if (!runtime_options.Exists(Opt::BootClassPathLocations)) { 
dex_locations = dex_filenames; 

} else { 
dex_locations = runtime_options.GetOrDefault (Opt: :BootClass 
CHECK_EQ(dex_filenames.size(), dex_locations.size()); 


std: :vector<std: :unique_ptr<const DexFile>> boot_class_path; 
if (runtime_options.Exists(Opt::BootClassPathDexList)) { 
boot_class_path.swap(*runtime_options.GetOrDefault 
(Opt: :BootClassPathDexList 
} else { 
OpenDexFiles(dex_filenames, 
dex_locations, 
runtime_options.GetOrDefault(Opt::Image), 
&boot_class_path); 
} 
instruction_set_ = runtime_options.GetOrDefault (Opt: :ImageIns 
std::string error_msg; 
if (!class_linker_->InitWithoutImage(std::move(boot_class_pat 
LOG(ERROR) << "Could not initialize without image: " << err 
return false; 


} 


Step1@Runtime: : Init. 创建 Heap 对 象 ， 这 是 虚拟 机 管理 堆 内 存 的 起 
。 我 们 将 在 后 续 小 节 中 做 专门 介绍 。 


Step2@Runtime: : Init. 创建 一 个 JavaVMExt 对 象 。 需 要 特别 留意 的 
gJnilnvokelnterface， 这 里 存储 的 是 JNI 的 预 置 消 数 ， 后 续 我 们 还 会 
专门 介绍 。 


J 


Step3@Runtime: : Init. 在 创建 ClassLinker 之 前 ， 需 要 先 Attach 主 
线程 。 那 么 这 里 的 “Attach” 应 该 怎么 理解 呢 ? 我 们 可 以 从 源码 的 角度 
来 回答 这 个 问题 : 


/*art/runtime/Thread.cc*/ 
Thread* Thread: :Attach(const char* thread_name, bool as_daemon, J 


bool create_peer) { 


Thread* self; 
Runtime* runtime = Runtime: :Current();//YEM: Runtime 是 进程 单 实 例 


MutexLock mu(nullptr, *Locks::runtime_shutdown_lock_); 
if (runtime->IsShuttingDownLocked()) { 


} 
} 


/* 如 果 Runtime 己 经 处 于 关闭 状态 ， 那 么 将 拒绝 新 线程 的 Attach*/ 
LOG(ERROR) << "Thread attaching while runtime is shutting d 
return nullptr; 

else { 

Runtime: :Current()->StartThreadBirth(); 
/x*StartThreadBirth 和 EndThreadBirth 必 须 配套 使 用 。 它 们 分 别 会 对 一 个 : 
threads_being_born_ 执 行 加 1 和 减 1 的 操作 。 换 名 话说 ， 如 果 threads_beil 
那么 就 表示 当前 有 一 个 Thread 正 在 初始 化 */ 

self = new Thread(as_daemon) ;// 新 建 一 个 线程 类 
self->Init(runtime->GetThreadList(), runtime->GetJavaVM()); 
Runtime: :Current()->EndThreadBirth();// 初 始 化 结束 

















CHECK_NE(self->GetState(), kRunnable); 
self->SetState(kNative);// 设 置 当前 状态 为 kNative, 即 运行 在 Native 环 境 中 


return self; 


Mik Attach eX MP HRT A MARR fal Andro i dE FUL ZR E SEE WL il 
的 一 点 端倪 。Dalvik/Art 和 Java 标 准 虚拟 机 一 样 都 支持 多 线程 ， 管 理 这 
些 线程 的 重任 就 落 在 了 Runt ime 的 身上 。 每 一 个 刚 “ 出 生 ” 的 线程 ， 都 
首先 需要 通过 Init 哨 数 注册 到 Runtime 内 部 的 线程 列表 中 ， 如 下 所 示 : 
void Thread: :Init(ThreadList* thread_list, JavaVMExt* java_vm) {... 


tlsPtr_.jni_env = new JNIEnvExt(this, java_vm); 
thread_list->Register(this); 


虚拟 机 中 的 每 个 线程 都 有 自己 独立 的 JN1 环 境 ， 所 以 上 述 代 码 段 中 
会 为 新 线程 分 配 一 个 自己 的 JNIEnvExt， 紧 接着 再 将 自己 注册 到 


thread | ist 管 理 列 表 中 。 


我 们 知道 ，Android 虚 拟 机 既 要 能 执行 Java 代 码 ， 也 必须 能 处 理 
Native 层 的 实现 ， 而 且 这 两 种 情况 是 需要 区 分 对 待 的 。 以 
Thread: :Attach 为 例 ， 它 当前 处 于 Native 环 境 中 ， 因 而 线程 状态 会 被 置 
为 kNative。Art 虚 拟 中 的 线程 还 有 很 多 其 他 状态 ， 如 下 所 示 〈 大 家 可 以 
参考 每 个 状态 后 面 的 注释 了 解 它 们 的 含义 ， 我 们 就 不 歼 述 了 ) : 


enum ThreadState { 


// Thread.State JDWP state 

kTerminated = 66, // TERMINATED TS_ZOMBIE Thread.run has retur 

kRunnable, // RUNNABLE TS_RUNNING runn 

kTimedWaiting, // TIMED WAITING TS_WAIT in 0 

kSleeping, // TIMED WAITING TS_SLEEPING in T 

kBlocked, // BLOCKED TS_MONITOR bloc 

kWaiting, // WAITING TS_WAIT in 0 

kwWaitingForGcToComplete, // WAITING TS_WAIT bloc 

kWaitingForCheckPointsToRun, // WAITING TS_WAIT GC 
to run 

kwWaitingPerformingGc, // WAITING TS_WAIT perf 

kwWaitingForDebuggerSend, // WAITING TS_WAIT bloc 
events to be sent 

kwWaitingForDebuggerToAttach, // WAITING TS_WAIT bloc 
debugger to attach 

kWaitingInMainDebuggerLoop, // WAITING TS_WAIT bloc 
processing debugger events 

kwWaitingForDebuggerSuspension, // WAITING TS_WAIT wait 
suspend all 

kWaitingForJniOnLoad, // WAITING TS_WAIT wait 
of dlopen and JNI on load code 

kWaitingForSignalCatcherOutput, // WAITING TS_WAIT wait 
catcher IO to complete 

kWaitingInMainSignalCatcherLoop, // WAITING TS_WAIT bloc 
processing signals 

kWaitingForDeoptimization, // WAITING TS_WAIT wait 
suspend all 

kWaitingForMethodTracingStart, // WAITING TS_WAIT wait 
to start 

kStarting, // NEW TS_WAIT nati 
yet ready to run managed code 

kNative, // RUNNABLE TS_RUNNING runn 

kSuspended, // RUNNABLE TS_RUNNING susp 
debugger 


}; 


717E 


Step4@Runtime: : Init. 成功 将 主线 程 Attach 到 Runt ime 环 境 中 以 
， 现 在 可 以 创建 Class Linker 了 。 简 单 来 说 ， 这 个 “类 链接 器 ”的 职 
是 管理 Java Class 以 及 Class 内 部 的 所 有 对 象 。 
Step5@Runtime:: Init. 初始 化 Class Linker。 根 据 当 前 环境 中 是 
BEE Image Space 可 以 细 分 为 如 下 两 种 情况 
情况 1，Heap 中 包含 了 Boot Image Space 的 情况 
大 家 应 该 能 猜想 到 这 里 的 Image 默 认 指 的 是 boot. art GES: 不 排 


除 用 户 自己 提供 一 个 定制 的 Image 的 可 能 性 ) 。 此 时 Class Linker 可 以 
直接 调用 InitFromBoot1mage 来 从 Image 文 件 中 提取 出 Boot Class 


Path， 并 保存 到 boot_class_path_ 中。 
GetHeap () 函数 获取 的 是 前 面 Runtime: :1nit 中 创建 的 gc: :Heap 类 型 
即 内 存 堆 管理 器 。 而 GetHeap () ->HaslmageSpace () 


的 heap_ 成 员 变 量 ， 
则 用 于 判断 当前 堆 对 象 中 是 否 含有 Image 空间 。 怎 么 理解 Image Space 


呢 ? 
先 来 看 一 下 函数 HasBoot1lmageSpace， 它 的 实现 如 下 所 示 : 


bool HasBootImageSpace() const { 
return !boot_image_spaces_.empty(); 


} 
其 中 boot image spaces 是 一 个 
std: :vector<space: :1mageSpace*》> 类 型 的 变量 ， 这 说 明 1mageSpace 的 
数量 理论 上 可 以 不 止 一 个 (虽然 当前 版 本 中 实际 还 是 只 有 一 个 
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ImageSpace) 。 
ImageSpace 继 承 自 MemMapSpace， 后 者 又 继承 自 ContinuousSpace， 
表明 它 是 一 个 连续 的 空间 ; 另外 系统 中 还 有 很 多 不 连续 的 空间 ， 它 们 


继承 自 Di scont inuousSpace， 如 图 21-52 所 示 。 


virtual bool [sContinuousSpace() const {return false; | 
virtual bool IsDiscontinuousSpace() const {return false; | 







ContinuousSpace DiscontimuousSpace 


virtual boo! IsContinuousSpace() const! virtual boo! IsContinuousSpace() const! 
return true; | return true; | 





全 图 21-52 连续 和 不 连续 空间 的 继承 关系 


换 句 话说 ， 继 承 自 ContinuousSpace 的 对 象 为 连续 空间 ; 反之 继承 
自 Di scontinuousSpace 的 对 象 则 为 不 连续 空间 。 依 此 判断 逻辑 ， 结 合 代 
码 分 析 我 们 可 以 得 出 属于 连续 空间 的 对 象 有 :，lmageSpace、 
ZygoteSpace 等 。 


ImageSpace 是 在 Heap 构 造 过 程 中 同步 生成 的 ， 对 应 语句 如 下 : 


Space: :ImageSpace* boot_image_space = space::ImageSpace::Cr 
image_name.c_str(), 
image_instruction_set, 
index > 0, 
&error_msg); 


其 中 image_name 的 赋值 分 为 两 种 情况 ， 其 一 是 使 用 Android 虚 拟 机 
调用 者 〈 例 如 AndroidRuntime) 主动 通过 “-Ximage” 人 参数 指定 的 一 个 
Image; 如 果 调 用 者 没有 这 么 做 ， 并 且 当 前 compi ler_callbacks 为 nu|| 
的 话 ， 那 么 程序 将 把 它 默认 赋值 为 : 


GetAndroidRoot ()+ "/framework/boot. art", 
BN /system/framework/boot. art 


我 们 在 前 面 小 节 说 过 ， 系 统 会 在 必要 的 时 候 (Android WM 版 本 中 是 
在 应 用 程序 的 安装 过 程 中 ) 通过 dex2oat 把 APK 中 的 Dex 编 译 为 本 地 的 机 
器 码 。 在 这 一 操作 过 程 中 ，dex2oat 事 实 上 也 会 启动 一 个 虚拟 机 ， 所 以 
这 里 的 compi ler_callbacks_ 即 是 这 种 编译 器 场景 下 的 “回调 函数 ” 


因为 Android 中 的 虚拟 机 是 以 动态 库 的 形式 〈 如 1ibart. so) 存在 
的 ， 并 对 外 提供 JNI1_GetDefaultJavavMInitArgs、JNI_CreateJavaVM 和 
JN1_GetCreatedJavaVMs 三 个 公共 的 接口 。 所 以 它 并 不 会 特别 关心 调用 
者 是 zygote 或 是 dex2oat 抑 或 是 其 他 对 象 。 


KF Image Space 及 其 他 Space 的 更 多 分 析 ， 可 以 参见 后 面 的 Heap 小 


情况 2， 当 前 Heap 中 没有 包含 Image 的 情况 


通常 这 种 情况 会 发 生 在 dex2oat (因为 dex20at 也 会 启动 一 个 虚拟 
机 ， 并 通过 指定 “compilercal lbacks” 来 获取 回调 ) 进程 中 ， 此 时 需 
要 调用 InitWithout1mage 来 确定 Boot Class Path. InitWithout Image 
的 入 参 boot_class_path 实 际 上 是 一 个 DexFi le 的 Vector 对 象 ， 其 中 的 所 
有 元 素 都 会 被 AppendToBootClassPath 添 加 到 boot class path 中。 


对 于 情况 1， 系 统 只 需要 直接 加 载 image 就 可 以 了 ; 而 另 一 种 情况 下 
虚拟 机 系统 就 只 能 通过 手工 来 主动 创建 和 加 载 Dex 文 件 了 。 

至 此 VM 的 创建 和 初始 化 就 基本 上 完成 了 。 接 下 来 jni_internal 中 的 
的 JN1_CreateJavaVM 会 通过 调用 Start 隐 数 来 启动 已 经 成 功 创建 的 虚拟 


机 对 象 ， 其 中 涉及 改变 当前 线程 的 运行 状态 、 创 建 ClassLoader 等 各 个 
环节 。 


下 面 我 们 给 出 虚拟 机 在 创建 和 初始 化 阶段 的 流程 图 ， 如 图 21-53 所 
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A 21-53 VM 的 创建 和 启动 流程 


21.6 EEA METERA 


从 前 面 小 节 的 学 习 中 ， 我 们 知道 Heap 堆 管理 器 将 在 Runtime: : Init 
中 完成 构建 和 初始 化 。 

Android 虚 拟 机 中 的 堆 空 间 有 多 种 不 同类 型 ， 它 们 在 Heap 类 中 都 有 
对 应 的 成 员 变 量 ， 如 表 21-9 所 示 。 


表 21-9 堆 空 间 类 型 及 释义 


所 有 的 连续 空间 集合 ， 
ee < ee * 5 y 
std::vector<space::ContinuousSpace*> 对 象 将 被 保存 在 一 个 连 


continuous_spaces_; 续 的 内 存 范围 内 





所 有 的 不 连续 空间 集 


std::vector<space::DiscontinuousSpace*>|| 人 ee 

è — ’ X H kbA ZN 

discontinuous_spaces_; aA TRH BES TL 
存储 


ZS 
std::vector<space::AllocSpace*> 四 


alloc_spaces_; 空间 集合 





space::MallocSpace* 在 这 里 ， 这 和 Art 中 采用 
non_moving_space_; 的 Compact 内 存 回 收 算 
法 有 关联 





Art 中 的 堆 内 存 分 配器 
(allocator) 有 多 种 类 


space::RosAllocSpace* rosalloc_space_; 型， 这 个 空间 是 专门 为 
kAllocatorTypeRosAlloc 
分 配器 服务 的 


HE See] 
A 


a * 
space::DIMallocSpace* dlmalloc_space_; kAllocatorTypeDIMalloc 


Ty BC a HRA A) 


GC 用 于 保存 和 复制 进程 
space::MallocSpace* main_space_; eee cee Bu 


间 之 一 的 代名词 





space::LargeObjectSpace* 这 个 空间 简单 来 说 用 于 
large_object_space_; 大 体积 对 象 的 存储 





为 什么 我 们 需要 这 么 多 的 Space 变 量 ， 它 们 之 间 又 有 什么 关联 呢 ? 


首先 ， 需 要 强调 的 是 ， 这 些 空 间 并 非 完全 独立 的 。 更 确切 地 讲 ， 上 
述 变 量 所 描述 的 部 分 空间 区 域 是 存在 重 倒 的 。 He spaces_ 
是 一 个 vector 变 量 ， 它 表 示 Heap 中 所 有 连续 空间 的 集合 ; 而 
main_space 本身 也 属于 连续 空间 ， 它们 是 对 同一 空间 的 不 同 维度 的 描 


述 。 


Kg 


ag 


从 继承 关系 上 来 看 ， 这 些 XXSpace 之 间 可 以 说 是 “息息相关 ”的 ， 
如 图 21-54 所 示 。 


+yirtual bool IsContinuousSpace(}() 
taccounting::LargeObjectBilmap* Gell iveBitmap}(} 


+accounting::LargeObjectBitmap*GetLiveBiumapt() 








I)iscontinuousSpace 
virtual boo! IsContinuousSpace(\) | T+ virtual uint64 1 OetBytesAllocaled( =0; 0) | 
thyle* Begin(}() 


+virlual uinl64 t GetObiectsAllocated =0; ()| Lrviwual bool IsContinuousSpace()) 
+hyle*Fnd()() A 


ImageSpace ContinuousMemMapAllocSpace |argeObjectSpace 


| | 
EE 
| 
I i | 


RosAllocSpace DIMallocSpace 


全 图 21-54 各 种 Space 类 的 继承 关系 


最 顶层 的 类 有 两 种 ， 即 Space 和 Al locSpace。 前 者 提供 了 与 “存储 
空间 ”有 关 的 属性 ， 而 Al locSpace 则 负责 对 象 的 分 配 管理 。 如 果 把 上 述 
的 关系 图 理解 为 非 严格 意义 上 的 “ 树 ”， 那 么 其 树叶 节点 则 由 
ImageSpace, RosAl locSpace, DIMal locSpace 等 元 素 组 成 一 一 这 些 元 素 
才 是 Space 的 真正 载体 。Space. h 中 专门 为 它们 分 配 了 对 应 的 类 型 值 ， 如 
下 所 示 : 


enum SpaceType { 


kSpaceTypeImageSpace, ImageSpace 
kSpaceTypeMallocSpace, D1iMallocSpace 
kSpaceTypeZygoteSpace, ZygoteSpace 
kSpaceTypeBumpPointerSpace, BumpPointerSpace 
kSpaceTypeLargeObjectSpace, LargeObjectSpace 


ti 


这 么 多 类 型 的 Space 对 象 ， 它 们 在 Androi d 虚 拟 机 运行 时 环境 中 的 内 
存 布局 是 怎么 样 的 呢 ? 解答 这 个 问题 的 办 法 是 阅读 Heap : :Heap 构 造 函 数 
的 代码 实现 ， 答 案 如 下 : 


(1) ImageSpace 后 面 紧 跟着 的 是 与 它 对 应 的 0at 文 件 。 


(2) 如 果 separate non moving space (代表 我 们 需要 单独 的 non 
moving space) 为 true， 则 分 为 两 种 情况 : 其 一 是 当前 进程 为 Zygote， 
那么 此 时 Non moving space 的 起 点 是 Zygote Space; 否则 就 是 单纯 的 
non moving space. 


(3) 如 果 上 述 的 separate_non_moving_space 为 true， 那 么 接 下 来 
的 Space 的 起 始 地 址 是 低地 址 空间 (300M) . Other spaces 需 要 根据 垃 
圾 回收 器 的 类 型 而 定 ， 例 如 kCol1lectorTypeCC 对 应 的 是 Region Space. 


(4) 用 于 分 配 内 存 的 核心 区 域 叫做 MainSpace， 它 的 类 型 属于 
RosAllocSpace 或 者 DIMal1locSpace。 


还 有 一 个 问题 相信 也 是 大 家 所 关心 的 一 一 即 这 些 Space 中 提供 的 存 
储 空间 究竟 从 何 而 来 ， 又 是 在 什么 时 候 申请 得 到 的 呢 ? 


以 ImageSpace 为 例 ， 它 是 Runtime: :1nit 创 建 Heap 对 象 时 ， 由 后 者 





在 构造 过 程 中 同步 生成 的 。 下 面 我 们 重点 分 析 一 下 这 个 流程 : 


/*art/runtime/gc/heap.cc*/ 
for (size_t index = 0; index < image _file_names.size(); ++in 
std::string& image_name = image_file_names[index]/; 
std::string error_msg; 
space: :ImageSpace* boot_image_space = space::ImageSpace::Cr 
image_name.c_str(), 
image_instruction_set, 
index > 0, 
&error_msg); 


Android N 版 本 中 支持 多 个 jimage 文 件 ， 这 一 点 从 image_file_names 
这 个 vector 也 可 以 看 出 来 。 对 于 image_file_names 中 的 每 一 个 元 素 ， 我 
们 通过 CreateBoot Image 来 生成 它们 对 应 的 Boot Image. 
CreateBoot1mage 函 数 很 长 ， 但 真正 生成 Image 的 地 方 在 于 它 调用 的 Init 
范 数 ， 因 而 我 们 重点 讲解 一 下 后 者 〈 分 段 阅 读 ) 


/*art/runtime/gc/space/Image_space.cc*/ 

ImageSpace* ImageSpace::Init(const char* image _ filename, 
const char* image_location, 
bool validate_oat_file, 
const OatFile* oat_file, 
std::string* error_msg) { 


std: :unique_ptr<File> file; 


TimingLogger: :ScopedTiming timing("OpenImageFile", &logger); 
file.reset(0OS: :OpenFileForReading(image_filename) ); 


ImageHeader temp_image_header; 

ImageHeader* image_header = &temp_image_header ; 

{ 
TimingLogger::ScopedTiming timing("ReadImageHeader", &logger ) 
bool success = file->ReadFully(image_header, sizeof(*image_he 
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const auto& bitmap_section = 
image_header ->GetImageSection(ImageHeader: :kSect 
const size_t image_bitmap_offset = RoundUp(sizeof (ImageHeader ) 
image_header ->GetDataSize(), 
const size_t end_of_bitmap = image_bitmap_offset + bitmap_secti 
if (end_of_bitmap != image_file_size) {... 
return nullptr; 


首先 要 做 的 是 打开 Image 文件 (Sai 况 下 以 . art 为 后 缀 名 ) ， 

后 提取 Header 头 部 。 我 们 在 前 面 小 节 曾 经 简单 介绍 过 Image Header, oo 
包含 的 信息 很 多 一 ”比如 Image 内 容 区 域 和 其 对 应 的 0at 区 域 的 起 始 地 
址 、 所 占 的 空间 大 小 、 是 否 支 持 PIC (Position Independent Code) 
等 。 在 这 个 场景 中 我 们 主要 想 获 取 如 下 这 些 信息 : 


@ image_begin_#Himage_size_ 


这 两 个 值 可 以 通过 image header. Get |mageBeg in () 和 
image_header. Get lmageSize() 获得 ， 前 者 表示 lmage 文 件 期 望 的 内 存 映 
射 地 址 ， 后 者 则 是 映射 的 区 域 大 小 。 


° image_bitmap_offset_#timage_bitmap_size_ 


Bitmap 是 什么 ? 它 用 于 描述 Image Space 中 各 个 对 象 的 “存活 ” 信 
息 ， 是 GC 垃 圾 回收 器 的 工作 基础 之 一 。 不 过 Image Space 比 较 特殊 ， 它 
是 不 需要 进行 垃圾 回收 操作 的 《类 型 为 
kGcRetentionPolicyNeverCollect) ， 所 以 理论 上 并 不 需要 像 其 他 类 型 
的 Space 那 样 提 供 Live Bitmap 和 Mark Bitmap 两 类 Bitmap。 


Image 内 部 会 被 分 为 7 个 Section， 定 义 如 下 : 


enum ImageSections { 
kSectionObjects, 
kSectionArtFields, 
kSectionArtMethods, 
kSectionDexCacheArrays, 
kSectionInternedStrings, 
kSectionClassTable, 
kSectionImageBitmap, 
kSectionCount, // Number of elements in enum. 


}; 


通过 GetlmageSection (lmageHeader ::kSectionlmageBitmap) 得 
到 的 是 一 个 Bitmap 区 ， 它 主要 用 于 垃圾 回收 过 程 。 从 上 面 的 enum 值 可 
知 ， 这 个 区 域 位 于 Image 文 件 的 尾部 : 


std: :vector<uint8_t*> addresses(1, image_header ->GetImageBegin( 
if (image_header->IsPic()) {// 支 持 位 置 无 关 特 性 


// Can also map at a random low_4gb address since we can relo 
addresses.push_back(nullptr); 
} 


std: :unique_ptr<MemMap> map; 
std::string temp_error_msg; 
for (uint8_t* address : addresses) { 
TimingLogger: :ScopedTiming timing("MapImageFile", &logger); 


std::string* out_error_msg = (address == addresses.back()) ? 
const ImageHeader::StorageMode storage_mode = image_header ->G 
if (storage mode == ImageHeader::kStorageModeUncompressed) { 


map.reset(MemMap: :MapFileAtAddress(address, 
image_header ->GetImageSize(), 
PROT_READ | PROT_WRITE, 
MAP_PRIVATE, 
file->Fd(), 
0, 
/*low_4gb*/true, 
/*reuse*/false, 
image_filename, 
/*out*/out_error_msg) ); 
} else 4.. 
} 
if (map != nullptr) {// 按 优先 级 来 处 理 ， 一 旦 成 功 就 没有 必要 尝试 后 续 的 at 
break; 
} 


Í 




















得 到 了 Image Header 以 后 ， 接 下 来 就 可 以 考虑 它 的 内 容 区 域 了 。 要 
完成 的 任务 也 很 好 理解 ， 实 际 上 就 是 把 Image“ 有 用 ”的 内 容 读 取 到 内 
存 中 来 ， 以 便 后 续 直接 访问 使 用 。 和 普通 文件 不 同 的 是 ，Image 是 被 直 
接 映射 到 内 存 中 的 ， 因 而 并 不 需要 繁琐 的 初始 化 过 程 。 这 同时 也 是 它 能 
加 速 应 用 程序 局 动 速度 的 秘诀 所 在 。 


MapF i leAtAddress 的 第 一 个 参数 是 Image 和 希望 被 映射 到 的 内 存 地 

址 ， 这 个 值 优 先 取 Image Header 中 设 定 的 image_begin_ 因为 采用 这 
个 地 址 将 1mage 映 射 到 内 存 中 来 ， 意 味 着 后 面 我 们 就 不 需要 为 它 的 内 部 
地 址 引用 做 很 多 修正 工作 了 ， 所 以 相对 而 言 效 率 会 高 一 些 。 如 果 |mage 
支持 P10 的 话 ， 我 们 也 可 以 考虑 把 它 map 到 1ow_4gb 内 的 任何 地 址 上 。 上 
述 代码 段 中 的 for 循 环 会 根据 addresses 中 存储 的 元 素 逐 一 尝试 
MapFileAtAddress， 一 旦 有 一 个 成 功 的 话 就 不 用 再 考虑 后 续 低 优先 级 的 
address 了 。 另 外 ，lmage 目 前 支持 多 种 存储 方式 ， 即 





kStorageModeUncompressed 〈 不 压缩 ) ~ kStorageModeLZ44 
kStorageModeLZ4HC《〈 后 面 这 两 种 都 采用 了 LZ24 无 损 压 缩 技 术 ， 它 的 优点 
在 于 压缩 和 解压 缩 过 程 的 速度 都 相当 快 。 具 体 可 以 参考 
https://code. google. com/p/1z4/) o 


接 下 来 MapFi1eAtAddress 会 进一步 调用 Maplnternal， 而 后 者 最 终 

则 是 通过 mmap 来 完成 对 Image 的 内 存 映射 操作 。 真 正 的 映射 地 址 ， 以 及 

其 他 相关 信息 都 会 被 封装 在 一 个 新 创建 的 MemMap 中 ， 并 传递 给 上 述 代 码 
段 中 的 map 变 量 : 


DCHECK_EQ(0, memcmp(image_header, map->Begin(), sizeof(ImageHea 





std: :unique_ptr<MemMap> image_bitmap_map(MemMap: :MapFileAtAddre 
bitmap_se 
PROT_READ 
file->Fd( 
image_bit 
/*low_4gb 
/*reuse* 
image_fi 
error_ms 


TimingLogger: :ScopedTiming timing("RelocateImage", &logger); 
if (!RelocateInPlace(*image_header, 
map->Begin(), 
bitmap.get(), 
oat_file, 
error_msg)) { 
return nullptr; 


} 


} 

// We only want the mirror object, not the ArtFields and ArtMet 

std::unique_ptr<ImageSpace> space(new ImageSpace(image_filename 
image_location, 
map.release(), 
bitmap.release(), 
image_end)); 


Runtime* runtime = Runtime::Current(); 
CHECK_EQ(oat_file != nullptr, image_header->IsAppImage()); 
if (image_header->IsAppImage()) {... 
} else if (!runtime->HasResolutionMethod()) { 
runtime->SetInstructionSet (space->oat_file_non_owned_-> 
GetOatHeader().GetInstructionSet() 





runtime->SetResolutionMethod(image_header -> 
GetImageMethod(ImageHeader: :kResol 


n 


return space.release(); 


J 


提 醋 大 家 注意 的 是 ， 上 述 代 码 段 中 共 出 现 了 两 个 MemMap ， 分 别 用 于 
映射 Image 和 Bitmap。 前 面 我 们 介绍 过 ， 假 如 Image 被 映射 到 的 内 存 地 址 
取 的 是 Image Header 中 设 定 的 image_begin_ ， 那 么 就 不 需要 做 额外 的 重 
定位 工作 一 一 此 时 Relocate1lnPlace 经 过 判断 后 会 直接 返回 。 


FA), Boot lmage 中 还 包含 很 多 公共 的 函数 例如 Resolution 
Method, CalleeSave Method) 和 配置 (lnstruction Set) ， 它 们 也 都 
需要 被 提取 并 保存 到 Runtime 中 ， 以 保证 后 续 程 序 代 码 的 正确 执行 。 


到 目前 为 止 ， 我 们 分 析 的 都 是 Image 文 件 已 经 存在 的 情况 下 的 处 理 
过 程 ， 那 么 如 果 是 Image 文 件 缺 失 的 情况 呢 ? 这 时 候 就 涉及 Image 的 产生 
过 程 了 〈 这 样 一 来 下 一 次 就 可 以 直接 使 用 Image 来 加 快速 度 了 ) ， 即 
Generatelmage 的 实现 : 





/*art/runtime/gc/space/Image_space.cc*/ 
static bool GenerateImage(const std::string& image_filename, Inst 
std::string* error_msg) { 
const std::string boot_class_path_string(Runtime: :Current()->Ge 
std: :vector<std::string> boot_class_path; 
Split(boot_class_path_string, ':', boot_class_path);//boot clas 
if (boot_class_path.empty()) {//Boot Class Path 不 存在 ， 无 法 生成 Ima 
*error_msg = "Failed to generate image because no boot class 
return false; 








} 
if (Runtime::Current()->IsZygote()) {// 当 前 如 果 是 Zygote 进 程 的 话 ， 清 
LOG(INFO) << "Pruning dalvik-cache since we are generating an 
need to recompile"; 
PruneDexCache(image_isa); 
} 


std::vector<std::string> arg_vector; 





std::string dex2oat(Runtime: :Current()->GetCompilerExecutable( ) 
arg_vector.push_back(dex2oat ); 


std::string image_option_string("--image=") ; 


image_option_string += image_filename; 
arg_vector.push_back(image_option_string); 


for (size_t i = 0; i < boot_class_path.size(); i++) { 
arg_vector.push_back(std::string("--dex-file=") + boot_class_ 


} 


std::string oat_file_option_string("--oat-file="); 
oat_file_option_string += 

ImageHeader : :GetOatLocationFromImageLocatio 
arg_vector.push_back(oat_file_option_string); 


Runtime: :Current()->AddCurrentRuntimeFeaturesAsDex20atArguments 


return Exec(arg_vector, error_msg) ;//iz{rdex2oat fer KA MmImage x 


在 生成 Image 之 前 首先 要 确定 系统 指定 了 哪些 Boot Class Path. M 
名 称 上 不 难看 出 ， 这 些 路 径 既 是 Image 的 “输入 源 ”， 也 是 
与 “Boot” 息 息 相 关 的 换 句 话 来 说 ， 它 是 为 大 部 分 应 用 程序 所 共用 
的 “class” 的 集合 地 。 


那么 Boot Class Path 是 在 哪里 指定 的 呢 ? 通常 情况 下 ， 
Runtime: : Init 会 把 正确 的 值 保 存 到 Runtime 对 象 内 部 的 成 员 变量 
boot_class_path_string 中 《上述 代码 段 中 GetBootClassPathString 
函数 返回 的 就 是 这 个 变量 ) 。 而 Runt ime 会 根据 以 下 两 点 来 确定 出 Boot 
Class Path 的 具体 值 : 





e 环境 变量 BOOTCLASSPATHL; 
o 虚拟 机 调用 者 通过 “-Xbootclasspath: ”参数 特别 指定 的 Boot Class 
Path 。 


而 且 后 者 的 优先 级 《如果 存在 的 话 ) 要 高 于 前 者 ， 这 就 好 比 是 司机 
首先 得 遵守 交警 的 现场 指挥 一 样 。 不 过 需要 注意 的 是 ， 如 果 当 前 有 可 用 
的 Boot Image， 那 么 Boot Class Path 将 直接 来 源 于 它 ， 而 不 会 再 重新 
计算 。 

Android 旧 版 本 中 ， 环 境 变量 B00TCLASSPATH 通 常会 在 init. rc 或 者 
其 import 的 rc 文件 中 被 export 到 系统 中 ;最 新 的 Android 版 本 中 对 此 进 


行 了 调整 ， 改 由 编译 系统 来 完成 这 个 任务 。 具 体 而 言 ，Android 系 统 工 
程 /system/core/rootdir 目 录 下 的 Android. mk 会 在 


PRODUCT_BOOTCLASSPATH 这 个 变量 发 生 改 变 时 重新 生成 init. environ. rc 
文件 。 而 后 者 实际 上 又 是 由 init. environ. rc. in 这 个 模板 文件 加 上 一 些 
必要 的 处 理 步 又 创建 出 来 的 ， 例 如 : 


# set up the global environment 

on init 
export ANDROID_ BOOTLOGO 1 
export ANDROID ROOT /system 
export ANDROID_ASSETS /system/app 
export ANDROID_DATA /data 
export ANDROID _STORAGE /storage 
export ASEC_MOUNTPOINT /mnt/asec 
export LOOP_MOUNTPOINT /mnt/obb 
export BOOTCLASSPATH %BOOTCLASSPATH% 
export SYSTEMSERVERCLASSPATH %SYSTEMSERVERCLASSPATH% 


Android. mk 会 根据 当前 的 实际 情况 填 
充 “B00TCLASSPATH” 和 “SYSTEMSERVERCLASSPATH” 的 具体 值 ， 然 后 导 
出 到 init. environ. rc 文件 中 。 那 么 PRODUCT_B00TCLASSPATH 中 包含 哪些 
必要 的 路 径 呢 ? 


/*build/core/dex_preopt.mk*/ 

DEXPREOPT_BOOT_JARS := $(subst $(space), :,$(PRODUCT_BOOT_JARS) ) 
DEXPREOPT_BOOT_JARS_ MODULES := $(PRODUCT_BOOT_JARS) 
PRODUCT_BOOTCLASSPATH := $(subst $(space),:, 

$(foreach m,$(DEXPREOPT_BOOT_JARS_MODULES), /system/framework/$(m) 


从 上 面 这 上段 脚本 的 处 理 逻 辑 来 看 ，PRODUCT_BOOTCLASSPATH 最 终 需 
要 依赖 于 PRODUCT_B00T_JARS 才 能 得 到 正确 的 结果 。PRODUCT_B00T_JARS 
属于 产品 类 属性 ， 典 型 的 范例 如 下 : 


PRODUCT_BOOT_JARS := \ 
core-libart \ 
conscrypt \ 
okhttp \ 
core-junit \ 
bouncycastle \ 
ext \ 
framework \ 
telephony-common \ 
voip-common \ 
ims-common \ 


其 中 framework 包 含 了 各 种 AP1 的 真实 的 实现 〈 开 发 者 在 编译 时 使 用 
到 的 android. jar 事 实 上 只 是 一 个 空 的 Stub 实 现 ， 更 多 细节 可 以 参考 本 
书 SDK 章 节 ) ; 而 core-1ibart 对 应 的 是 A0SP 工 程 目录 下 的 1ibcore 目 
录 ， 是 基础 能 力 的 集合 。 早 期 Dalvik 版 本 中 对 它 的 命名 
Æ “core. jar”， 所 以 Art 虚 拟 机 在 初始 化 时 如 果 发 现 B00TCLASS 仍 沿用 
了 这 个 文件 名 的 话 ， 会 自动 将 其 替换 为 “core-libart” 【具体 实现 在 
ParsedOptions::Parse#) 。 


Android N 版 本 中 引入 了 0penJDK， 所 以 A0SP/1ibcore 下 面 的 编译 主 
要 分 为 两 部 分 : 


e openjdk_java_files 


即 与 openjdk 相 关 的 文件 ， 有 一 个 名 为 openjdk_java_fi les. mk 的 脚 
本 与 之 对 应 ， 主 要 包括 了 A0SP/ZIibcore/ojluni 目 录 下 的 内 容 。 通 过 
openjdk java files, non openjdk java files 和 icu4j 可 以 编译 出 名 
为 core-al1 的 Java 包 。 


e non_openjdk_java_files 


与 非 openjdk 相 关 的 文件 ， 有 一 个 名 为 non_openjdk_java_files. mk 
的 脚本 与 之 对 应 ， 主 要 包括 了 AO0SP/1ibcore/dex、 
AOSP/1ibcore/1uni、AO0SP/1ibcore/dalvik 几 个 目录 下 的 内 容 。 上 述 的 
core-|libart 就 是 由 non_openjdk_java_files 和 icu4j 相 关 的 一 系列 文件 
编译 而 成 的 。 


另外 ，PRODUCT_B00TCLASSPATH 会 负责 将 PRODUCT_B00T_JARS 中 的 各 
个 jar 文 件 组 成 “/system/framework/[JAR_NAME]. jar” 序 列 ， 并 且 保 
证 各 个 jar 之 间 以 “: ”为 分 隔 符 , 从 而 形成 最 终 的 结果 。 


理解 了 Boot Class Path 的 赋值 过 程 后 ， 我 们 继续 分 析 前 述 的 
Generatelmage 国 数 。 因 为 Boot Class Path 以 冒号 为 分 隔 符 ， 所 以 
Generatelmage 通 过 这 个 关键 词 惑 可 以 把 所 有 路 径 解析 成 vector 对 象 ， 
即 boot_class_path 一 一 如 果 这 个 变量 为 空 的话 ， 说 明 当 前 并 没有 指定 
启动 类 路 径 ， 那 么 会 导致 程序 出 错 返回 。 另 外 ， 假 如 当前 进程 是 
Zygote， 那 么 在 dalvik-cache 下 生成 新 的 Image 之 前 ， 我 们 会 首先 调用 
PruneDexCache 来 清理 掉 一 些 “ 垃 圾 ”。 


接 下 来 该 dex2oat 出 场 了 。 第 一 步 自然 还 是 要 找到 dex2oat 程 序 的 存 
储 路 径 ， 即 GetCompi lerExecutable。 默 认 情 况 下 ，dex2oat 在 设备 中 的 
位 置 是 /system/bin/dex2oat 〈 非 调试 版 本 ) 或 
者 /system/bin/dex20atd (调试 版 本 ) 。 查 找到 的 结果 将 会 被 保存 到 
arg_vector 这 个 变量 中 ， 其 他 需要 被 保存 的 重要 参数 及 它们 的 值 分 别 





十 : 
e “--image= 7 
由 image_filename 指 定 ， 即 前 面 所 述 的 boot. art 的 存储 路 径 。 
e “--dex-file= 


boot class path 中 的 每 个 jar 都 会 通过 --dex-file 单 独 传 递 给 
dex2oat 程 序 。 


e “--oat-file=” 


通过 Get0atLocationFromlmageLocation 从 image 文 件 中 提取 出 0at 
文件 的 路 径 ， 提 取 过 程 简单 来 讲 就 是 把 lImage 路 径 结 尾 的 3 个 字符 改 
为 “oat”。 换 句 话 说 ，“--oat-file” 默 认 情 况 下 得 到 的 结果 值 


是 “/system/framework/boot. oat”。 


这 些 参 数 中 的 “--dex-file=” 是 dex20at 的 “输入 ”参数 ， 其 他 两 
个 则 属于 “输出 ”参数 。 我 们 特别 强调 这 点 ， 是 因为 根据 经 验 来 看 不 少 
开发 人 员 都 容易 在 这 个 问题 上 “ 栽 跟头 ”。 


Generatelmage 国 数 的 最 后 会 调用 Exec 来 执行 dex2oat 程 序 ， 这 个 
数 也 是 我 们 需要 关注 的 : 


/*art/runtime/utils.cc*/ 
bool Exec(std::vector<std::string>& arg_vector, std::string* erro 





const char* program = arg_vector[0].c_str();// 将 arg_vector 转 化 为 : 
std::vector<char*> args; 
for (size_t i = 0; i < arg_vector.size(); ++1) { 

.…/* 转 化 过 程 */ 


Í 
args.push_back(NULL) ; 


//fork 一 个 进程 来 执行 dex20at 程 序 
pid_t pid = fork();// 孵 化 出 一 个 新 进程 
if (pid == 0) {// 子 进程 
setpgid(0，0);// 设 置 group id 
execv(program，&args[0]);// 执 行 dex20at 程 序 
PLOG(ERROR) << "Failed to execv(" << command_line << ")"; 
exit(1); 
} else { 
if (pid == -1) {//#EPERRLAM 
*error_msg = StringPrintf("Failed to execv(%s) because fork 
command_line.c_str(), strerror(er 
return false; 


int status; 
pid_t got_pid = TEMP_FAILURE_RETRY(waitpid(pid, &status, 0)); 
if (got_pid != pid) { 

*error_msg = StringPrintf("Failed after fork for execv(%s) 
"wanted %d, got %d: %s" 
command_line.c_str(), pid, got_pid, 

return false; 


} 
if (!WIFEXITED(status) || WEXITSTATUS(status) != 0) { 
*error_msg = StringPrintf("Failed execv(%s) because non-0 e 
command_line.c_str()); 
return false; 


} 
} 
return true; 


J 
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arg_vector 中 的 所 有 元 素 ， 除 了 将 它们 转化 为 char* 指 针 外 ， 还 需要 保 
存 到 args 这 个 新 的 vector 中 。 


接 下 来 通过 Linux 中 创建 新 进程 的 经 典 方式 一 一 fork 来 及 化 出 
dex20at 的 承载 进程 。 其 中 pid==0 的 情况 属于 新 及 化 出 的 子 进程 ， 在 这 
个 分 支 中 我 们 会 调用 execv 来 加 载 和 运行 目标 程序 〈 即 dex2oat) ， 并 由 
后 者 完成 Image 和 0at 文 件 的 生成 工作 。 


同时 父 进 程 也 会 继续 运行 。 因 为 fork 函 数 是 在 父 进程 中 被 调用 的 ， 
所 以 它 的 返回 值 自然 在 这 一 环境 中 是 可 见 的 。 换 名 话说， 代表 dex2oat 
所 在 进程 的 pid 值 不 会 是 0: 如 果 是 -1 的 话 ， 表 示 fork 函 数 执行 失败 ; 否 
则 pid 就 代表 了 dex2oat 的 进程 id 号 。 那 么 父 进 程 中 应 该 承担 哪些 工作 
Ne? 答案 是 : 等 待 。 具 体 来 说 就 是 调用 waitp id 主动 等 待 dex2oat 完 成 任 





务 ， 再 根据 这 个 程序 的 运行 结果 来 决定 最 终结 果 是 false (AM) 或 者 
true (AKITA) 。 


所 以 总 结 来 说 ，dex2oat 既 可 以 被 用 于 编译 0at， 还 担负 着 生成 
Image 的 责任 。 


21.7 Android 虚 拟 机 中 的 线程 管理 


我 们 知道 ，Android 虚 拟 机 是 支持 多 线程 的 。 那 么 虚拟 机 中 的 线程 
是 如 何 管理 重点 关注 创建 和 挂 起 两 个 核心 流程 ， 的 ， 和 Linux 线 程 又 
有 什么 区 别 和 联系 呢 ? 这 些 我 们 本 小 节 所 要 回答 的 问题 。 


21.7.1 Java 线程 的 创建 过 程 


我们 知道 ，Java 代 码 中 可 以 通过 多 种 方式 来 创建 一 个 线程 ， 比 如 下 
这 种 典型 的 做 法 : 


Thread thread= new Thread(); 


Thread 提 供 了 不 同 的 构造 函数 来 满足 开发 者 的 各 种 场景 需求 ， 不 过 
它们 最 终 都 会 调用 同一 个 Create 函 数 : 


/*libcore/libart/src/main/java/java/lang/Thread. java*/ 
public Thread() { 
create(null, null, null, 0); 


大 家 需要 注意 的 是 ， 此 时 新 的 线程 其 实 还 没有 被 创建 出 来 一 一 这 要 
等 到 Thread. Start () 时 才 生 效 : 


public synchronized void start() { 
checkNotStarted( ); 
hasBeenStarted = true; 
nativeCreate(this, stackSize, daemon); 


其 中 nativeCreate 是 一 个 本 地 层 的 函数 ， 如 下 所 示 : 


/*art/runtime/native/java_lang_Thread.cc*/ 
static void Thread_nativeCreate(JNIEnv* env, jclass, jobject java 
jlong stack_size, jboolean daemon 
Thread: :CreateNativeThread(env, java_thread, stack_size, daemon 


} 
很 明显 ，Java 层 的 Thread 类 最 终 关 联 的 是 native 层 中 的 


Thread. cc: 


/*art/runtime/Thread.cc*/ 

void Thread: :CreateNativeThread(JNIEnv* env, jobject java_peer, s 
CHECK(java_peer != nullptr); 
Thread* self = static_cast<JNIEnvExt*>(env)->self; 
Runtime* runtime = Runtime: :Current(); 


// Atomically start the birth of the thread ensuring the runtim 
bool thread_start_during_shutdown = false; 


MutexLock mu(self, *Locks::runtime_shutdown_lock_)j; 
if (runtime->IsShuttingDownLocked()) { 
thread_start_during_shutdown = true; 
} else { 
runtime->StartThreadBirth()j; 
} 
} 


Thread* child_thread = new Thread(is_daemon) ;// 创 建新 线程 类 





pthread_t new_pthread; 

pthread_attr_t attr; 

CHECK_PTHREAD_CALL(pthread_attr_init, (&attr), "new thread"); 

CHECK_PTHREAD_CALL(pthread_attr_setdetachstate, (&attr, PTHREAD. 

CHECK_PTHREAD_CALL(pthread_attr_setstacksize, (&attr, stack_siz 

int pthread_create_result = pthread_create(&new_pthread, &attr, 
Thread: :CreateCallback, child_thread); 


“2 


StartThreadBirth 和 EndThreadBi rth 需 要 配套 使 用 ， 用 于 表示 当前 
有 新 线程 在 “孵化 ”中 ， 这 点 我 们 在 Runtime: : 1nit 分 析 main 线 程 的 创 
建 时 就 已 经 描述 过 了 。 接 下 来 会 创建 一 个 新 的 线程 类 Thread， 不 过 这 时 
还 未 fork 出 一 个 线程 。 真 正 的 转折 点 出 现在 pthread_create 了 水 数 中 ， 它 
是 由 pthread 提 供 的 标准 的 线程 创建 接口 “这 也 意味 着 ，Java 程 序 中 的 
线程 是 由 操作 系统 线程 来 承载 的 ) 。 声 明 如 下 : 


int pthread_create(pthread_t *tidp,const pthread_attr_t *attr, (v 
void *arg); 


第 1 个 参数 代表 的 是 指向 线程 标志 符 的 指针 ; 第 2 个 参数 是 线程 的 属 
性 值 ; 第 3 个 参数 代表 这 个 新 线程 的 入 口 地 址 ， 在 这 个 场景 中 传 入 的 是 
Thread: :CreateCallback; 最 后 的 arg 变 量 是 新 线程 的 入 口 函 数 所 需要 
的 参数 。 
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下 所 示 : 


/*art/runtime/Thread.cc*/ 

void* Thread: :CreateCallback(void* arg) {/Varg 即 Thread 类 对 象 
Thread* self = reinterpret_cast<Thread*>(arg); 
Runtime* runtime = Runtime: :Current();// 一 个 进程 中 只 存在 唯一 的 Runti 


m~ 


CHECK( !runtime->IsShuttingDownLocked()); 
self->Init(runtime->GetThreadList(), runtime->GetJavaVM()); 
Runtime: :Current()->EndThreadBirth(); 


ScopedObjectAccess soa(self); 


// Copy peer into self, deleting global reference when done. 
CHECK(self->tlsPtr_.jpeer != nullptr); 

self->tlsPtr_.opeer = soa.Decode<mirror::0bject*>(self->tlsPt 
self->GetJniEnv()->DeleteGlobalRef(self->tlsPtr_.jpeer); 
self->tlsPtr_.jpeer = nullptr; 
self->SetThreadName(self->GetThreadName(soa) ->ToModifiedUtf8( 
Dbg: :PostThreadStart(self); 


// Invoke the 'run' method of our java.lang. Thread. 

mirror: :Object* receiver = self->tlsPtr_.opeer; 

jmethodID mid = WellKnownClasses::java_lang_Thread_run; 
InvokeVirtualOriInterfacewithJValues(soa, receiver, mid, nullp 


} 
// Detach and delete self. 
Runtime: :Current()->GetThreadList()->Unregister (self) ;//2¢#E4E fiz) 


return nullptr; 


执行 到 上 述 这 个 子 数 时 ， 我 们 就 已 经 “摆脱 ”了 原先 的 旧 线 程 ， 进 


入 新 的 “征程 ”了 。 那 么 刚 创 建 的 线程 需要 完成 哪些 核心 工作 呢 ? 


(1) 毋庸 置疑 ， 它 首先 需要 被 纳入 虚拟 机 的 统一 管理 中 ， 完 成 这 


MESA) self Init. 


(2) 为 下 面 第 3 点 中 的 函数 调用 准备 好 所 需 参 数 ， 更 确切 地 说 就 是 


指 receiver 和 mid。 其 中 mid 代 表 了 某 个 特定 Java 函 数 的 唯一 1D 号 。 在 我 
们 这 个 场景 中 ， 它 被 赋予 的 值 是 Wel1KnownClasses : 


java_lang Thread_run (WellknownClasses 如 其 名 称 所 示 ， 代 表 了 一 些 
常用 的 基础 类 ， 以 及 基础 类 中 包含 的 成 员 了 水 数 、 变 量 的 集合 ， 壁 如 
java. lang. Thread, java. lang. ClassLoader., 
dalvik. system. VMRuntime 等 。 它 们 都 在 Wel1_known_classes 中 以 
static 变 量 的 形式 存在 ) 。WellknownClasses 在 完成 自身 初始 化 的 同 
时 ， 也 会 为 其 负责 的 所 有 常用 类 逐一 做 初始 化 工作 。 以 
java_lang_Thread_run 这 个 常用 类 为 例 ， 它 的 初始 化 过 程 如 下 所 示 : 
/*art/runtime/well_known_classes.cc*/ 


void WellKnownClasses::Init(JNIEnv* env) {.. 
java_lang_Thread = CacheClass(env, "java/lang/Thread"); 








java_lang_Thread_run = CacheMethod(env, java_lang_Thread, false 


在 分 析 Cache 的 实现 之 前 ， 我 们 先 来 思考 一 下 ，Wel1KnownClasses 
的 Init 了 水 数 应 该 由 谁 来 调用 呢 ? 我 们 前 面 已 经 提 过 ，JNI1Env 是 线程 相关 
的 ， 也 就 是 说 每 个 线程 都 有 自己 的 JN1 环 境 。 换 名 话说， 虚拟 机 中 有 哪 
个 线程 需要 负责 加 载 java. lang. Thread 这 样 的 常用 类 呢 ? 


没 错 ， 是 主线 程 。 具 体 的 调用 流程 是 Runtime: :Start - 
>Runtime: :InitNativeMethods-> WellKnown Classes::1Init， 有 兴趣 
的 读者 可 以 自行 分 析 源 码 了 解 详情 。 


接 下 来 我 们 继续 分 析 CacheC1ass 的 实现 : 


/*art/runtime/well_known_classes.cc*/ 
static jclass CacheClass(JNIEnv* env, const char* jni_class_name) 
ScopedLocalRef<jclass> c(env, env->FindClass(jni_class_name) ); 
if (c.get() == nullptr) { 
LOG(FATAL) << "Couldn't find class: " << jni_class_name; 


return reinterpret_cast<jclass>(env->NewGlobalRef(c.get())); 


} 


不 难 发 现 ， 查 找 Class 的 重任 落 在 env->FindClass 这 个 函数 上 面 。 
其 中 env 代 表 的 是 一 个 JN1 运 行 环境 ， 它 是 线程 相关 的 。 这 个 场景 中 的 
env 来 源 于 se1f->GetJniEnv () ， 而 se1f 是 Runtime 对 象 通 过 
Thread: :Current () 获取 的 ， 也 就 是 Runtime 自 身 所 在 的 线程 。 
GetJniEnv 得 到 的 是 一 个 继承 自 JNIEnv ( 它 是 对 _JNIEnv 的 typedef) 的 
JNIEnvExt, CAV AK sack AVF inClassHAVZ MOT: 


/*art/libnativehelper/jni.h*/ 

struct _JNIEnv { 
/* do not rename this; it does not seem to be entirely opaque 
const struct JNINativeInterface* functions; 


jclass FindClass(const char* name) 
{ return functions->FindClass(this, name); } 


functions 会 在 JNIEnvExt 构 造 时 被 指定 为 一 个 全 局 的 函数 列表 ， 如 
下 所 示 : 


/*art/runtime/jni_env_ext.cc*/ 
JNIEnvExt: : JNIEnvExt(Thread* self_in, JavaVMExt* vm_in)..{ 
functions = unchecked_functions = GetJniNativelInterface(); 


GetUniNativelnterface 返回 的 是 一 个 全 局 变量 
gJniNativelnterface， 这 个 列表 中 指向 的 是 jni_internal 文 件 中 的 函 
数 ， 其 中 FindClass 的 最 终 实现 如 下 : 


/*art/runtime/jni_internal.cc*/ 
static jclass FindClass(JNIEnv* env, const char* name) { 
CHECK_NON_NULL_ARGUMENT (name) ; 
Runtime* runtime = Runtime::Current(); 
ClassLinker* class_linker = runtime->GetClassLinker(); 
std::string descriptor (NormalizeJniClassDescriptor(name) ); 
ScopedObjectAccess soa(env); 
mirror::Class* c = nullptr; 
if (runtime->IsStarted()) { 
StackHandleScope<i> hs(soa.Self()); 
Handle<mirror::ClassLoader> class_loader(hs.NewHandle(GetCl 
c = class_linker->FindClass(soa.Self(), descriptor.c_str(), 





} else { 

c = class_linker->FindSystemClass(soa.Self(), descriptor.c_ 
} 
return soa.AddLocalReference<jclass>(c); 
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(3) 执行 本 线程 所 承载 的 程序 代码 。 璧 如 开发 者 在 Android 应 用 程 
序 中 通常 会 局 动 一 个 新 的 线程 来 从 远 病 服 务 器 下 载 文件 ; 或 者 局 动 新 线 


程 执 行 一 些 耗 时 的 运算 操作 等 。 一 个 典型 的 Java 线 程 用 法 是 开发 人 员 通 
过 继承 Runnab le 来 提供 新 线程 所 需 完 成 的 功能 。 开 发 者 自 定义 的 
Runnable 对 象 会 将 被 保存 在 Thread. target 变 量 中 ， 而 后 者 又 会 在 
Thread: :run (0 函数 中 被 调用 ， 如 下 所 示 : 


/*libcore/libart/src/main/java/java/lang/Thread.java*/ 
public void run() { 
if (target != null) { 
target.run(); 
} 


J 


这 样 一 来 我 们 就 不 难 理解 Thread: :CreateCal lback 所 要 承担 的 主要 
任务 了 : 它 需 要 在 Native 层 调用 并 执行 Java 层 中 的 run( 函数 。 所 以 问 
题 就 转化 为 CreateCal lback 怎 么 才 可 以 找到 run () 所 对 应 的 Java 代 码 ， 
然后 运行 它 呢 ? 


大 家 应 该 猜 到 了 ， 完 成 上 述 工 作 的 实际 执行 者 是 
InvokeVirtualOrlnterfaceWithJValues: 


/*art/runtime/reflection.cc*/ 


JValue InvokeVirtualOriInterfacewithJValues(const ScopedObjectAcce 
soa, mirror::Object* receiver, jmethodID mid, jvalue* args 


mirror: :ArtMethod* method = FindVirtualMethod(receiver, soa.Dec 
/* 查 找到 正确 的 ArtMethod*/ 














uint32_t shorty_len = 0; 

const char* shorty = method->GetShorty(&shorty_len); 

JValue result; 

ArgArray arg_array(shorty, shorty_len); 
arg_array.BuildArgArrayFromJValues(soa, receiver, args); 
InvokewWithArgArray(soa, method, &arg_array, &result, shorty);/* 
return result; 


Android 虚 拟 机 提供 了 很 多 函数 来 帮助 程序 从 Nat ive 层 发 起 并 调用 
ZijJavat žit, (8 |nvokeWithArgArray, InvokeWithJValues=. Mek 
数 名 称 lnvokeVirtual0rlnterfaceWithJValues 可 以 看 出 ， 它 会 试图 查 
找 并 执行 一 个 虚 函 数 或 者 接口 函数 。 输 入 人 参数 中 的 mid 代 表 了 辑 数 的 唯 
—IDS; jvalue 是 这 个 函数 所 需 的 参数 ; 另 一 个 重要 的 参数 变量 
receiver 则 是 mid 吨 数 所 归属 的 类 。 





查找 过 程 由 FindVirtualMethod 完 成 : 


/*art/runtime/reflection.cc*/ 
static ArtMethod* FindVirtualMethod(mirror::Object* receiver, Art 
SHARED_LOCKS_REQUIRED(Locks::mutator_lock_) { 
return receiver ->GetClass()->FindVirtualMethodForVirtualOriInter 


简单 来 讲 ，receiver->GetClass 得 到 的 是 一 个 Class 类 的 描述 ， 借 
此 才能 得 到 它 所 包含 的 Vi rtual Method 或 者 Interface; ArtMethod 类 是 
虚拟 机 内 部 对 函数 的 描述 结构 。 不 论 函 数 最 终 是 通过 Java 解 释 器 来 执 
行 ， 还 还 是 直接 使 用 它 所 对 应 的 O0AT 机 器 码 来 完成 ， 都 由 ArtMethod 来 决 
Æo 


对 于 lnvokeWithArgArray 的 具体 实现 过 程 ， 我 们 在 后 续 小 节 还 会 有 
详细 分 析 。 


21.7.2 线程 的 挂 起 过 程 


虚拟 机 中 的 线程 在 很 多 场景 下 都 需要 被 挂 起 ， 例 如 当 垃 圾 回收 器 工 
“ERY GES: 并 不 是 所 有 GC 情况 下 都 需要 线程 挂 起 ) 、 程 序 正在 等 待 调 
试 器 的 连接 等 。 所 以 学 习 虚 拟 机 线程 管理 的 一 个 必要 环节 ， 是 了 解 线程 
的 挂 起 过 程 。 本 小 节 我 们 将 以 ThreadLi st : :SuspendAl 1 为 线索 来 探寻 
Art 虚 拟 机 是 如 何 处 理 线 程 挂 起 操作 的 ， 以 及 大 家 在 开发 过 程 中 又 有 了 哪 
些 需要 特别 注意 的 地 方 : 


/*art/runtime/thread_list.cc*/ 
void ThreadList::SuspendAll(const char* cause, bool long suspend) 
Thread* self = Thread::Current(); 


ScopedTrace trace("Suspending mutator threads"); 
const uint64_t start_time = NanoTime(); 


SuspendAllInternal(self, self); 
#1if HAVE_TIMED_RWLOCK 
while (true) { 
if (Locks: :mutator_lock_->ExclusiveLockwWithTimeout (self, 
kThreadSuspendTimeoutMs, 0) ) 
break; 
} else if (!long_suspend_) { 


UnsafeLogFatalForThreadSuspendAllTimeout( ); 


} 
} 
#else 
Locks: :mutator_lock_->ExclusiveLock(self); 
#endif 
long_suspend_ = long_suspend; 


const uint64_t end_time = NanoTime(); 

const uint64_t suspend_time = end_time - start_time; 

suspend_all_historam_.AdjustAndAddValue(suspend_time) ; 

if (Suspend time > kLongThreadSuspendthreshold) { 
LOG(WARNING) << "Suspending all threads took: " << PrettyDu 


} 


ThreadList 是 当前 虚拟 机 中 管理 的 线程 的 集合 体 ， 
SuspendAlllnternal 的 任务 就 是 通知 它们 全 部 进入 挂 起 状态 。 简 单 来 
讲 ， 它 采取 的 作法 是 通过 给 各 个 线程 置 位 krSuspendRequest 来 请 求 后 者 
进入 Suspend， 并 将 该 线程 对 应 的 tlsPtr_. suspend_trigger 置 为 无 效 的 
nullptr。 这 样 一 来 当 线 程 执 行 到 它 的 Check Point 访 问 上 述 变量 时 ， 就 
会 引发 $1GSEGV 的 段 错误 ， 从 而 通过 预先 注册 的 fault hander 〈 人 参见 前 
面 小 节 的 讲解 ) 逐步 执行 到 Suspension check 的 处 理 函 数 ， 即 
art quick implicit suspend 中 。 


函数 art_quick_implicit_suspend 是 一 个 汇编 水 数 ， 主 要 目的 是 跳 
转 到 artTestSuspendFromCode 中 ， 后 者 会 在 将 过 一 系列 调用 后 最 终 进 入 


TransitionFromRunnab |eToSuspended. 


TransitionFromRunnableToSuspended 国 数 最 关键 的 两 步 操 作 ， 其 
一 是 TransitionTo Suspended AndRunCheckpoints， 负 责 把 当前 线程 状 
态 切 换 为 挂 起 状态 ; 其 二 就 是 Locks: :mutator_lock-> 
TransitionFromRunnableToSuspended， 主 要 目的 在 于 释放 当前 线程 持 
有 的 mutator_lock 的 Shared Lock。 这 些 知 识 点 我 们 在 讲解 信号 机 制 时 
还 有 详细 摘 述 ， 这 里 只 有 了 解 大 致 处 理 过 程 就 可 以 了 。 


那么 系统 如 何 判 断 是 不 是 所 有 线程 都 已 经 挂 起 成 功 了 了 呢 ? 这 是 借助 
于 Locks: :mutator lock 实现 的 。 因 为 Darwin 系 统 不 支持 带 超时 功能 的 





lock， 所 以 需要 通过 HAVE_TIMED_RWLOCK 宏 来 区 分 对 待 〈 除 非 当 前 系统 
是 Apple， 否 则 这 个 安 的 值 为 1) . ThreadList: :SuspendAl | 4AYwhi le 
循环 的 执行 逻辑 如 下 : 调用 ExclusiveLockWithTimeout 来 获取 
Exclusive Lock， 并 设置 超时 时 间 (目前 为 
kThreadSuspendTimeoutMs=30 秒 ) 。 如 果 线 程 无 法 在 指定 时 间 内 进入 挂 
起 状态 ， 那 么 ExclusiveLockWithTimeout 返 回 false， 同 时 如 果 
long_suspend 不 为 true， 那 么 就 会 引发 致命 错误 ， 并 调用 
UnsafeLogFatalForThreadSuspendAl1Timeout 来 打印 出 详细 的 错误 信 
息 。 例 如 下 面 是 从 Android Bug 反 馈 系 统 上 摘录 的 一 个 真实 范例 : 


A/art: art/runtime/thread_list.cc:173] Thread suspend timeout 
A/art: art/runtime/thread_list.cc:173] mutator lock level=46 owner=18446744073709551615 state=1 num pending writers=0 


A/art: art/runtime/thread_list.cc:173] DALVIK THREADS (20): 

A/art: art/runtime/thread_list.cc:173] “main” prio=5 tid=1 Native 

A/art: art/runtime/thread_list. cc:173] group= main” sCount=1 dsCount=0 obj=0x731a5000 self=0xb3c25400 

A/art: art/runtime/thread_list. cc:173] sysTid=1966 nice=0 cgrp=default sched=0/0 handle=0xb7723ea0 

A/art: art/runtime/thread_list.cc:173] state=S schedstat=( 0 0 0 ) utm=12 stm=21 core=0 HZ=100 

A/art: art/runtime/thread_list.cc:173] stack=0xbf715000-Oxb£717000 stackSize=8MB 

A/art: art/runtime/thread_list. cc:173] held mutexes= 

A/art: art/runtime/thread_list.cc:173] kernel: futex_wait_queue_me+0xc5/Oxfe 

A/art: art/runtime/thread_list.cc:173] kernel: futex_wait+0xb9/Oxica 

A/art: art/runtime/thread_list.cc:173] kernel: do_futex+0x8c/0x7a3 

A/art: art/runtime/thread_list.cc:173] kernel: sys_futex+0x88/0xdb 

A/art: art/runtime/thread_list.cc:173] kernel: syscall_call+0x7/Oxb 

A/art: art/runtime/thread_list.cc:173] native: #00 pc 000132d0 /system/lib/libc. so (syscal1+82) 

A/art: art/runtime/thread_list.cc:173] native: #01 pc 007fbc77 [stack] (22?) 

A/art: art/runtime/thread_list.cc:173] at android. database. sqlite. SQLiteConnection. nativeExecute (Native method) 
A/art: art/runtime/thread_list.cc:173] at android. database. sqlite. SQLiteConnection. execute (SQLiteConnection. java:555) 
A/art: art/runtime/thread_list.cc:173] at 
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“Thread suspend timeout” 明 确 指出 这 是 因为 挂 起 线程 失败 导致 
的 问题 。 那 么 线程 挂 起 成 功 与 否 和 Exclus iveLockWithTimeout 的 执行 过 
程 有 什么 必然 的 联系 呢 ? 


我 们 知道 ，Locks: :mutator_lock_ 是 一 个 MutatorMutex 指 针 ， 如 
下 : 


mutator_lock_ = new MutatorMutex("mutator lock", current_lock_lev 


而 且 Locks: :mutator_lock 又 继承 自 ReaderWr iterMutex， 这 就 是 
我 们 在 本 书 操作 系统 同步 互 斥 章节 曾 专 门 介绍 过 的 读 写 锁 。 它 在 各 个 状 


态 下 所 允许 的 操作 及 结果 如 表 21-10 所 示 。 


表 21-10 ”操作 及 结束 


Es 
Shared(n) on error 


因为 Art 中 的 很 多 函数 都 需要 mutator lock 的 “ 读 取 锁 ”， 这 一 点 我 
们 通过 搜索 关键 词 “mutator_lock_ ”就 可 以 确认 了 : 





Class.h (art\runtime\mirror): bool IsArrayClass () SHARED REQUIRES (Locks: :mutator lock ); 

Class.h (art\runtime\mirror): bool IsClassClass() SHARED REQUIRES (Locks: :mutator lock ); 

Class.h (art\runtime\mirror): bool IsThrowableClass () SHARED REQUIRES (Locks: :mutator lock ); 
Class.h (art\runtime\mirror): bool IsReferenceClass() const SHARED REQUIRES (Locks: :mutator lock ); 


当 调 用 上 述 这 类 函数 时 ， 一 个 必要 的 前 提 条 件 是 成 功 获得 
mutator_lock 的 Shared Lock， 否 则 编译 器 会 报错 。 另 外 获取 到 
Exclusive Lock 的 前 提 则 是 所 有 的 Shared Lock 都 得 到 释放 〈 即 Free 状 
AS) ， 否 则 就 会 进入 Block 状 态 。 换 句 话 说， 如 果 所 有 线程 都 可 以 在 预 
定时 间 内 进入 挂 起 状态 〈 各 个 线程 申请 的 Shared Lock 会 被 同步 释 
放 ) ， 那 么 ExclusiveLockWithTimeout 就 能 够 在 Timeout 之 前 成 功 返 回 
true; 否则 30 秒 超时 后 任务 未 完成 ， 就 会 引发 fatal error. 


通过 mutator_lock_ 的 方式 可 以 很 好 地 达到 对 虚拟 机 线程 的 挂 起 控 
制 ， 这 其 中 的 设计 实现 还 是 蛮 巧 妙 的 ， 值 得 大 家 借鉴 学 习 。 


21.8 Art 虚 拟 机 中 的 代码 执行 方式 综述 
伴随 着 A0T、J1T 等 技术 的 出 现 ，Java 虚 拟 机 的 执行 方式 已 经 不 单纯 
是 “解释 器 ”这 一 各 了。 以 Art 虚 拟 机 为 例 ， 大 家 可 以 思考 一 下 它 所 面 
对 的 代码 环境 是 什么 样 的 ? 
o (1) 使 用 Java 语 言 编写 的 代码 
此 时 有 如 下 两 种 情况 。 
Case1: Dex PAZ Interpreter PHF. 
需要 注意 的 是 ，Java 代 码 在 Interpreter 中 并 不 一 定 就 是 解释 执 
行 ， 它 还 可 能 是 JIT 执 行 。 
Case2: Dex 字 节 码 经 过 dex2oat 转 化 后 的 本 地 机 器 码 的 执行 。 
e (2) 使 用 C/C++ 等 语言 编写 的 代码 


Case3: 使 用 CZCc++ 编 写 的 函数 ， 通 常会 被 编译 成 . so 文件 ， 并 利用 
JN1 技 术 人 参与 到 Android 应 用 程序 的 运行 中 。JN1 本 地 函数 和 上 述 的 Case2 
都 是 对 本 地 机 器 码 的 执行 ， 所 以 它们 存在 相似 之 处 


另外， 以 上 3 个 Case 并 不 是 完全 孤立 的 一 一 一 换 句 话说 ， 它 们 存在 
互相 调用 的 情况 。 这 无 疑 进一步 加 剧 了 Art 的 处 理 难 度 ， 大 致 如 图 21-55 
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e (1) 字 节 码 在 Interptetet 中 的 执行 过 程 


当 ArtMethod 人 确认 需要 通过 1nterpreter 来 执行 本 函数 时 ， 将 交 由 后 
者 来 解析 执行 字 节 码 〈 也 可 能 是 JIT) 。 在 此 过 程 中 如 果 遇 到 invoke-XX 





MEHI, Interpreter SiHWDolnvokery ži 
Cinterpreter_common.h) 来 查找 和 确定 目标 对 象 ， 并 跳 转 过 去 。 每 一 
个 目标 对 象 都 对 应 一 个 ArtMethod， 查 找 的 工作 则 由 类 加 载 系统 完成 。 
Dolnvoke 与 类 加 载 系统 之 间 的 桥梁 是 FindWethodFromCode， 核 心 实现 如 
下 : 


/*art/runtime/entrypoints/entrypoint_utils-inl.h*/ 
template<InvokeType type, bool access_check> 
inline ArtMethod* FindMethodFromCode(uint32_t method_idx, mirror: 
this_object,ArtMethod* referrer, 
ClassLinker* const class_linker = Runtime: :Current()->GetClassL 
ArtMethod* resolved_method = class_linker ->GetResolvedMethod (me 
if (resolved_method == nullptr) { 
StackHandleScope<i> hs(self); 
mirror::Object* null_this = nullptr; 
HandleWrapper<mirror: :Object> h_this( 
hs.NewHandlewrapper(type == kStatic ? &null_this : this_o 
constexpr ClassLinker::ResolveMode resolve_mode = 
access_check ? ClassLinker: :kForceICCECheck 
: ClassLinker: :KNoICCECheckForCache; 
resolved_method = class_linker->ResolveMethod<resolve_mode>(sel 
method_idx, re 
} 


上 述 代 码 段 的 逻辑 是 : 首先 通过 ClassLinker 的 GetResolvedMethod 
来 确定 系统 之 前 是 否 解析 过 这 个 函数 ， 如 果 答 案 是 肯定 的 ， 就 没有 必要 
重复 解析 了 ; 否则 我 们 需要 利用 ResolveMethod 来 查找 和 获取 目标 范 
数 。ResolveMethod 的 工作 主要 分 为 3 个 环节 ， 即 定位 Dex、 定 位 Class， 
最 后 才 是 定位 Method。 


一 旦 成 功 获取 到 目标 函数 对 应 的 ArtMethod 后 ，Dolnvoke 紧 接着 利 
用 模板 函数 DoCal 1 来 执行 ArtMethod。DoCal1 的 实现 在 
interpreter_common. cc 中 ， 它 的 职责 是 准备 好 各 种 arguments， 然 后 进 
一 步调 用 DoCal1Common。 后 者 中 真正 去 执行 的 ArtMethod 的 核心 语句 摘 
录 如 下 : 


if (LIKELY(Runtime: :Current()->IsStarted())) {//Runtime 已 经 启动 完成 
ArtMethod* target = new_shadow_frame->GetMethod(); 
if (ClassLinker: :ShouldUseInterpreterEntrypoint ( 
target, target->GetEntryPointFromQuickCompiledCode())) { 
ArtInterpreterToInterpreterBridge(self, code_item, new_shad 


} else { 
ArtInterpreterToCompiledCodeBridge(self, code_item, new_sha 


} else { 
UnstartedRuntime: :Invoke(self, code_item, new_shadow_frame, r 


正常 情况 下 Runt ime 都 已 经 启动 完成 ， 所 以 我 们 只 要 根据 
ShouldUselnterpreterEntrypoint 的 返回 结果 就 能 判断 出 下 一 步 的 动作 
如 果 此 消 数 的 返回 值 表 明 执 行 该 ArtMethod 对 应 的 函数 需要 使 用 
Interpreter， 那 么 接 下 来 的 处 理 就 相当 于 从 interpreter- 
>interpreter (使 用 Artlnterpreter TolnterpreterBridge) ; 反之 就 
说 明 需 要 进入 本 地 代码 执行 ， 因 而 是 interpreter->compiled code (使 
用 ArtlnterpreterToComp iledCodeBr idge) ， 如 图 21-56 所 示 。 


ArtMethod 
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全 图 21-56 ArtMethod'? 49EntryPoint 


我 们 知道 ，ArtMethod 是 对 Java 函 数 〈 包 括 JN1I 函 数 和 非 JNI 函 数 ) 
的 运行 时 抽象 。 如 果 是 JNI1 遂 数 ， 那 么 就 应 该 获取 到 它 所 对 应 的 so 中 的 
本 地 代码 来 执行 ， 如 果 是 非 JN1 函 数 ， 那 么 会 有 两 种 情况 : 即 通过 


Interpreter 来 解释 执行 它 的 字 节 码 ; 或 者 是 直接 执行 dex2oat 后 生成 的 
Native Code。 具 体 选 择 哪 种 方式 会 受到 多 ee 壁 如 当前 是 
否 处 于 调试 状态 (调试 模式 下 需要 解释 执行 冰 数 是 否 有 对 应 的 0at 
Code (并 非 所 有 Java 号 ; oped rte Gade) 等 。 值 得 一 提 的 
是 ，ArtMethod 中 的 几 个 entry_point 变 量 在 Android 历 代 版 本 中 的 改动 
都 较 大 ， 其 中 entry_point_from_interpreter_ 在 Android N 版 本 中 已 经 
被 移 除 并 采用 其 他 方式 替代 ; entry_point_from_jni _ 成员 变 量 如 果 改 
名 为 “entry_point_to_jni_ ”或 许 更 能 表达 它 的 设计 初 袁 。 这 些 请 
家 在 阅读 源码 时 特别 注意 。 


那么 ArtMethod 中 的 这 些 Entry Point 是 在 什么 时 候 被 赋值 的 呢 ? & 
是 LinkCode: 


/*art/runtime/class_linker.cc*/ 
void ClassLinker::LinkCode(ArtMethod* method, const OatFile: :0atC 
uint32_t class_def_method_index) { 
Runtime* const runtime = Runtime::Current(); 
if (runtime->IsAotCompiler()) {// 当 前 虚拟 机 进程 是 dex20at， 直 接 返 回 
// The following code only applies to a non-compiler runtime. 
return; 


} 
// Method shouldn't have already been linked. 
DCHECK(method->GetEntryPointFromQuickCompiledCode() == nullptr) 
if (oat_class != nullptr) { 
const OatFile::OatMethod oat_method = 
oat_class- >GetOatMethod(class_ def_method_index 
oat_method.LinkMethod(method) ;// 为 ArtMethod 指 定 Native Code 





} 
const void* quick_code 
bool enter_interpreter 


method->GetEntryPointFromQuickCompiled 
ShouldUseInterpreterEntrypoint (method, 
// 是 否 需要 使 用 解释 器 来 执行 这 个 函数 


if (!method->IsInvokable()) {/V 函 数 允 许 被 执行 吗 ? 璧 如 抽象 函数 
EnsureThrowsInvocationError (method); 
return; 





} 


if (method->IsStatic() && !method->IsConstructor()) {// 静 态 非 构造 
method->SetEntryPointFromQuickCompiledCode(GetQuickResolution. 
} else if (quick code == nullptr && method->IsNative()) {// 本 地 E 
method->SetEntryPointFromQuickCompiledCode(GetQuickGenericJni 
} else if (enter_interpreter) {// 需 要 解释 执行 的 情况 
// Set entry point from compiled code if there's no code or i 
method->SetEntryPointFromQuickCompiledCode(GetQuickToInterpre 























} 


if (method->IsNative()) { 
// Unregistering restores the dlsym lookup stub. 
method->UnregisterNative(); 


if (enter_interpreter || quick_code == nullptr) { 
const void* entry_point = method->GetEntryPointFromQuickCom 
DCHECK(IsQuickGenericJniStub(entry_point) | | 
IsQuickResolutionStub(entry_po 


LinkCode 中 首先 需要 注意 的 就 是 
oat method. Huot (method) 这 个 语句 ， 因 为 ArtMethod 所 对 应 的 
机 器 码 就 是 通过 这 个 函数 获取 的 。 我 们 来 看 一 下 它 的 代码 实现 : 


/*art/runtime/oat_file.cc*/ 

void OatFile: :OatMethod: :LinkMethod(ArtMethod* method) const { 
CHECK(method != nullptr); 
method->SetEntryPointFromQuickCompiledCode(GetQuickCode()); 


} 


0atMethod 中 包含 的 两 个 变量 BE; = = 它们 
的 取 和 结果 ， 就 是 本 函数 对 应 的 机 器 码 在 内 存 中 的 加 载 地 址 《后 者 是 基 
于 前 者 的 偏 移 量 ) -~ GetQuickCode () 就 是 根据 它们 来 获取 到 QuickCode 
的 ， 然后 再 通过 ArtMethod 自 身 的 
SetEntryPointFromQuickComp iledCode 设 置 其 为 Compiled Native Code 
的 入 口 点 。 


ShouldUselnterpreterEntrypoint 在 多 种 情况 下 会 返回 true: 
Quick Code 不 存在 ; te Rae (并 且 当 前 不 
能 是 Native 和 Proxy 函 数 ) 等 。 


接 下 来 LinkCode 需 要 根据 调用 者 所 处 的 不 同 环 境 〈 虚 拟 机 解释 器 环 
本 地 代码 执行 环境 等 ) 来 做 差异 处 理 ， 为 EntryPoi nt 赋 子 正确 的 





我 们 回 到 ClassLinker: :LinkCode 函数 中 继续 分 析 。 剩 下 还 有 下 列 
几 种 可 能 性 需要 考虑 : 


。 静态 非 构造 函数 


静态 非 构造 类 型 的 函数 比较 特殊 ， 需 要 另行 处 理 。 因 为 静态 函数 是 
不 需要 实例 化 对 象 的 ， 所 以 可 能 会 出 现 它 的 调用 时 间 早 于 类 初始 化 时 间 
的 情况 。 为 了 防止 错误 的 发 生 ，Art 虚 拟 机 设计 了 名 为 “Quick 
Resolution Trampoline” 的 Stub。 它 的 工作 原理 简单 来 讲 就 是 延迟 确 
认 静 态 溺 数 的 Entry Points， 具 体 是 在 ClassLinker: :lnitializeClass 
中 ， 即 Class 初 始 化 时 通过 FixupStaticTrampolines 来 重新 调整 静态 号 
数 的 入 口 地 址 。 而 此 时 SetEntryPointFromQuickCompi1edCode 中 暂时 设 
置 的 是 GetQuickResolutionStub。 


e Native Á 3 # E Quick Code 不 存在 





此 时 设置 的 入 口 是 GetQuickGener icJUniStub. 
。 需 要 解释 执行 的 情况 

此 时 设置 的 入 口 是 GetQuickTolnterpreterBridge。 
。 其 他 


除 此 之 外 就 可 以 保持 LinkMethod 中 的 设置 ， 即 函数 的 Compi led 
Native Code. 


顺便 提 一 下 ， 虚 拟 机 中 有 一 些 约定 俗 成 的 关于 “ 跳 转 ”的 术语 ， 例 
如 Stub、Trampoline、Ricochet 等 。Stub 是 一 种 “ 桩 ”， 顾 名 思 义 它们 
并 非 真 正 的 实现 体 ， 而 是 为 了 某 些 “意图 ”而 设计 的 中 间 过 程 。 
Trampol ine 属 于 Stub 的 一 种 ， 而 且 有 趣 的 是 这 个 词 的 原意 是 “蹦床 、 弹 
床 ”， 这 和 某 些 场合 下 需要 从 Cal ler 途 经 Stub， 再 “ 跳 ” 到 Cal lee 的 设 
计 理 念 是 相当 吻合 的 。 


LinkCode 函 数 的 最 后 ， 还 有 一 段 代码 是 针对 JN1 的 处 理 ， 其 中 的 核 
心 是 调用 UnregisterNative。 这 个 函数 会 把 Jni Entry Point 设 置 为 
GetJniDlsymLookupStub， 即 通过 D1sym 这 种 标准 的 方式 来 完成 查找 动 
TFs 


接 下 来 我 们 选取 GetQui ckTolnterpreterBr idge 来 做 详细 分 析 ， 以 
加 深 大 家 的 理解 。 它 的 返回 结果 是 一 个 名 


为 “art quick to interpreter _ bridge” 的 汇编 国 数 一 一 后 者 的 职责 
是 帮助 处 于 Qui ck Code 环 境 中 的 Cal1er 涵 数 能 够 正确 调用 需要 解释 器 执 
行 的 Cal lee 函 数 ， 如 下 所 示 : 


.extern artQuickToInterpreterBridge 

ENTRY art_quick_to_interpreter_bridge 
SETUP_REFS_AND_ARGS_CALLEE_SAVE_FRAME r1, r2 
mov r1, r9 @ pass Thread: :Current 
mov r2, sp @ pass SP 
b1x artQuickToInterpreterBridge @ (Method* method, Thre 
ldr r2, [r9, #THREAD_EXCEPTION_OFFSET] @ load Thread::Cur 
// Tear down the callee-save frame. Skip arg registers. 
add sp, #(FRAME_ SIZE_ REFS_AND_ARGS_CALLEE_SAVE - FRAME_SIZ 
.cfi_adjust_cfa_offset -(FRAME_SIZE_REFS_AND_ARGS_CALLEE_SAVE 
RESTORE_REFS_ONLY_CALLEE_SAVE_FRAME 














cbnz r2, 1f @ success if no exception is pend 
vmov do, rọ, ri @ store into fpr, for when it's a 
bx lr @ return on success 


T: 
DELIVER_PENDING_EXCEPTION 
END art_quick_to_interpreter_bridge 


我 们 在 分 析 art quick to interpreter bridge 之 前 首先 需要 清楚 
它 的 调用 者 都 有 了 哪些， 这 样 有 助 于 理 顺 上 下 文 环 境 。 从 前 面 LinkCcode 中 
的 解析 ， 我 们 知道 art_quick_to_interpreter_bridge 是 作为 一 个 
bridge 被 设置 成 Quick EntryPoint 的 。 这 个 入 口 真 正派 上 用 场 的 一 个 地 
方 ， 在 于 ArtMethod 的 inovke 子 数 。 具 体 的 函数 调用 流程 是 : 
ArtMethod: : invoke- 
>art_quick_invoke_stub/art_quick_invoke_static_stub-—> 
quick_invoke_reg setup—> art_quick_invoke_stub_internal——zsg 
后 的 art_quick_invoke_stub_internal 属 于 汇编 函数， 在 它 内 部 会 进 一 
步调 用 LinkCode 中 设置 的 入 口 ， 相 应 语句 如 下 : 


ldr ip, [re, #Art_METHOD_QUICK_CODE_OFFSET_32] 
根据 1dr 的 语法 规则 ， 在 上 述 语句 之 前 的 寄存 器 配置 操作 就 直接 、 
定 了 art_quick to _interpreter _bridge 这 个 国 数 的 可 用 参数 了 ， 整 理 
如 下 : 
rO=method pointer 


r1-r3=core registers 


r9 = (managed) thread pointer 


不 过 在 最 终 调用 artQuickTolnterpreterBridge 之 前 ， 各 寄存 器 值 
其 实 又 做 了 一 些 调整 ， 即 : 


rO=method pointer 

r1=Thread: :Current 

r3=SP 

X Alar tQuickTolnterpreterBr idge 这 个 C 国 数 的 原型 是 匹配 的 ， 


uint64 t artQuickTolnterpreterBr idge (ArtMethod* method, 
Thread* self, ArtMethod** sp) 


其 中 method 代 表 被 调用 的 函数 (cal lee) ，self 表 示 当 前 线程 ，sp 是 
一 个 指向 代表 caller 的 ArtMethod 指 针 变 量 的 指针 〈 因 为 sp 实际 上 是 一 
个 栈 ， 它 的 栈 顶 位 置 保存 的 是 ArtMethod*) 。 


疯 数 artQuickTolnterpreterBridge 的 关键 点 有 两 个 : 其 一 是 为 
Interpreter 的 运行 提供 栈 帧 ， 即 ShadowFrame。ShadowFrame 有 点 类 似 
于 Java 标 准 虚拟 机 中 的 Stack Frame, 它 用 于 存储 方法 中 的 本 地 变量 表 、 
操作 栈 、 方 法 出 口 等 信息 。 当 然 ，Android 虚 拟 机 是 基于 寄存 器 来 实现 
的 ， 而 标准 Java 虚 拟 机 则 基于 栈 来 实现 ， 所 以 它们 两 者 在 栈 帧 的 具体 结 
构 上 有 一 定 差 别 。 


ShadowFrame 是 由 artQuickTolnterpreterBridge 通 过 如 下 语句 创建 





的 : 


ShadowFrame* shadow frame (ShadowFrame: :Create (num regs, 
nullptr, method, 0, memory)); 


Create 限 数 会 根据 memory 大 小 生成 一 个 栈 帧 : 


static ShadowFrame* Create(uint32_t num_vregs, ShadowFrame* lin 
ArtMethod* method, uint32_t dex_pc, void 
ShadowFrame* sf = new (memory) ShadowFrame(num_vregs, link, m 
return sf; 
} 


num_regs :目标 函数 所 需要 的 寄存 器 数量 。Android 程 序 在 被 编译 成 
Dex 前 ， 会 为 每 个 函数 提供 一 个 名 为 registers_size 的 变量 ， 记 录 了 为 
保证 本 函数 正常 运行 所 需 的 寄存 器 数量 ， 以 便 虚 拟 机 在 运行 态 时 可 以 正 
确 分 配 资 源 。 


method: 代表 目标 函数 的 ArtMethod#。 
memory: 上 述 寄存 器 所 占用 的 内 存 空 间 。 


ShadowFrame 同 时 还 提供 了 不 少 操作 这 些 寄存 器 的 方法 ， 如 
GetVReg, SetVReg , GetVReg FromQuickCode®. Interpreter Æ I1 
过 程 中 ， 需 要 通过 ShadowFrame 来 完成 字 节 码 的 解析 和 执行 。 


函数 artQuickTolnterpreterBridge 的 另外 一 个 关键 点 是 调用 
Interpreter 提 供 的 Enter Interpreter FromEntryPoint 来 真正 切入 到 解 
释 器 中 。 因 为 栈 帧 已 经 创建 ， 因 而 Enter lnterpreterFromEntryPoint 主 
要 做 的 是 一 些 合法 性 检验 工作 一 一 如 果 一 切 正 常 的 话 ， 就 可 以 调用 
Execute 来 真正 地 解析 和 运行 字 节 码 了 。 最 终 的 执行 结果 将 通过 r0 返 回 
给 调用 方 ， 然 后 再 层 层 回 传 。 


这 样 一 来 interpreter 的 执行 就 与 ArtMethod 的 实际 情况 完美 地 结合 
起 来 ， 保 证 了 interpreter 中 本 地 代码 执行 和 字 节 码 解 释 执 行 两 种 状态 
之 间 的 正确 切换 。 


。 (2) 本 地 代码 的 执行 


本 地 代码 的 执行 也 会 遇 到 和 interpreter 中 类 似 的 问题 ， 即 如 何 处 
理 不 同 函 数 间 的 跳 转 关系 一 一 这 其 中 的 关键 就 在 于 本 地 代码 如 何 与 类 加 
载 系统 建立 无 缝 连接 。 本 地 代码 为 了 解决 这 个 难题 所 使 用 的 “ 银 弹 ”是 
Jump Table. 


这 同时 也 是 A0SP 工 程 中 /art/runtime/entrypoints 文 件 夹 下 数 十 个 
源 文件 所 要 完成 的 工作 。EntryPoint 的 主体 有 3 个 ， 即 
Interpreter (Android N 版 本 中 的 实现 发 生 了 变化 ， 不 再 独立 保留 
Interpreter EntryPoint) 、Quick 〈 早 期 虚拟 机 版 本 中 除了 Qui ck 外 还 
有 Portable 实 现 ， 不 过 目前 也 已 经 被 移 除 了 ) , URN. ENF 
entrypoints 目 录 下 都 有 对 应 的 子 文件 夹 。 


我 们 知道 在 早期 的 Art 虚 拟 机 版 本 中 ， 它 同时 支持 Portab le 和 Qui ck 
两 种 机 制 。 其 中 Portable 实 现 外 部 函 ; 数 引 用 的 做 法 和 前 面 小 节 介 绍 的 
ELF 规 范 中 的 动态 链接 方式 是 非常 类 似 的 ， 这 或 许 也 是 
它 “Portable” 名 称 的 由 来 。 Qu i ck 机制 则 “另辟蹊径 ”， 它 并 不 需要 
像 ELF 那 样 去 执行 动态 链接 的 过 程 ， 而 是 通过 几 个 EntryPoint 就 可 以 完 
成 对 外 部 函数 的 调用 过 程 。 


EntryPoints 是 由 Thread 的 几 个 全 局 变量 管理 的 ， 如 下 所 示 : 


/*art/runtime/Thread.h*/ 

class Thread 4... 
JniEntryPoints jni_entrypoints; 
QuickEntryPoints quick_entrypoints; 


它们 会 在 Thread: :1nit 中 通过 InitTIsEntryPoints 来 得 到 初始 化 : 


/*art/runtime/Thread.cc*/ 
void Thread: :InitTlsEntryPoints() 4.. 
InitEntryPoints(&tlsPtr_.jni_entrypoints, &tlsPtr_.quick_entryp 


J 


InitEntryPoints 在 多 种 主流 的 硬件 架构 上 都 有 定义 ， 如 x86、 
Arm, mips 〈 都 同时 支持 32 和 64 位 版 本 ) 等 。 以 Arm 平 台 为 例 ， 其 实现 如 
T: 


/*art/runtime/arch/arm/Entrypoints_init_arm.cc*/ 

void InitEntryPoints(JniEntryPoints* jpoints, QuickEntryPoints* q 
// INI 
jpoints->pDlsymLookup = art_jni_dlsym_lookup_stub; 


// Alloc 
ResetQuickAllocEntryPoints(qpoints); 


// Cast 
qpoints->pInstanceofNonTrivial = artIsAssignableFromCode; 
qpoints->pCheckCast = art_quick_check_cast; 


// DexCache 

qpoints->pInitializeStaticStorage = art_quick_initialize_static 
qpoints->pInitializeTypeAndVerifyAccess = art_quick_initialize_ 
qpoints->pInitializeType = art_quick_initialize_type; 
qpoints->pResolveString = art_quick_resolve_string; 


// JNI 
qpoints->pJniMethodStart = JniMethodStart; 
qpoints->pJniMethodStartSynchronized = JniMethodStartSynchroniz 
qpoints->pJniMethodEnd = JniMethodEnd; 
qpoints->pJniMethodEndSynchronized = JniMethodEndSynchronized; 
qpoints->pJniMethodEndwithReference = JniMethodEndwithReference 
qpoints->pJniMethodEndwithReferenceSynchronized = 
JniMethodEndwithReferenceSynchroniz 
qpoints->pQuickGenericJniTrampoline = art_quick_generic_jni_tra 


// Invocation 
qpoints->pQuickImtConflictTrampoline = art_quick_imt_conflict_t 
qpoints->pQuickResolutionTrampoline = art_quick_resolution_tram 
qpoints->pQuickToInterpreterBridge = art_quick_to_interpreter_b 
qpoints->pInvokeDirectTrampolinewithAccessCheck = 
art_quick_invoke_direct_trampoline_with_access_check; 
qpoints->pInvokeInterfaceTrampolinewithAccessCheck = 
art_quick_invoke_interface_trampoline_with_access_check; 
qpoints->pInvokeStaticTrampolinewithAccessCheck = 
art_quick_invoke_static_trampoline_with_access_check; 
qpoints->pInvokeSuperTrampolinewithAccessCheck = 
art_quick_invoke_super_trampoline_with_access_check; 
qpoints->pInvokeVirtualTrampolinewithAccessCheck = 
art_quick_invoke_virtual_trampoline_with_access_check; 





// Thread 
qpoints->pTestSuspend = art_quick_test_suspend; 


变量 jpoints 和 qpoints 分 别 对 应 JN1 和 Qui ck 两 个 主体 。 它 们 的 数据 
结构 各 不 相同 ， 例 如 JniEntryPoints 的 实现 如 下 : 


struct PACKED(4) JniEntryPoints { 
// Called when the JNI method isn't registered. 
void* (*pDlsymLookup)(JNIEnv* env, jobject); 


}; 


JniEntryPoints 结 构 体 中 只 有 pD1symLookup 一 个 函数 指针 ， 只 有 当 
UNI Method 没 有 注册 的 情况 下 它 才 会 被 调用 。 


QuickEntryPoints 可 以 说 是 最 重要 的 一 个 EntryPoint， 因 为 Art 中 
的 一 大 特性 就 是 将 Dex 转 成 了 0at 这 是 虚拟 机 运行 速率 得 以 提升 的 
一 大 根 因 。 可 以 看 到 ，Qui ckEntryPoints 包 含 的 内 容 很 多 ， 从 Al loc、 
Cast、DexCache、Field 访 问 控制 、Math 计 算 等 都 有 涉及 。 这 样 一 来 0at 
中 的 本 地 代码 在 需要 访问 上 述 分 类 中 的 函数 时 ， 就 完全 可 以 通过 这 些 





entrypoints 入 口 地 址 来 获取 了 。 由 于 这 种 访问 是 不 涉及 动态 链接 过 程 
的 ， 所 以 理论 上 讲 会 比 传统 方式 来 得 快 〈 这 是 其 被 命名 为 “Quick” 的 
最 主要 原因 ) 。 


Thread 中 提供 的 上 述 这 些 入 口 函 数 如 何 可 以 让 0at 中 的 本 地 代码 方 
便 地 访问 到 呢 ? 这 就 是 Android 虚 拟 机 的 调用 约定 中 将 寄存 器 r9 用 于 保 
Current Thread 的 用 意 所 在 了 ， 我 们 在 后 续 小 节 中 还 有 更 详细 的 分 
析 。 


只 要 dex2oat 编 译 生成 的 native code 遵 循 r9 寄 存 器 的 约定 ， 那 么 本 
地 代码 就 可 以 在 必要 的 时 候 通 过 这 个 寄存 器 找到 上 述 的 Jump 
Table (Entry Points)， 进 而 重新 回 到 Runt ime 环 境 中 ， 然 后 借助 于 类 加 
载 系统 来 找到 和 调用 目标 函数 ， 从 而 实现 本 地 代码 对 外 部 函数 的 引用 。 
a 它们 都 可 以 做 到 “互联 互 
过 o 


21.9 Art 虚拟 机 的 “中 枢 系 统 ”一 一 执行 引擎 之 1nterpreter 


接 下 来 的 章节 内 容 中 我 们 将 逐一 揭 开 Android 虚 拟 机 执行 程序 的 3 种 
主要 方式 ， 分 别 是 Interpretation、JIT 和 AOT。 


我 们 知道 在 Android Dalvik 时 代 ， 解 释 器 其 实 是 有 C 可 移植 版 本 和 
汇编 代码 两 个 版 本 的 。 但 是 Android Art 在 取代 Dalvik 的 早期 ， 却 只 提 
供 了 c 语 言 实现 的 Interpreter。 猜 测 这 很 可 能 是 因为 当时 Art 虐 拟 机 中 
引入 的 A0T 实 现 大 幅 提 升 了 虚拟 机 性 能 ， 它 的 作者 们 认为 Interpreter 已 
经 处 于 相对 “弱势 ”的 地 位 ， 甚 至 是 可 有 可 无 的 《除了 某 些 特殊 情况 ) 
状态 ， 所 以 也 就 没有 特意 去 关心 解释 器 的 效率 问题 了 。 但 是 到 了 
Android N 版 本 时 这 种 情况 又 发 生 了 变化 。 简 单 来 说 ，Art 虚 拟 机 是 一 个 
Interpreter+JIT+A0T 大 融合 的 环境 ， 这 3 种 执行 方式 各 有 优 缺 点 ， 并 不 
存在 非 此 即 彼 的 关系 。 因 而 为 了 达到 它们 三 方 之 间 的 一 种 最 佳 平衡 ， 
Android 虚 拟 机 团队 不 得 不 重新 选择 在 Interpretation 上 加 大 功夫 ， 于 
是 又 出 现 了 汇编 版 本 的 解释 器 。 具 体 原因 和 细节 我 们 在 下 一 小 节 讲 解 
JIT 时 还 会 有 前述 。 


本 小 节 我 们 着 重 来 分 析 Android N 版 本 中 解释 器 的 内 部 实现 原理 。 

Interpreter 对 应 的 源码 路 径 是 art/runtime/interpreter， 除 了 不 
多 的 几 个 C++ 源 文 件 外 ， 其 他 与 平台 相关 的 汇编 代码 则 保存 在 子 目录 
mterp 里 。 


和 所 有 标准 JVM 虚 拟 机 中 解释 器 所 担负 的 职责 类 似 ，Android 系 统 给 
解释 器 分 配 的 任务 也 是 解析 字 节 码 并 了 予以 执行 。 解 释 器 的 抽象 模型 可 以 
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全 图 21-57 模型 


输入 源 既 可 以 是 最 原始 的 编程 语言 ， 也 可 以 是 类 似 于 Java 中 的 
Bytecode 的 这 类 中 间 表 示 。 从 这 个 角度 来 看 它 和 编译 器 的 区 别 在 于 : 前 
者 是 对 程序 语义 的 执行 结果 ， 而 编译 器 则 是 用 另 一 种 语言 来 表示 原始 语 
言 (通常 原始 语言 比 编译 器 输出 语言 高 级 ， 例 如 从 0 语言 编译 成 机 器 语 
言 ) 。 解 释 型 语言 并 个 代表 完全 不 需要 编译 ， 事 实 上 很 多 解释 器 的 内 部 
实现 也 是 先 编译 源码 ， 然 后 才 加 以 执行 。 只 不 过 对 于 用 户 来 说 编译 的 过 
程 是 透明 未 可 知 的 ， 从 而 让 人 产生 了 “解释 执行 的 错觉 ”。 从 编程 语言 
的 角度 而 言 解释 器 并 没有 被 规定 具体 的 实现 方式 ， 所 以 我 们 说 解释 型 语 
言 或 者 编译 型 语言 ， 在 定义 上 都 应 该 加 上 限定 词 一 一 即 它 们 的 “主要 / 
主流 ”的 实现 方式 是 解释 执行 或 者 编译 执行 ， 这 样 才 不 至 于 引起 误解 。 


对 于 Android 虚 拟 机 中 的 解释 器 ， 输 入 源 特 指 的 是 Android 字 节 码 。 
s eee egg ee mean 
它们 呢 ? 


首先 可 以 想到 的 是 用 一 个 switch 语 句 来 分 别处 理 每 一 条 字 节 码 ， 类 
似 下 面 这 样 的 代码 结构 : 


while(NOT_END) { 
switch(opcode) { 

case CODE_1: 
do_something; 
break; 

case CODE_2: 
do_something; 
break; 


; n 
取 新 的 指令 ; 


这 事实 上 就 是 Java 虚 拟 机 经 典 的 switch 型 解释 器 的 锥 形 。 它 的 内 部 
结构 虽然 相当 清晰 简洁 ， 但 是 却 存在 一 个 致命 的 问题 一 一 效率 低下 。 这 
其 中 的 “罪魁 祸首 ”是 每 条 指令 的 执行 都 需要 “漫长 ”的 判断 过 程 一 一 
即 从 CODE_1 开 始 ， 直 到 匹配 到 正确 的 目标 指令 ， 如 此 循环 往复 。 这 样 一 
来 当 指令 数量 达到 一 定 规模 时 ， 这 种 结构 的 弊端 就 非常 明显 了 。 


Android N 版 本 也 提供 了 switch 类 型 的 解释 器 ， 其 入 口 函 数 是 
ExecuteSwitchlmp1， 核 心 代码 如 下 所 示 : 


/*art/runtime/interpreter/interpreter_switch_impl.cc*/ 
template<bool do_access_check, bool transaction_active> 
JValue ExecuteSwitchImpl(Thread* self, const DexFile::CodeItem* c 
ShadowFrame& shadow_frame, JValue result 
bool interpret_one_instruction) { .. 
do { 
dex_pc = inst->GetDexPc(insns); 
shadow_frame.SetDexPC(dex_pc); 
TraceExecution(shadow_frame, inst, dex_pc); 
inst_data = inst->Fetchi6(0); 
switch (inst->Opcode(inst_data)) { 
case Instruction: :NOP: 
PREAMBLE(); 
inst = inst->Next_1xx(); 
break; 
case Instruction: :MOVE: 
PREAMBLE(); 
shadow_frame.SetVReg(inst->VRegA_12x(inst_data), 
shadow_frame.GetVReg(inst->VRegB_12x 
inst = inst->Next_1xx(); 
break; 


} while (!interpret_one_instruction); 


从 这 个 函数 可 以 看 出 Android 中 的 switch 型 虚拟 机 符合 我 们 前 述 的 
经 典 结构 。 


既然 switch 类 型 的 虚拟 机 效率 上 存在 重大 缺陷 ， 那 么 我 们 是 否 有 什 
么 改进 方法 呢 ? 


相信 大 家 会 很 自然 地 想到 Goto 方 式 。 没 错 ，Switch 结 构 最 大 的 问题 
在 于 需要 逐一 去 寻找 “每 一 条 指令 所 对 应 的 处 理 函 数 ”， 那 么 如 果 我 们 
将 指令 与 其 处 理 函 数 直接 建立 “一 对 一 ”的 联系 ， 性 能 问题 理论 上 就 迎 
妨 而 解 了 。 可 以 参考 Android 里 的 具体 实现 ， 在 
interpreter_goto _ table_imp1. cc 的 ExecuteGotolmp1 函 数 中 : 


template<bool do_access_check, bool transaction_active> 
JValue ExecuteGotoImpl(Thread* self, const DexFile::CodeItem* cod 
shadow_frame, JValue result_register) { 
static const void* const 
handlersTable[ instrumentation: :kNumHandlerTables 


{ 
// Main handler table. 
#define INSTRUCTION_HANDLER(o, code, n, f, r, i, a, v) &&op_##cod 


#include "dex_instruction_list.h" 
DEX_INSTRUCTION_LIST(INSTRUCTION_HANDLER) 

#undef DEX_INSTRUCTION_LIST 

#undef INSTRUCTION_HANDLER 


r { 
// Alternative handler table. 
#define INSTRUCTION_HANDLER(o, code, n, f, r, i, a, v) &&alt_op_# 
#include "dex_instruction_list.h" 
DEX_INSTRUCTION_LIST(INSTRUCTION_HANDLER) 
#undef DEX_INSTRUCTION_LIST 
#undef INSTRUCTION HANDLER 
} 
}; 


根据 Goto 结 构 的 设计 思路 ， 我 们 首先 需要 构造 一 个 数组 。 不 难看 出 
上 述 代 码 段 中 的 handlersTable 是 一 个 二 维 数组 ， 包 含 
了 “Main” 和 “Alternative” 两 种 Handler Table。 其 中 Main Table 是 
正常 情况 下 的 指令 处 理 函 数 的 集合 ，Alternative Table 则 主要 在 
Instrumentation (Android 虚 拟 机 提供 的 一 种 插 桩 机 制 ， 以 保证 单 步 调 
试 、Tracer 等 可 以 正常 工作 ) 的 情况 下 发 挥 作用 : 


HANDLE_INSTRUCTION_START (MOVE) 
shadow_frame.SetVReg(inst->VRegA_12x(inst_data), 


shadow_frame.GetVReg(inst->VRegB_12x(ins 
ADVANCE(1); 
HANDLE_INSTRUCTION_END( ); 


HANDLE_INSTRUCTION_START (MOVE_FROM16 ) 
shadow_frame.SetVReg(inst->VRegA_22x(inst_data), 
shadow_frame.GetVReg(inst ->VRegB_22x())) 
ADVANCE(2); 
HANDLE_INSTRUCTION_END( ); 


上 述 代码 段 中 的 HANDLE_INSTRUCTION_START 用 于 定义 一 个 opcode 的 
labe1， 如 下 所 示 : 


#define HANDLE_INSTRUCTION_START(opcode) op_##opcode: 


前 面 在 定义 handlersTable 时 ， 和 每 一 项 的 取 值 都 是 &&op_ 检 code， 这 
样 一 来 opcode 就 和 它 对 应 的 处 理 代码 建立 起 关联 了 。 


另外 ，ADVANCE 宏 用 于 取出 并 跳 转 到 下 一 个 指令 去 执行 ， 从 而 保证 
程序 的 正常 运行 ，HANDLE 1NSTRUCTION_END 的 主要 用 途 是 “分 隔 ” 各 个 
指令 一 一 因为 ADVANCE 会 跳 转 到 其 他 指令 去 执行 ， 所 以 任何 情 况 下 程序 
如 果 走 到 HANDLE_1INSTRUCTION_END 的 话 就 说 明 出 现 了 严重 的 问题 ， 此 时 
SAFE AY AAI 


最 后 我 们 再 来 讨论 一 下 汇编 语言 实现 的 解释 器 。 


需要 强调 的 是 ， 基 于 汇编 的 解释 器 并 不 是 Android N 版 本 或 者 Art 虚 
拟 机 独创 的 ， 因 为 早 在 Dalvik 时 代 Android 融 提供 了 portable 和 fast 两 
种 版 本 的 解释 器 了 ， 它 们 分 别 是 由 C 和 汇编 语言 编写 完成 的 。 所 以 这 次 
Android N 版 本 中 引入 汇编 解释 器 只 能 说 是 它 “ 重 返 疆 场 ”。 


汇编 解释 器 虽然 执行 效率 高 ， 但 缺点 也 是 明显 的 一 一 它 需 要 针对 不 
同 的 硬件 架构 进行 适 配 。 目 前 Android N 版 本 中 已 经 支持 arm、arm64、 
mips、mips64、x86 和 x86_64 等 多 种 硬件 体系 ， 它 们 都 统一 被 放置 在 
art/runtime/interpreter/mterp 目 录 下 。 每 一 个 opcode 的 处 理 代码 都 
以 一 个 单独 的 . 文件 来 提供 ， 例 如 op_aget. S、op_aget_char. S, 
op_aput. S 等 。 


至 于 具体 是 采用 switch、Goto 抑 或 是 Assemb le 解释 器 ， 百 先是 由 
klnterpreterlmp1Kind 变 量 决 定 的 一 一 它 的 初始 值 是 kMterplmp1Kind， 
即 汇编 解释 器 。 然 后 我 们 还 需要 根据 运行 过 程 中 的 实际 4 育 况 来 做 调整 。 
某 些 情况 下 汇编 解释 器 是 无 法 满足 程序 的 运行 需求 的 ， 例 如 它 并 不 能 
效 支 撑 所 有 的 instrumentation 和 debugging 的 场景 。 此 时 我 们 就 要 选择 
切换 到 switch 或 者 Goto 类 型 来 保证 程序 的 正常 运行 。 


21.10 Art 虚拟 机 的 “中 枢 系 统 ” 一 一 执行 引擎 之 JIT 


和 A0T 相 反 ，Just-in-time compilation 是 一 种 动态 编译 ， 意 味 着 
它 是 在 程序 运行 过 程 中 才 执 行 的 编译 工作 。JIT 在 Android 虚 拟 机 中 的 应 
用 历史 是 比较 有 戏剧 性 的 ， 具 体 描述 如 下 所 示 : 


Android Dalvik 时 代 : JIT 是 虚拟 机 中 保证 运行 效率 的 重要 保障 机 
Ns 


Android ART 《N 版 本 之 前 ): JIT“ 退 隐 江 湖 ”。 
Android ART (N 版 本 开始 ) : JIT 又 “重出 江湖 ”。 
21. 10.1 JIT 重 出 江湖 的 契机 


除了 技术 方面 的 考虑 外 ， 有 的 时 候 “ 政 治 ” 原 因 事实 上 更 有 权利 决 
定 一 项 技术 的 “生死 ”， 这 一 点 无 论 在 大 公司 还 是 小 公司 都 是 一 样 的 。 
a eee 我 们 还 是 专注 在 技术 领 
或 的 分 析 吧 。 


在 本 章 的 开头 ， 我 们 已 经 对 Art 与 Dalvik 做 了 性 能 对 比 ， 可 以 看 出 
前 者 确实 是 存在 优势 的 。 支 撑 Art 的 核心 技术 是 AoT， 它 和 JIT 从 理论 上 
讲 是 两 个 概念 。 不 过 这 并 不 能 说 明 JIT 就 一 无 是 处 。 相 反 ， 它 们 各 有 优 
缺点 一 一 譬如 JIT 显 然 比 A0T 更 节省 存储 空间 ; 而 且 不 需要 在 程序 安装 ， 
或 者 每 次 系统 升级 /应 用 程序 升级 后 都 做 A0T 优 化 。 图 21-58 所 示 是 我 们 
在 Android N 版 本 之 前 会 经 常 看 到 的 一 个 用 户 界面 。 





Android is upgrading... 


( ) Optimizing app 26 of 47. 





全 图 21-58 用 户 界面 


由 于 Goog1e 安 全 补丁 更 新 越 来 越 频繁 ， 这 就 意味 着 用 户 很 可 能 会 在 
一 个 月 甚至 更 短 的 时 间 内 经 历 图 21-58 所 示 的 优化 过 程 。 从 而 给 Android 


的 用 户 体验 市 来 新 的 挑战 。 
那么 我 们 是 否 有 可 能 将 它们 做 一 个 融合 ， 取 各 家 所 长 ， 补 双方 所 短 


m? 


这 或 许 是 Android N 中 引入 JIT 的 一 个 重要 原因 ， 我 们 可 以 从 Google 
1/0 2016 会 议 上 提供 的 材料 得 到 一 些 启 发 ， 如 图 21-59 所 示 。 
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全 图 21-59 Android N 版 本 中 重新 引入 JIT 技 术 的 潜在 优势 {--} (51 É Google I/O 2016) 





可 以 看 到 JIT 和 A0T 的 结合 在 Android 虚 拟 机 的 多 个 方面 上 都 带 来 了 
可 喜 的 提升 ， 接 下 来 的 几 个 小 节 中 我 们 将 逐一 揭晓 隐藏 在 这 些 新 变化 之 
后 的 实现 原理 。 


21.10.2 Android N 版 本 中 JIT 的 设计 目标 及 策略 


JIT 在 设计 初期 主要 设 定 了 如 表 21-11 几 个 目标 ， 并 提出 了 相应 的 设 
计策 略 : 
表 21-11 目标 及 策略 


[| TT | 





考量 设计 策略 


因为 不 需要 在 程序 安装 时 执行 AOT 预 编译 ， 所 以 不 会 出 
现 漫长 的 安装 等 等 














Android N 版 本 中 的 JIT 至 少 采 用 了 如 下 几 种 方式 来 保证 
程序 的 启动 速度 : (1) 足够 快 的 解释 器 ， 可 以 参考 前 一 
小 节 的 分 析 (2) 调整 Dex 的 verification 时 机 ， 见 下 面 的 
详细 说 明 (3) 在 运行 过 程 中 记录 影响 启动 速度 的 











Classes， 并 做 特别 优化 (4) 为 应 用 程序 提供 Image。 在 
之 前 的 版 本 中 ， 只 有 boot.art 具 有 这 种 特性 ， 而 Android N 
版 本 将 这 种 优势 扩大 到 了 所 有 的 应 用 程序 中 


JIT 的 编译 过 程 在 独立 的 线程 中 完成 ， 并 且 给 UI 线程 更 高 
的 优先 级 


只 编译 那些 有 必要 的 函数 





e | 的 GC 宁 略 ， 保 证 无 用 的 内 存 占 用 被 及 时 清理 | 


为 了 保证 程序 的 局 动 速度 ，Art 开 发 小 组 做 了 如 下 一 系列 针对 Gmail 
的 实验 ， 如 图 21-60 所 示 《图 例 无 特别 说 明 均 引用 自 Google 1/0 
2016) . 
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全 图 21-60 Android M 版 本 上 Gmail 的 局 动 耗 时 数据 


(1) 首先 在 Android MashMallow 上 启动 Gbmai1， 并 利用 SysTrace 抓 
取 到 如 图 21-60 所 示 的 数据 。 
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可 以 看 到 在 Android M 版 本 上 Gmai | 启动 第 一 帧 所 需 时 间 为 0. 57 秒 。 


(2) 紧 接着 是 在 Art 小 组 实现 的 第 一 个 JIT 版 本 上 针对 上 述 步 又 中 
的 同一 个 程序 展开 实验 。 
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全 图 21-61 Android N 上 第 一 个 JIT 版 本 启动 Gmail 的 耗 时 数据 


从 图 21-61 所 示 可 以 看 到 这 种 情况 下 启动 第 一 帧 所 需 时 间 为 1. 3 秒 ， 
差不多 为 A0T 版 本 中 的 2 倍 。 


(3) 那么 是 什么 原因 导致 了 JIT 情 况 下 的 启动 速度 变 慢 呢 ? 如 图 
21-62 所 示 。 
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全 图 21-62 启动 慢 的 原因 分 析 


由 图 21-62 可 以 看 到 ， 在 第 一 帧 显示 之 前 APK 经 历 了 Extraction 和 
Ver ification 两 个 阶段 ， 它 们 都 将 在 一 定 程度 上 拖 慢 启动 速度 。 因 而 
Art 小 组 一 方面 尝试 将 这 两 个 动作 前 移 到 程序 的 安装 阶段 ， 另 一 方面 在 
解释 器 的 提速 上 做 了 很 多 工作 (包括 提供 汇编 版 本 的 解释 器 ) ， 最 后 让 
程序 的 启动 速度 有 了 明显 改善 ， 如 图 21-63 所 示 实 验 结果 。 
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AA21-63 经 过 优化 后 的 JIT 版 本 实验 结果 


采取 了 多 种 改进 措施 后 ，Gmai 1 程序 在 Android N 版 本 中 的 第 一 帧 启 
动 时 间 降 低 到 了 0. 63 秒 ， 和 AOT 已 经 非常 相近 了 。 


21.10.3 Profile Guided Compilation (追踪 技术 ) 


从 前 面 章节 的 学 习 中 ， 我 们 知道 Android M 版 本 中 的 A0T 编 译 有 两 个 
主要 的 执行 时 机 ， 即 ROM 系 统 编译 时 以 及 第 三 方 应 用 程序 安装 时 。 那 么 
大 家 可 以 思考 一 下 ，JI1T 编 译 又 该 在 什么 时 候 执 行 才 是 最 合适 的 呢 ? 


根据 JIT 的 设计 理念 ， 它 显然 不 会 像 AOT 那 样 对 程序 的 大 部 分 Java 代 
码 都 进行 编译 GER: 理论 上 这 是 可 以 配置 的 ) ， 所 以 必定 需要 一 套 追 
踪 机 制 来 决定 哪 一 部 分 代码 需要 被 执行 JIT 一 一 即 “ 热 区 域 ” 的 确定 。 
和 传统 的 JIT 不 同 的 是 ，Android N 版 本 中 的 追踪 技术 又 被 称 
为 “Profile Guided Compilation”。 


Profile Guided Compilation 的 基本 工作 原理 如 图 21-64 所 示 。 
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全 图 21-64 基本 工作 原理 


Step1， 当 应 用 程序 第 一 次 启动 时 ， 只 会 通过 解释 器 执行 ， 同 时 JIT 
会 介入 并 针对 hot methods 执 行 优 化 工作 。 

Step2， 上 述 执行 过 程 中 还 将 同步 输出 一 种 被 称 为 “Profile 
information” 的 信息 ， 并 按 一 定 规律 保存 到 文件 中 。Prof i le 文件 属于 
程序 属 主 “私人 ” 持 有 。 


Step3. 上述 两 个 步骤 会 被 重复 执行 ， 因 而 Profile information 得 
到 不 断 地 完善 。 


Step4.， 当 设备 处 于 idle 状 态 并 且 同 时 还 在 充电 时 ， 就 进入 了 
Profile guided compilation 服 务 。 这 个 编译 过 程 将 以 Profi le 
informat ion 文 件 为 输入 ， 最 后 的 输出 则 是 二 进 制 机 器 代码 。 后 者 会 被 
用 于 替代 原始 应 用 程序 的 相应 部 分 。 

那么 我 们 需要 在 Profi le information 中 记录 哪些 必要 的 数据 呢 ? 

e Hot Methods 
即 需要 离线 优化 的 函数 。 
o 影响 程序 启动 速度 的 Classes 
用 于 进一步 优化 程序 的 启动 速度 。 





Step5， 在 经 过 上 述 步 骤 后 ， 应 用 程序 在 后 续 启 动 时 就 可 以 根据 实 
际 情况 来 在 A0T/JIT/ lnterpretion 中 择优 选取 一 种 执行 方式 了 。 


JIT 在 Android N 版 本 中 有 专门 的 源 代码 目录 ， 即 
AOSP/art/runtime/jit。 它 在 Runtime: :Start 中 会 被 启动 ， 如 下 所 示 : 


/*art/runtime/runtime.cc*/ 
bool Runtime: :Start() {.. 
if (jit_options_->UseJIT()) { 
std::string error_msg; 


if (!IsZygote()) { 
CreateJit(); 
} else if (!jit::Jit::LoadCompilerLibrary(&error_msg)) { 
// Try to load compiler pre zygote to reduce PSS. b/2774494 
LOG(WARNING) << "Failed to load JIT compiler with error " < 
} 


JIT 相 关 的 选项 jit_options 是 在 Runtime::1nit 中 赋值 的 ， 其 中 是 
否 启 用 JIT 由 下 面 语句 判断 : 


jit_options->use_jit_ = options.GetOrDefault (RuntimeArgumentMap 


而 RuntimeArgumentMap: :UseJIT 的 具体 值 取 决 于 系统 变 
量 “dalvik. vm. usejit”， 后 者 将 由 AndroidRunt ime 在 启动 虚拟 机 时 和 
其 他 VM 选 项 一 起 处 理 。 


训 无 疑问 JIT 系 统 是 一 个 单 实例 ， 静 态 函 数 Jit: : Create 负 责 这 一 
实例 的 生成 工作 。JIT 的 核心 工作 都 是 在 自己 独立 的 线程 中 完成 的 ， 以 
避免 对 程序 运行 性 能 造成 影响 〈 即 Jank 事 件 ) 。 


根据 Profile Guided Compi lation 的 工作 原理 ，JIT 模 块 所 要 完成 
的 主要 任务 如 下 : 


。 监测 程序 的 运行 情况 ， 获 取 “ 感 兴趣 ”的 信息 
这 个 工作 具体 是 由 JitlnstrumentationListener 完 成 的 ， 它 和 我 们 
在 本 章 中 分 析 的 Instrumentat ion 是 息息相关 的 ， 大 家 可 以 自行 阅读 代 
码 了 解 详情 。 
。 将 获取 到 的 信息 保存 到 文件 中 
具体 是 由 ProfileSaver 这 个 类 完成 的 。 
o 翻译 热点 函数 
实时 翻译 运行 过 程 中 的 热点 函数 的 能 力 是 由 1ibart-compi ler. so 或 
者 1ibartd-compiler. so 提供 的 ， 具 体 对 应 的 是 jit_compile_method 


数 ， 并 保存 在 JitCodeCache 中 。 这 样 一 来 某 个 ArtMethod 在 执行 时 除了 
考虑 A0T 和 lnterpretation 之 外 ， 还 需要 综合 参考 JIT 保 存在 全 局 变量 


code cache PAYZAR. 


了 解 了 JIT 模 块 的 职责 后 ， 读 者 们 可 能 还 有 这 样 的 疑问 ， 即 A0T 又 是 
在 什么 时 候 由 哪个 模块 负责 执行 的 呢 ? 我 们 在 下 一 小 节 中 来 回答 这 个 问 


题 。 
21.10.4 AOT Compilation Daemon 


为 了 满足 Profi le Guided Compilation (JIT) 的 编译 特点 ， 我 们 
需要 一 个 独立 的 Daemon 来 响应 0ffline AOT Compilation。Daemon 的 概 
念 相信 大 家 并 不 陌生 ，Android 系 统 中 拥有 多 个 与 之 类 似 的 守护 程序 ， 
例如 adbd、netd 等 。 


当 A0T Daemon 局 动 后 ， 它 的 核心 处 理 远 辑 如 图 21-65 所 示 。 





。 当 设 备 同时 处 于 idle 和 充电 状态 下 时 ，Daemon 被 唤醒 并 通过 遍历 来 
分 析 系 统 中 的 所 有 应 用 程序 ， 以 决定 是 否 需要 执行 AOT 操 作 。 

。 如 果 应 用 程序 是 “共享 ”的 ， 那 么 需要 对 它 执行 完全 的 编译 动作 。 

。 否则 查找 应 用 程序 中 是 否 有 对 应 的 Profile 文 件 。 如 果 答 案 是 否定 的 
话 ， 直 接 放弃 ;反之 进入 真正 的 Profile guided compilation. 
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全 图 21-65 AOT Daemon 的 核心 处 理 逻 辑 


Profile guided compi1ation 事 实 上 也 属于 A0T 技 术 的 范畴 ， 所 以 
它 完全 可 以 在 复 用 Android M 版 本 dex2oat 的 基础 上 再 进行 部 分 改造 。 这 
一 点 我 们 从 dex2oat. cc 文件 针对 option 的 处 理 中 亦 能 看 出 一 些 端 倪 : 


else if (option.starts with("--profile-file=")) { 
profile file = option.substr(strlen("--profile-file=")). 
} else if (option.starts_with("--profile-file-fd=")) { 
ParseUintOption(option, "--profile-file-fd", &profile_fil 
} else if (option == "--host") { 


J 


我 们 通过 内 容 小 结 来 帮助 大 家 将 所 有 知识 点 做 一 个 “ 串 接 


e 不同 于 Marsh Mallow 中 针对 所 有 应 用 程序 预先 执行 AOT 的 做 法 ， 
Android N 版 本 并 不 会 在 应 用 程序 安装 过 程 中 调用 dex2oat。 一 方 
面 ， 这 种 新 变化 大 幅 加 快 了 程序 的 安装 速度 ， 解 决 了 系统 更 新 时 用 
户 需 要 经 历 漫 长 等 待 的 问题 ; 为 一 方面 ， 由 于 程序 的 首次 启动 必须 
通过 解释 器 来 运行 ，Android N 版 本 必须 采用 多 种 手段 (新 的 解释 
器 、 将 Verification 前 移 等 ) 来 保证 程序 的 启动 速度 不 受 影响 。 
应 用 程序 除了 解释 执行 外 ， 还 会 在 运行 过 程 中 实时 做 JIT 编 译 
不 过 它 的 结果 并 不 会 被 持久 化 。 另 外 ， 虚 拟 机 会 记录 下 应 用 程序 在 
动态 运行 过 程 中 被 执行 过 的 函数 ， 并 输出 到 Profile 文 件 里 。 
AOT compilation daemon 将 在 系统 同时 满足 idle 和 充电 状态 两 个 条 件 
时 才 会 被 唤醒 ， 并 按照 一 定 的 逻辑 来 遍历 执行 应 用 程序 的 AOT 优 
化 。 由 于 参与 AOT 的 函数 数量 通常 只 占 应 用 程序 代码 的 一 小 部 分 ， 
所 以 整体 而 言 Android N 版 本 中 AOT 结 果 所 占用 的 空间 大 小 比 旧版 
本 要 小 很 多 。 
21.11 Art 虚 拟 机 的 “中 枢 系 统 ” 一 一 执行 引擎 之 本 地 代码 

前 面 几 个 小 节 我 们 综述 了 虚拟 机 中 代码 的 执行 过 程 ， 并 且 对 JIT、 
Interpreter 两 种 方式 进行 了 扩展 分 析 。 现 在 是 时 候 前 述 虚 拟 机 中 另 一 
个 重要 的 执行 引擎 了 ， 即 本 地 代码 的 执行 过 程 。 

我 们 可 以 从 以 下 两 个 角度 来 思 











e Zygote 


我 们 知道 ，Zygote 是 一 切 Android 应 用 程序 的 “鼻祖 ”， 而 这 
个 “ 旷 化 器 ”自身 除了 包含 一 小 部 分 本 地 代码 外 ， 其 他 绝 大 部 分 也 是 通 
过 Java 语 言 实现 的 。 这 意味 着 它 也 需要 启动 一 个 虚拟 机 实例 来 执行 代码 
程序 。 而 Zygote 本 身 的 功能 又 是 比较 单纯 的 ， 所 以 它 是 我 们 分 析 虚 拟 机 
中 代码 执行 过 程 的 一 个 很 好 的 介入 点 。 


。 Apk 应 用 程序 
Android 虚 拟 机 的 最 大 价值 体现 在 应 用 程序 中 。 一 旦 我 们 掌握 了 


Zygote 中 是 如 何 利用 Art 虚 拟 机 来 为 其 服务 的 “脉络 ”以 后 ， 那 么 对 APK 
应 用 程序 部 分 的 理解 就 只 要 侧重 于 和 Zygote 的 差异 部 分 就 可 以 了 。 


大 家 应 该 注意 到 了 ，Zzygote 在 调用 AndroidRuntime 的 start 国 数 时 
传 入 了 一 个 Class 名 称 ， 如 下 所 示 : 


runtime.start("com.android.internal.os.ZygoteInit", args); 


这 个 ClassName 人 参数 代表 的 是 需要 被 执行 的 类 对 象 。 一 旦 虚拟 机 局 
动 完 成 后 ， 就 会 首先 调用 这 个 类 中 的 静态 main (String[] args) 方 法 。 
我 们 在 前 述 小 节 中 已 经 分 析 过 AndroidRunt ime: :start 中 的 大 部 分 内 容 
了 ， 下 面 重点 看 一 下 与 Zygotelnit 相 关 的 部 分 : 


/*frameworks/base/core/jni/AndroidRuntime.cpp*/ 
void AndroidRuntime::start(const char* className, const Vector<St 
oe 
char* slashClassName = toSlashClassName(className) ; 
jclass startClass = env->FindClass(slashClassName) ; 
if (startClass == NULL) { 
ALOGE("JavaVM unable to locate class '%s'\n", slashClassN 
/* keep going */ 
} else { 
jmethodID startMeth = env->GetStaticMethodID(startClass, 
"(ELjava/lang/String; )V"); 
if (startMeth == NULL) { 
ALOGE("JavaVM unable to find main() in '%s'\n", class 
/* keep going */ 
} else { 
env->CallStaticVoidMethod(startClass, startMeth, strA 
} 


Jnilnvocation 中 的 Init 和 startVM 函 数 分 别 用 于 初始 化 和 启动 虚拟 
机 ， 然 后 onVmCreated () 会 被 回调 来 通知 持 有 者 虚拟 机 的 最 新 状态 。 这 
些 知识 点 我 们 在 前 面 小 节 中 已 经 分 析 过 了 ， 大 家 如 有 不 清楚 的 地 方 可 以 
回 过 头 去 阅读 。 


接 下 来 AndroidRuntime: :start 就 可 以 处 理 className 〈 即 这 个 场景 
中 的 Zygotelnit) 了 。 首 先 把 类 名 中 的 “. ”全 部 转换 成 slash 符 号 
(“/”) ， 得 到 如 下 的 结果 : 


com/android/internal/os/ZygoteInit 


这 样 做 的 目的 之 一 是 便于 虚拟 机 根据 类 名 来 查找 到 类 的 存储 地 址 。 


如 果 读 者 用 过 Java 反 射 机 制 ， 一 定 会 对 它 的 强大 之 处 印象 深刻 。 反 
射 机 制 可 以 在 运行 阶段 动态 加 载 并 实例 化 一 个 类 对 象 ， 在 某 些 场合 下 可 
以 为 程序 提供 非常 灵活 的 实现 。AndroidRuntime: :start 中 对 className 
的 处 理 过 程 实际 上 与 反射 机 制 的 原理 是 非常 相似 的 。 它 们 都 需要 回答 下 
面 的 几 个 问题 : 


。 问题 1. 如 何 快速 查找 到 包含 了 目标 类 的 Package 包 ; 
o 问题 2. 如 何 加 载 并 实例 化 className 所 指示 的 类 对 象 。 


与 标准 Java 虚 拟 机 不 同 ，Android 系 统 采 用 的 是 Dex 文 件 格 式 ， 而 且 
还 需要 考虑 事先 已 经 做 好 优化 〈odex 或 者 0AT 等 ) 的 情况 。 


另外 ， 针 对 Art 虚 拟 机 还 需要 额外 回答 : 

o 问题 3.Java 代 码 是 如 何 与 OAT 中 的 Native Code 准 确 对 应 起 来 的 呢 ? 
本 小 节 接 下 来 的 内 容 中 我 们 将 给 出 上 述 3 个 问题 的 答案 。 
AndroidRuntime 运 行 在 JN1 环 境 中 ， 其 中 jclass、jstring、 

jobjectArray 实 际 上 是 void# 指 针 的 typedef 类 型 ; env 变 量 则 属于 
JNIEnv 类 型 ， 用 于 提供 JN1 环 境 下 的 各 种 处 理 函 数 。 在 这 个 场景 中 ， 查 


找 className 的 关键 在 于 env->FindClass。 这 个 函数 经 过 多 层 封 装 后 
最 终 对 应 的 是 jni_internal. cc 中 的 FindC1ass， 核 心 实 现 如 下 所 示 : 








/*art/runtime/jni_internal.cc*/ 
static jclass FindClass(JNIEnv* env, const char* name) { 


if (runtime->IsStarted()) { 

c = class linker->FindClass(soa.Self(), descriptor.c_str(), 
} else { 

c = class linker->FindSystemClass(soa.Self(), descriptor.c_ 


return soa.AddLocalReference<jclass>(c); 


从 上 述 代 码 段 中 可 以 看 出 FindClass 将 面临 下 面 两 种 选择 : 





e tuntime->IsStatted0 为 ttue 的 情况 


IsStarted () 用 于 指示 当前 的 运行 时 环境 是 否 已 经 启动 成 功 ， 它 是 
HF started 变量 得 出 的 结论 ， 而 这 个 变量 在 Runt ime: :Start () 时 会 被 
置 为 true。 


这 种 情况 下 我 们 可 以 调用 class_linker 的 FindClass 方 法 来 查找 目 
标 类 。 


。 虚拟 机 运行 时 环境 还 未 启动 完成 的 情况 
此 时 不 能 直接 使 用 上 述 的 方法 ， 需 要 改 由 FindSystemClass〈 此 时 
程序 相关 的 Class 还 未 进入 Ready 状 态 ) 来 完成 查找 工作 。 


我 们 在 前 面 初始 化 和 启动 虚拟 机 小 节 曾 经 分 析 过 Class Linker, fay 
单 而 言 它 扮 演 的 是 “类 链接 器 ”的 角色 一 一 任何 与 目标 程序 以 及 虚拟 机 
本 身 相 关联 的 类 、 类 中 的 方法 等 都 属于 它 的 管辖 范围 。 换 句 话说 ， 
class linker 中 的 所 有 Class 类 、Jar 包 、 甚 至 Dex、1lmage 文 件 都 可 能 成 
为 FindC1ass 的 搜索 范围 。 


首先 来 看 下 ClassLinker::FindClass (Thread* self, const 
char* descriptor, Handle<mirror:: ClassLoader> class loader) 


肖 数 参数 的 来 源 : 
e Thread* self 
JNIEnv 对 应 的 线程 。 
e char* descriptor 
通过 std: :string 
descriptor (NormalizeJniClassDescriptor (name) ) 转换 而 来 。 
NormalizeJniClass Descriptor 会 把 name 中 的 “. ”转换 为 “/”， 其 结 
果 可 能 是 : “La/b/C;” 或 者 “[La/b/C;”。 在 我 们 这 个 场景 下 
descr iptor 对 应 的 是 : com/android/internal/os/ Zygotelnit. 


e Handle<mirror::ClassLoader> class_loader 
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诸如 Handle<mirror::ClassLoader> 这 样 的 模板 定义 在 虚拟 机 中 还 
有 很 多 ， 我 们 有 必要 做 一 下 解释 。 对 于 那些 从 虚拟 机 的 Heap 中 分 配 的 对 
象 ， 那 么 大 家 试想 一 下 : 如 果 系 统 中 发 生 了 G0， 并 且 垃 圾 回收 器 挪动 了 
对 象 的 位 置 ， 那 么 原先 那些 指向 老 位 置 的 变量 该 怎么 办 呢 ? 这 就 是 
Hand1e 的 存在 价值 了 。 因 为 它 所 包含 的 元 素 对 于 GC 是 可 见 的 ， 有 利于 后 
alee 而 这 一 点 显然 是 强 指 针 所 无 法 胜 
王 的 。 


Handle 通 常 是 由 HandleScopes 分 配 的 ， 璧 如 class_loader 这 个 变 


由 


StackHandleScope<3> hs(self); 
Handle<mirror::ClassLoader> class_loader(hs.NewHandle(klass-> 


我 们 首先 创建 了 一 个 StackHandleScope 变 量 ， 它 是 一 个 模板 类 ， 所 
带 的 数字 表示 所 能 容纳 和 管理 的 Handle 上 限 。 从 StackHandleScope 这 个 
名 称 可 以 推断 出 ， 它 是 一 个 局 部 的 栈 对 象 ， 因 而 不 能 通过 new 等 方式 创 
而 且 当 这 个 栈 对 象 的 生命 周期 结束 后 ， 其 所 管理 的 Handle 也 会 被 释 


Handle 具 体 是 由 NewHandle 负 责 生 成 的 ， 如 下 所 示 : 


/*art/runtime/handle_scope-inl.h*/ 
template<size_t kNumReferences> template<class T> 
inline MutableHandle<T> StackHandleScope<kNumReferences>: :NewHand 
SetReference(pos_, object); 
MutableHandle<T> h(GetHandle<T>(pos_)); 
pos_t+, 
return h; 


其 中 NewHandle 的 函数 入 人 参 是 klass->GetClassLoader () BP 
ClassLoaderk。 这 就 是 需要 通过 Handle 管 理 的 对 象 ，NewHandle 首 先 会 
调用 SetReference 来 表示 它 被 引用 了 (pos_ 是 一 个 unsigned int 值 ) 。 
紧 接着 我 们 需要 提供 一 个 容器 MutableHandle， 后 者 继承 自 Handle 类 。 
GetHandle 的 实现 并 不 复杂 ， 如 下 : 


/*art/runtime/handle_scope-inl.h*/ 

inline Handle<mirror::Object> HandleScope: :GetHandle(size_t i) { 
DCHECK_LT(i, number_of_references_); 
return Handle<mirror: :Object>(&GetReferences()[i]); 


可 见 它 是 利用 GetReferences () 来 获取 一 个 StackReference 的 指 
针 ， 然 后 供 生 成 的 Handle 来 构造 (Handle 中 有 一 个 StackReference 类 型 
的 变量 reference_) 。 这 样 一 来 Handle 中 针对 目标 的 操作 在 任何 时 候 都 
可 以 保证 是 正确 的 了 。 


有 了 这 些 背景 知识 ， 现 在 我 们 可 以 进一步 分 析 
ClassLinker: :FindClass 的 内 部 实现 了 : 





/*art/runtime/class linker.cc*/ 
mirror::Class* ClassLinker::FindClass(Thread* self, const char* d 
Handle<mirror::ClassLoader> 


mirror::Class* klass = LookupClass(descriptor, class_loader.Get 
if (klass != nullptr) { 
return EnsureResolved(self, descriptor, klass);//mMkFlClass) 


} 
if (descriptor[0] == '[') { // 情 况 2.class 还 未 加 载 ， 且 为 数组 类 的 情况 
return CreateArrayClass(self, descriptor, class_loader); 
} else if (class_loader.Get() == nullptr) {// 情 况 3， Class 是 非 数 组 
// 同 时 class loader% 
ClassPathEntry pair = FindInClassPath(descriptor, boot_class_ 
//4#% boot class 路 径 

















if (pair.second != nullptr) { 
return DefineClass(self, descriptor, hash, NullHandle<mirro 
*pair.first, *pair.second); 
} else {... 


} 
} else if (Runtime::Current()->UseCcompileTimeClassPath()){// 情 ; 


当 





} else {// 情 况 5.ClassLoader 不 为 空 的 情况 
ScopedObjectAccessUnchecked soa(self); 
mirror::Class* klass = FindClassInPathClassLoader(soa, self, 
class_loade 








if (klass != nullptr) { 
return klass; 


ScopedLocalRef<jobject> class_loader_object(soa.Env(), 
soa.AddLocalReference<jobject>(class_load 
std::string class_name_string(DescriptorToDot(descriptor ) ); 
ScopedLocalRef<jobject> result(soa.Env(), nullptr); 


ScopedThreadStateChange tsc(self, kNative); 
ScopedLocalRef<jobject> class_name_object(soa.Env(), 
soa.Env()->NewStringUTF(class_name_ 


if (class_name_object.get() == nullptr) { 
DCHECK(self->IsExceptionPending()); // OOME. 
return nullptr; 


} 
CHECK(class_loader_object.get() != nullptr); 
result.reset(soa.Env()->CallObjectMethod(class_loader_objec 
WellKnownClasses: :java_lang_Class 
class_name_object.get()) 


J 
if (self->IsExceptionPending()) {... 
} else if (result.get() == nullptr) {.. 
} else { 
// success, return mirror: :Class* 
return soa.Decode<mirror::Class*>(result.get()); 
} 
} 


FindClass 哨 数 的 目标 很 上 明确， 就 是 为 了 找到 descr iptor 所 对 应 的 
Class 实 现 ， 然 后 将 其 加 载 到 内 存 中 并 转化 为 Class 对 象 。 


首先 ，FindClass 会 通过 LookupClass 确 认 这 个 Class 是 否 已 经 被 成 
功 加 载 过 。 如 果 答 案 是 肯定 的 话 ， 直 接 从 ClassLoader 对 应 的 Class 
Table 《如 果 ClassLoader 为 空 的 话 ， 则 使 用 boot_class_table_) Pik 
回 正确 的 值 。 否 则 就 进入 情况 2 一 一 数组 类 的 判断 中 。 不 过 我 们 这 个 场 
景 下 显然 不 属于 后 面 这 种 情况 ， 因 而 可 以 直接 跳 过 这 一 步 。 


接 下 来 就 进入 非 数 组 类 的 处 理 中 了 。 又 有 如 下 几 种 可 能 性 : 
情况 3: class_loader 为 空 的 情况 


按照 双 杀 委派 的 原则 ， 此 时 可 以 调用 FindlnClassPath 在 Boot 
Class Path 中 尝试 查找 目标 对 象 。 具 体 需 要 处 理 哪 些 路 径 在 前 述 小 节 中 
对 此 已 经 有 过 详细 阐述 ， 这 里 不 再 歼 述 。 


FindlnClassPath 的 内 部 实现 并 不 复杂 ， 它 会 在 一 堆 DexFi le 中 寻找 
哪个 文件 中 包含 了 descriptor 所 描述 的 类 一 一 如 果 找 到 的 话 就 返回 一 个 
ClassPathEntry 对 象 。 当 然 ， 找 到 ClassPath 还 只 是 万 里 长 征 的 起 点 ， 
我 们 仍 需要 进一步 执行 加 载 、 实 例 化 、 初 始 化 类 对 象 等 多 个 操作 才能 真 
正 让 这 个 Class 类 变 成 可 用 状态 。Class Linker 也 提供 了 各 种 包装 函数 

(如 DefineClass) 来 完成 这 一 系列 操作 ， 后 续 我 们 再 针对 这 些 知 识 做 





详细 分 析 。 
情况 4: 编译 时 特别 指定 了 类 路 径 的 情况 


UseCompi leTimeClassPath 这 个 函数 直接 返回 
use_compile time class path 变量 值 ， 而 后 者 实际 上 与 dex2oat 的 调 
用 参数 中 是 否 含 有 “-Ximage:” 有 关 。 换 句 话 说 ， 只 有 承载 dex2oat 的 
虚拟 机 实例 才 会 有 Compile Time Class Path. 


情况 5: 即便 上 述 几 种 情况 都 无 法 找到 正确 的 类 ，FindClass 也 还 未 
到 “ 山 穷 水 尽 ” 的 地 步 。 它 会 接着 尝试 调用 
FindClasslnPathClassLoader， 而 这 个 函数 所 做 的 努力 又 分 为 两 个 方 
jo]: 


其 一 ， 寻 找 boot class path 下 的 所 有 DexFile。 


其 二 ， 寻 找 PathClassLoader 中 包含 的 DexPathList 中 的 所 有 Dex 元 


public class BaseDexClassLoader extends ClassLoader { 
private final DexPathList pathList; 


mDexPathL i st 管理 的 Dex 文 件 保 存在 其 下 的 dexElements 数 组 中 ， 
即 : 


private Element[] dexElements; 


这 样 一 来 ， 应 用 程序 自身 加 载 的 Dex 就 可 以 在 此 时 发 挥 作用 了 。 


如 果 FindClasslnPathClassLoader 依 然 没 有 收获 的 话 ， 程 序 才 会 通 
过 class_ loader 自 定义 的 loadClass 来 加 载 目 标 类 对 象 。 而 假若 这 
根 “ 最 后 的 稻草 ”人 仍然“ 一无所获” 的 话 ， 那 么 FindClass 就 只 能 返回 
空 指 针 了 ， 并 且 还 会 引发 “Class Not Found” 类 的 错误 。 


紧 接 着 我 们 再 具体 分 析 一 下 Find1nClassPath 的 内 部 实现 : 


/*art/runtime/class_linker.cc*/ 
ClassPathEntry FindInClassPath(const char* descriptor, 
size_t hash, const std::vector<const De 
{for (const DexFile* dex_file : class_path) { 


const DexFile::ClassDef* dex_class_def = dex_file->FindClassD 
if (dex_class_def != nullptr) { 
return ClassPathEntry(dex_file, dex_class_def); 


} 


return ClassPathEntry(nullptr, nullptr); 
} 


可 以 看 到 ， 这 个 函数 的 返回 值 是 ClassPathEntry， 它 其 实 是 对 
DexFi le 文件 位 置 的 一 种 描述 方式 。 查 找 过 程 也 并 不 复杂 ， 直 接 遍 历 
class_path 中 的 所 有 dex 文 件 就 可 以 了 。 其 中 最 关键 的 还 是 
FindClassDef 这 个 水 数 : 


/*art/runtime/dex_file.cc*/ 
const DexFile::ClassDef* DexFile::FindClassDef(const char* descri 
DCHECK_EQ(ComputeModifiedUtf8Hash(descriptor), hash); 
// If we have an index lookup the descriptor via that as its co 
Index* index = class_def_index_.LoadSequentiallyConsistent()j; 
if (index != nullptr) { 
auto it = index->FindwWithHash(descriptor, hash); 
return (it == index->end()) ? nullptr : it->second; 


// Fast path for rate no class defs case. 
uint32_t num_class_defs = NumClassDefs(); 
if (num_class_defs == 0) { 

return nullptr; 


// Search for class def with 2 binary searches and then a linea 
const StringId* string_id = FindStringId(descriptor); 
if (string_id != nullptr) { 
const TypeId* type_id = FindTypeId(GetIndexForStringId(*strin 
if (type_id != nullptr) { 
uinti6_t type_idx = GetIndexForTypeld(*type_id); 
for (size_t i = 0; i < num_class_defs; ++i) { 
const ClassDef& class_def = GetClassDef(i); 
if (class_def.class_idx_ == type_idx) { 
return &class_def; 


大 家 还 记得 我 们 前 面 小 节 分 析 过 的 DexF i le 文件 格式 吗 ? ERY 
Header 中 有 一 个 成 员 变 量 class defs size 专门 用 于 指示 当前 DexFile 


中 包含 的 Class 的 数量 ; 而 另 一 个 成 员 变 量 class_defs_off_ 则 指向 用 于 
描 述 名 个 Glass 具 体 信息 的 数组 。 


这 样 一 来 ， 查 找 某 Class 是 否 存 在 于 DexFi haaba 不 过 
FindClassDef 函 数 中 很 大 一 部 分 比重 的 代码 其 实 是 为 了 让 整个 查找 过 程 
更 加 高 效 ， 有 兴趣 的 读者 可 以 自行 分 析 一 下 。 而 我 们 最 关心 的 是 查 技 过 
程 是 如 何 执行 的 ， 这 部 分 涉及 的 核心 语句 如 下 : 


for (size_t i = 0; i < num_class_defs; ++i) { 
const ClassDef& class_def = GetClassDef(i); 
if (class_def.class_idx_ == type_idx) { 
return &class_def; 
} 
Í 


其 中 num_class_defs 得 到 的 就 是 class_ defs_size ， 
GetClassDef (i) 对 应 的 是 class_defs_[idx] ， 而 且 这 个 数组 实际 上 就 是 
通过 class_defs_off_ 偏 移 量 得 到 的 。 还 需要 特别 注意 的 是 type_idx 这 
个 变量 ， 它 的 数据 类 型 是 uint16 t (Bunsigned int) 。 从 字面 意思 上 
理解 代表 的 是 Class 的 “序号 ”， 那 么 它 具 体 又 是 如 何 被 计算 出 来 的 
E? 答案 在 于 下 面 这 3 个 语句 中 : 


onst StringId* string_id = FindStringId(descriptor); 
const TypeId* type_id = FindTypeId(GetIndexForStringId(*string_id 
uinti6_t type_idx = GetIndexForTypelId(*type_id); 


descriptor 在 我 们 这 个 场景 中 对 应 的 是 
com/android/internal/os/Zygotelnit。FindStringld 实 际 上 是 去 查找 
DexFile 中 偏 移 量 为 string ids off 的 一 个 String1d 数 组 中 descr iptor 
所 对 应 的 数组 项 。String1d 这 个 结构 体 中 的 string_data_off_ 指 向 的 是 
一 个 String 字 符 串 ， 这 样 就 可 以 与 descr iptor 进 行 字 符 串 匹配 了 。 
Get1ndexForString1d 得 到 的 是 deser iptor 在 String1d 数 组 中 的 具体 序 
号 〈 这 里 获取 序号 的 方式 比较 奇怪 ) 。FindType1d 得 到 与 String1d 对 应 
的 Type1d， 而 GetlndexForType1d 则 是 Type1d 在 type ids 数组 中 的 序 
号 。 


得 到 正确 的 ClassDef 后 ， 接 下 来 就 可 以 构建 ClassPathEntry 了 ， 
Mee Hd ne DexFile*, const 
DexFile: :ClassDef*>AY typedef. 


过 工作 还 没有 完成 ， 这 一 点 从 Class 的 状态 表 中 也 可 以 看 出 来 : 


/*art/runtime/mirror/Class.h*/ 

enum Status { 
kStatusRetired = -2, // Retired, should not be used. Use the 
kStatusError = -1, 
kStatusNotReady = 0, 
kStatusIdx = 1, // Loaded, DEX idx in super_class_type_idx 
kStatusLoaded = 2, // DEX idx values resolved. 
kStatusResolving = 3, // Just cloned from temporary class ob 
kStatusResolved = 4, // Part of linking. 
kStatusVerifying = 5, // In the process of being verified. 
kStatusRetryVerificationAtRuntime = 6, // Compile time verif 
kStatusVerifyingAtRuntime = 7, // Retrying verification at r 
kStatusVerified = 8, // Logically part of linking; done pre- 
kStatusInitializing = 9, // Class init in progress. 
kStatusInitialized = 10, // Ready to go. 
kStatusMax = 11, 





}; 


kStatusNotReady :如 果 FindClass 无 法 查找 到 目标 类 ， 那 么 我 们 需 
要 分 配 一 个 Class 对 象 ， 并 将 状态 迁移 到 kStatusNotReady。 


kStatusldx: 紧 接 着 我 们 从 DexF i le 中 读 取 Class 信 息 ， 用 于 填充 上 
述 的 Class 对 象 ， 并 将 状态 迁移 到 kStatus1dx (表明 super_class 还 未 
填充 ) ， 而 且 此 时 的 Class 可 以 被 插入 ClassTable 中 


kStatusLoaded: 如 果 获 取 Class 锁 成 功 ， 我 们 就 可 以 调用 
ResolveClass 来 将 状态 迁移 到 kStatusLoaded 了 (此 时 super_class 已 
经 处 理 ) 

kStatusResolved: 此 状态 表明 1inking 已 经 完成 。 


上 述 各 状态 数值 的 大 小 就 代表 了 它们 在 状态 机 中 的 变迁 逻辑 ， 其 中 
核心 的 几 个 状态 变迁 关系 如 图 21-66 所 示 。 
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所 以 说 查找 到 目标 对 象 只 是 第 一 步 ， 我 们 还 得 经 历 上 述 的 核心 状态 
迁移 才能 最 终 让 Class 达 到 可 用 状态 ， 这 些 工 作 大 多 是 在 Def ineClass 
完成 的 : 


/*art/runtime/class_linker.cc*/ 
mirror::Class* ClassLinker: :DefineClass(Thread* self, 
const char* descriptor, 
size_t hash, 
Handle<mirror::ClassLoader> cla 
const DexFile& dex_file, 
const DexFile::ClassDef& dex_cl 
StackHandleScope<3> hs(self); 
auto klass = hs.NewHandle<mirror::Class>(nullptr); 


if (klass.Get() == nullptr) { 
// 分 配 一 个 Class 空 间 ， 并 将 状态 迁移 到 kStatusNotReady 
klass.Assign(AllocClass(self, SizeOfClasswithoutEmbeddedTable 
dex_class_def))); 
} 


mirror::DexCache* dex_cache = RegisterDexFile(dex file, 
GetOrCreateAllocatorForClassLoader(class_loader.Get())); 


klass->SetDexCache(dex_cache); 
SetupClass(dex_file, dex_class_def, klass, class_loader.Get()); 


// Mark the string class by setting its access flag. 
if (UNLIKELY(!init_done_)) { 
if (strcmp(descriptor, "Ljava/lang/String;") == 0) { 
klass->SetStringClass(); 
} 


t 


ObjectLock<mirror::Class> lock(self, klass); 
klass->SetClinitThreadId(self->GetTid()); 


// Add the newly loaded class to the loaded classes table. 
mirror::Class* existing = InsertClass(descriptor, klass.Get(), 
if (existing != nullptr) {//Table 中 己 经 存在 此 Class 

return EnsureResolved(self, descriptor, existing); 


LoadClass(self, dex_file, dex class def, klass); 
auto interfaces = hs.NewHandle<mirror: :ObjectArray<mirror::Clas 


MutableHandle<mirror::Class> h_new_class = hs.NewHandle<mirror: 
if (!LinkClass(self, descriptor, klass, interfaces, &h_new_clas 
// Linking failed. 
if (!klass->IsErroneous()) { 
mirror::Class::SetStatus(klass, mirror::Class::kStatusError 
} 


return nullptr; 


} 
} 


return h_new_class.Get(); 


这 个 函数 很 长 ， 核 心 的 操作 由 Al locClass, SetDexCache, 
SetupClass, InsertClass, Ensure Resolved、LoadClass 和 LinkClass 


等 组 成 。 


其 中 Allocclass 即 “Allocate Class”， 它 负责 申请 Class 对 象 所 
需 的 内 存 空 siā], 而 且 这 块 内 存 是 从 Runtime::Current () ->GetHeap () 中 
获得 的 一 一 这 样 一 来 就 将 它 纳入 6GC 的 统一 管理 中 了 。 需 要 分 配 的 空间 大 
小 由 Size0fClassWithoutEmbeddedTables 计 算得 到 ， 有 兴趣 的 读者 可 以 
自行 分 析 其 中 的 实现 细节 。 


SetupClass 简 单 来 讲 用 于 对 Class 对 象 进行 初 始 化 。lnsertClass 则 
abate 欠 已 经 加 载 的 Class 保 存 到 一 个 已 加 载 列表 中 ， 这 样 后 续 如 果 
次 使 用 时 就 不 需要 再 “大 费 周章 ”了 。 根 据 这 个 函数 的 返回 值 可 以 判 
村 已 经 存在 一 一 正常 情况 下 返回 值 是 nul lptr， 但 
也 有 特例 : 譬如 其 他 线程 也 在 尝试 做 同一 个 Class 的 插入 操作 ， 而 且 比 


我 们 先行 完成 了 。 当 然 ， 这 种 情况 下 我 们 还 需要 调用 EnsureResolved 来 
确保 Class 得 到 正确 的 解析 处 理 。 


LoadClass 是 将 AI locC1ass 申 请 的 衬 s 旧 真正 填 满 内 容 (成 员 变 量 、 
ARMS) 的 一 个 函数 ， 这 也 是 后 面 Class 中 的 函数 能 被 正确 执行 的 
关键 所 在 。 代 码 实现 如 下 : 


/*art/runtime/class_linker.cc*/ 
void ClassLinker::LoadClass(Thread* self, const DexFile& dex_file 
const DexFile::ClassDef& dex_class_def, 
Handle<mirror::Class> klass) { 
const uint8_t* class_data = dex_file.GetClassData(dex_class_def 
if (class_data == nullptr) { 
return; // no fields or methods - for example a marker inter 


bool has_oat_class = false; 
if (Runtime: :Current()->IsStarted() && !Runtime::Current()->IsA 
OatFile::OatClass oat_class = FindOatClass(dex_file, klass->G 
&has_oat_class); 
if (has_oat_class) { 
LoadClassMembers(self, dex_file, class_data, klass, &oat_cl 


} 


if (!has_oat_class) { 
LoadClassMembers(self, dex_file, class_data, klass, nullptr); 


} 
} 


首先 我 们 需要 从 DexFi1e 中 找到 C1ass 数 据 〈 每 个 Class 数 据 由 
class_data_item 构 成 ) 所 在 位 置 ， 这 个 偏 移 量 保存 在 class_data _off_ 
中 。 。 假 如 这 个 值 为 空 的 话 ， 代 表 当 前 的 类 并 没有 包含 任何 成 员 函 数 和 成 
员 变 量 ， 因 而 流程 可 以 直接 结束 。 紧 接着 查找 这 个 Dex Class 所 对 应 的 
0atClass， 判 断 规则 是 它们 的 index 值 是 否 一 致 。 具 体 来 说 ， 我 们 需要 
调用 klass- >GetDexClassDeflndex 来 得 到 Dex Class 的 序号 ， 然 后 利用 
Find0atClass 来 获得 0at _ Class 对象。 当然 ， 执 行 这 种 对 应 关系 的 前 提 
是 Runtime 已 经 启动， 并 且 1sAotComp iler 的 返回 值 是 fal se 一 一 即 非 AOT 
编译 器 的 情况 。 什 么 意思 呢 ? 就 是 指 当 前 的 进程 首先 不 能 是 一 
Compiler (或 者 说 当前 进程 不 是 dex2oat) ， 而 且 没 有 使 用 JIT 在 做 编 
译 。 所 以 对 于 一 般 的 Androi d 程 序 来 说 都 会 执行 这 个 代码 分 支 。 


不 管 有 没有 0at Class, 程序 都 会 调用 LoadClassMembers。 我 们 来 看 
一 下 这 个 函数 的 内 部 实现 : 


/*art/runtime/class_linker.cc*/ 

void ClassLinker::LoadClassMembers(Thread* self, const DexFile& d 
const uint8_t* class_data, 
Handle<mirror::Class> klass, 
const OatFile::OatClass* oat_class) 


ClassDataItemIterator it(dex_file, class_data); 
// 加 载 静态 成 员 变 量 
const size_t num_sfields = it.NumStaticFields(); 
ArtField* sfields = num_sfields != 0 ? 
AllocArtFieldArray(self, num_sfi 
for (size_t i = 0; it.HasNextStaticField(); i++, it.Next()) { 
CHECK_LT(i, num_sfields); 
LoadField(it, klass, &sfields[i]); 
} 
klass->SetSFields(sfields); 
klass->SetNumStaticFields(num_sfields); 
DCHECK_EQ(klass->NumStaticFields(), num_sfields); 
// 加 载 普通 成 员 变 量 
const size_t num_ifields = it.NumInstanceFields(); 
ArtField* ifields = num_ifields != 0 ? 
AllocArtFieldArray(self, num_ifield 
for (size_t i = 0; it.HasNextInstanceField(); i++, it.Next()) 
CHECK_LT(i, num_ifields); 
LoadField(it, klass, &ifields[i]); 


























} 

klass->SetIFields(ifields); 

klass->SetNumInstanceFields(num_ifields); 

DCHECK_EQ(klass->NumInstanceFields(), num_ifields); 

// 加 载 成 员 函 数 ， 根 据 函 数 类 型 的 不 同 ， 加 载 方式 也 会 有 区 别 

if (it.NumDirectMethods() != 0) {//static、private 等 类 型 的 函数 
klass->SetDirectMethodsPtr(AllocArtMethodArray(self, it.Num 





} 

klass->SetNumDirectMethods(it.NumDirectMethods());//Direct Me 

if (it.NumVirtualMethods() != 0) {// 加 载 虚 函数 
klass->SetVirtualMethodsPtr(AllocArtMethodArray(self,it.Num 








} 
klass->SetNumVirtualMethods(it.NumVirtualMethods());// 虚 水 数 数 ] 
size_t class def method index = 0; 
uint32_t last_dex_method_index = DexFile: :kDexNoIndex; 
size_t last_class_def_method_index = 0; 
for (size_t i = 0; it.HasNextDirectMethod(); i++, it.Next()) 
ArtMethod* method = klass->GetDirectMethodUnchecked(i, imag 
LoadMethod(self, dex_file, it, klass, method); 
LinkCode(method, oat_class, class_def_method_index); 
uint32_t it_method_index = it.GetMemberIndex(); 
if (last_dex_method_index == it_method_index) { 
// duplicate case 


method->SetMethodIndex(last_class_def_method_index); 
} else { 
method->SetMethodIndex(class_def_method_index) ; 
last_dex_method_index = it_method_index; 
last_class_def_method_index = class_def_method_index; 


class_def_method_index++; 


} 
for (size_t i = 0; it.HasNextVirtualMethod(); i++, it.Next()) 


ArtMethod* method = klass->GetVirtualMethodUnchecked(i, ima 
LoadMethod(self, dex_file, it, klass, method); 
DCHECK_EQ(class_def_method_index, it.NumDirectMethods() + i 
LinkCode(method, oat_class, class_def_method_index); 
class_def_method_index++; 


} 
DCHECK( !it.HasNext()); 


self->AllowThreadSuspension(); 


i 


k 


LoadMembers 可 以 分 为 3 个 部 分 ， 分 别 负责 加 载 静态 成 员 变 量 、 普 通 
成 员 变 量 和 成 员 函 数 。 aaa Peat ash Ui 个 1terator, 它 的 每 
一 项 都 对 应 一 个 class data item。NumStaticFields 返 回 的 是 当前 
Class 中 静态 变量 的 数量 ， 它 是 在 如 下 构造 男 数 中 赋值 的 : 


ClassDataItemIterator(const DexFile& dex_file, const uint8_t* r 
: dex_file_(dex_file), pos_(0), ptr_pos_(raw_class_data_ite 
ReadClassDataHeader ( ); 
if (EndOfInstanceFieldsPos() > 0) { 
ReadClassDataField(); 
} else if (EndOfVirtualMethodsPos() > 0) { 
ReadClassDataMethod(); 








ReadClassDataHeader 将 从 ptr _ pos ， 即 raw_class_data_item 所 指 
向 的 区 域 中 读 取 变 量 和 羡 数 的 数量 ， 并 保存 到 header_ 中。 对 于 加 载 到 
的 所 有 信息 ， 都 将 通过 kclass 这 个 变量 进行 保存 ， 以 便 后 面 的 代码 执行 
可 以 顺利 进行 。 


我 们 再 回 到 DefineClass 函 数 的 分 析 中 。LoadClass 之 后 还 剩 最 后 一 
步 操作 ， 即 LinkClass。 它 也 是 ClassLinker 的 意义 所 在 一 一 建立 各 个 
Class 之 间 的 关联 。 比 如 父子 类 之 间 是 如 何 重 载 的 ， 实 现 多 态 性 的 
VTable 和 1Table 应 该 怎么 处 理 等 。 


以 LinkClass 中 的 LinkMethods 为 例 ， 它 a ee 性 
的 实现 。 多 态 允 许 程序 在 运行 中 再 绑 定 具体 的 函数 ， 给 程序 这 来 了 很 多 
灵活 性 和 便利 性 。 多 态 的 具体 实现 虽然 与 编译 器 有 关联 ， 但 是 它们 的 基 
本 原理 都 是 类 似 的 。 当 我 们 在 Class 中 定义 一 个 虚 函 数 〈 严 格 来 讲 ， 
Java 没 有 虚 函 数 的 概念 ， 或 者 说 函数 默认 就 具有 虚 函 数 的 行为 ) 的 时 
候 ，Compi1er 会 为 它 添 加 一 个 隐藏 的 成 员 变 量 ， 而 后 者 会 指向 一 个 函数 
外 针 数组 。 这 个 数组 就 是 被 大 家 所 熟知 的 VTable (Virtual Method 
Table) ， 它 包含 的 各 个 指针 的 具体 值 需要 在 运行 时 才能 得 到 最 终 确 
AE: 
bool ClassLinker::LinkMethods(Thread* self, 
Handle<mirror::Class> klass, 
Handle<mirror: :ObjectArray<mirror::Class 
ArtMethod** out_imt) { 
self->AllowThreadSuspension(); 
return SetupInterfaceLookupTable(self, klass, interfaces) 


&& LinkVirtualMethods(self, klass, /*out*/ &default_tra 
&& LinkInterfaceMethods(self, klass, default_translatio 


LinkMethods 的 处 理 主要 分 为 两 个 步骤 : 其 一 是 先 链接 虚 函 数 ， 然 
后 再 链接 接口 中 的 函数 。 链 接 的 本 质 就 是 把 对 水 数 的 索引 号 引用 变 成 真 
正 的 目的 地 址 ， 以 便 程序 的 正确 执行 。 


LinkVirtualMethods 用 于 对 虚 函 数 进行 处 理 ， 它 在 执行 逻辑 上 会 分 
为 两 个 部 分 “〈 分 别 对 应 函数 实现 中 的 if 和 else 两 个 分 支 ) 一 一 即 当前 类 
是 否 有 自己 的 SuperClass。 我 们 知道 ，Java 语 言 中 只 有 “最 顶端 ”的 
0bject 才 允许 没有 父 类 ， 因 而 对 绝 大 多 数 的 类 来 说 ， 它 们 都 会 走 前 半 部 
分 的 分 支 。 这 种 情况 下 ， 当 前 类 的 VTable 首 先是 从 父 类 获取 到 的 ， 然 后 
以 此 为 基础 进行 “改造 ”。 


VTable 在 代码 实现 中 采用 的 是 mirror: :PointerArray 数 据 结构 。 这 
个 Array 的 最 大 值 是 num virtual _methods + super_vtable_length, 也 
就 是 父 类 中 已 有 的 数组 大 小 加 上 类 自身 的 虚 函 数 个 数 。 我 们 给 VTab le 分 
配 的 空间 大 小 CAllocPointerArray) 也 是 以 这 个 数 为 基准 的 。VTable 
的 初始 化 也 很 简单 ， 就 是 将 Super Class 中 的 各 个 entry 复 制 到 VTable 中 
来 。 而 且 如 果 num_virtual_methods 为 0， 说 明 这 个 洱 数 并 不 需要 再 做 其 
他 额外 工作 ， 那 么 这 种 情况 下 函数 可 以 直接 结束 返回 。 


VTable 完 成 初始 化 后 ， 接 下 来 就 需要 处 理 当前 类 中 的 情况 了 。 我 们 


可 以 来 思考 一 下 ， 如 何 分 步骤 来 完成 对 VTable 的 改造 呢 ? SmE 
是 两 个 原则 : 


e 查询 Super Class 的 VITable 是 否 有 被 这 个 类 ovettide 的 函数 ; 
e 对 于 那些 与 父 类 没有 直接 关系 的 新 函数 ， 添 加 到 VTable 的 末尾 。 


LinkVirtualMethods 的 核心 处 理 流程 也 是 遵照 上 面 这 两 点 展开 的 ， 
只 不 过 出 于 性 能 等 因素 的 考虑 ， 它 还 加 入 了 很 多 其 他 改进 措施 。 有 兴趣 
的 读者 可 以 自行 阅读 代码 了 解 。 

理解 了 VTable 的 处 理 过 程 后 ， 我 们 再 来 进一步 分 析 IfTable。 相 信 
很 多 读者 会 有 这 样 的 疑问 ， 既 然 已 经 有 了 VTable, 为 什么 还 需要 1fTable 
呢 ? 


IfTable 从 字面 上 很 容易 理解 ， 是 指 Interface Table， 它 对 应 的 代 
但 实现 是 : 


HeapReference<IfTable> iftable_; 
而 IfTable 数 据 结构 定义 如 下 : 

Class MANAGED IfTable FINAL : public ObjectArray<Object> {... 
简单 来 说 ，1ftable 是 多 个 Interface 和 其 对 应 的 method 列 表 的 集 


根据 Java 语 言 的 规定 ， 一 个 Class 虽 然 只 能 继承 自 (extends) 一 个 
类 ， 但 却 可 以 实现 (implements) 多 个 接口 。 如 图 21-67 所 示 。 


<<>> <<>> 
Interfacel Interface? 


tInterfacel Method! () tnterface2 Method! 


+Interfacel Method? () Interface? Method? () 





全 图 21-07 Java 类 的 继承 与 实现 
这 一 点 我 们 从 两 个 Table 的 定义 对 比 也 可 以 霸 见 一 二 : 


HeapReference<IfTable> iftable_; 
HeapReference<PointerArray> vtable_; 


其 中 1fTable 继 承 自 0b jectArray<Ob ject>: 


Class MANAGED IfTable FINAL : public ObjectArray<Object> { 


所 以 说 VTable 只 解决 类 的 extends 关 系 ， 而 不 负责 类 的 implements 
关系 ， 后 者 的 实现 就 交 由 1fTable 来 完成 了 。 


这 样 一 来 ，FindClass 的 整个 实现 过 程 就 分 析 完 成 了 。 


得 到 Class 对 象 之 后 ， 下 一 步 需要 理解 的 是 怎么 执行 Class 类 中 的 函 
数 。 为 了 便于 大 家 阅读 ， 我 们 再 将 start 函 数 中 的 相关 代码 摘 取 如 下 : 


jclass startClass = env->FindClass(slashClassName) ; 
if (startClass == NULL) { 
ALOGE("JavaVM unable to locate class '%s'\n", slashClassN 
/* keep going */ 
} else { 
jmethodID startMeth = env->GetStaticMethodID(startClass, 
"(ELjava/lang/String; )V"); 
if (startMeth == NULL) { 
ALOGE("JavaVM unable to find main() in '%s'\n", class 
/* keep going */ 
} else { 
env->CallStaticVoidMethod(startClass, startMeth, strA 
} 


} 


Zygote 希 望 AndroidRuntime 启 动 的 Class 类 是 
com. android. internal. os. Zygotelnit, ADAM “main” . Am 
AndroidRuntime: :start 首 先 通 过 GetStaticMethod1D 来 从 上 述 加 载 的 
startClass 中 获得 main 国 数 的 jmethod1D。 这 个 1D 值 是 后 续 main 印 数 能 
得 到 顺利 运行 的 前 提 条 件 〈 它 实际 上 是 一 个 _jmethod1D 指 针 ) 。 
GetStaticMethod1D 的 源码 实现 在 jni_internal. cc 中 ， 如 下 所 示 : 


/*art/runtime/jni_internal.cc*/ 
static jmethodID GetStaticMethodID(JNIEnv* env, jclass java_cla 
const char* sig) { 
CHECK_NON_NULL_ARGUMENT(java_class); 
CHECK_NON_NULL_ARGUMENT (name) ; 
CHECK_NON_NULL_ARGUMENT(sig); 
ScopedObjectAccess soa(env); 
return FindMethodID(soa, java_class, name, sig, true); 











CHECK_NON_NULL_ARGUMENTA A THREBAR AS, AAAH 
结束 并 返回 nul1。 可 见 起 主要 作用 的 是 最 后 的 FindMethod1D: 


/*art/runtime/jni_internal.cc*/ 
static jmethodID FindMethodID(ScopedObjectAccess& soa, jclass jni 
const char* name, const char* sig, bool i 
SHARED_LOCKS_REQUIRED(Locks::mutator_lock_) { 
mirror::Class* c = EnsureInitialized(soa.Self(), 
soa.Decode<mirror: :Class*>(jni_cla 


ArtMethod* method 
auto pointer_size 
if (is_static) { 
method = c->FindDirectMethod(name, sig, pointer_size); 
} else if (c->IsInterface()) { 
method = c->FindInterfaceMethod(name, sig, pointer_size); 
} else { 
method = c->FindVirtualMethod(name, sig, pointer_size); 


p 


return soa.EncodeMethod(method); 


nullptr; 
Runtime: :Current()->GetClassLinker()->GetIm 


这 个 函数 的 目标 是 根据 参数 name 来 查找 到 正确 的 method1D。 在 我 们 
这 个 场景 中 ，name 对 应 的 是 “main”， 而 且 is_static 等 于 true (AW 
main 是 静态 函数 ) 。 换 句 话 说 ， 上 述 代 码 段 中 真正 调用 的 实现 函数 是 
FindDirectMethod: 


/*art/runtime/mirror/Class.cc*/ 
ArtMethod* Class::FindDirectMethod(const StringPiece& name, 
const StringPiece& signature, size 
for (Class* klass = this; klass != nullptr; klass = klass->GetS 
ArtMethod* method = klass->FindDeclaredDirectMethod(name, sig 
pointer_size) 


if (method != nullptr) { 
return method; 
} 


} 


return nullptr; 


} 


查找 Direct Method 的 过 程 并 不 复杂 ， 就 是 按照 继承 关系 不 断 搜 
寻 。FindDeclaredDirectMethod 最 终 是 通过 Class 中 的 direct methods_ 
数组 来 找到 所 需 的 ArtMethod 的 ， 其 中 signature 代 表 函 数 的 原型 一 一 例 
如 main 了 水 数 对 应 的 是 “([Ljava/1lang/String:]V” id 
量 direct methods 是 Class Linker 为 目标 class 加 载 数据 时 赋值 的 ， 具 具 
体 而 言 是 在 LoadClassMembers 中 调用 SetDi rectMethodsPtr 实 现 的 。 建 
议 大 家 可 以 和 前 面 介绍 的 内 容 结 合 起 来 分 析 ， 相 信 会 有 更 深刻 的 理解 。 


找到 的 ArtMethod 指 针 会 通过 jmethod1D 数 据 结 构 包 装 后 再 返回 给 
GetStaticMethod1D， 进 而 为 startMeth 赋 值 。JN1 中 自 定义 了 不 少 类 似 
于 jmethod1D 的 数据 结构 (如 jfieldlD、jobject、jclass 等 ) ， 它 们 大 
多 数 是 对 基础 数据 类 型 的 typedef 〈 如 voidk) 。 那么 jmethod1D 只 是 对 
ArtMethod* 简 单 的 强制 类 型 转换 吗 ? 我 们 发 现 FindMethod1D 最 后 return 
的 是 EncodeMethod (method) 。 它 和 另 一 个 配套 的 DecodeMethod 的 声明 
如 下 : 


jmethodID EncodeMethod(mirror::ArtMethod* method) const; 
mirror::ArtMethod* DecodeMethod(jmethodID mid) const; 


也 就 是 说 ，“ 编 解码 ”之 间 的 关系 如 下 : 
Encode: ArtMethod->jmethodID; Decode: jmethodID->ArtMethod 


获取 到 Method 1d 后 ， 接 下 来 就 要 考虑 如 何 才 能 真正 地 执行 这 个 通 
数 。 在 我 们 这 个 场景 下 ， 运 行 main 函 数 所 使 用 的 JN1 接 口 是 
Cal1StaticVoidMethod: 





/*art/runtime/jni_internal.cc*/ 
static void CallStaticVoidMethod(JNIEnv* env, jclass, jmethodID 
va_list ap; 
va_start(ap, mid); 
CHECK_NON_NULL_ARGUMENT_RETURN_VOID(mid); 
ScopedObjectAccess soa(env); 
InvokewithVarArgs(soa, nullptr, mid, ap); 
va_end(ap); 





AAR ERITH eM SSAA, HA PHEMLES TBE 
的 ， 所 以 Cal1StaticVoid Method 采 用 的 是 不 定 参 的 格式 。 如 果 大 家 对 
这 种 类 型 的 函数 感到 陌生 的 话 ， 建 议 可 以 先 自行 查阅 相关 资料 了 解 详 


情 : 


/*art/runtime/reflection.cc*/ 
JValue InvokeWithVarArgs(const ScopedObjectAccessAlreadyRunnable& 
SHARED_LOCKS_REQUIRED(Locks::mutator_lock_) { 


mirror: :ArtMethod* method = soa.DecodeMethod(mid) ; 

mirror: :Object* receiver = method->IsStatic() ? nullptr : 
soa.Decode<mirror: :Ob 

uint32_t shorty_len = 0; 

const char* shorty = method->GetShorty(&shorty_len); 

JValue result; 

ArgArray arg_array(shorty, shorty_len); 

arg_array.BuildArgArrayFromvVarArgs(soa, receiver, args); 

InvokewithArgArray(soa, method, &arg_array, &result, shorty); 

return result; 


因为 传 入 的 参数 是 jmethod1D， 所 以 需要 先 通过 DecodeMethod 把 它 
转 成 正确 的 ArtMethod。 我 们 知道 ， 函 数 如 果 是 静态 的 〈1sStatic) 
话 ， 那 么 可 以 不 需要 实例 化 就 直接 调用 ; 反之 就 要 指定 它 所 对 应 的 对 象 
在 上 述 代码 段 中 指 的 是 receiver， 它 是 由 obj 这 个 参数 Decode 而 来 
Be egy a ge i ae 
定位 。 


一 切 准备 融 绪 以 后 ， 开 始 调用 InvokeWithArgArray， 而 后 者 又 会 进 
一 步调 用 ArtMethod : Invoke: 





/*art/runtime/art_method.cc*/ 
void ArtMethod: :Invoke(Thread* self, uint32_t* args, uint32_t arg 
JValue* result, const char* 


ManagedStack fragment; 
self ->PushManagedStackFragment(&fragment ) ; 
Runtime* runtime = Runtime::Current();// 注 意 ，Runtime 实 例 是 进程 唯 - 
if (UNLIKELY(!runtime->IsStarted() || Dbg::IsForcedInterpreterN 
this))) {...// 当 前 Runtime 还 未 启动 ， 或 者 当前 是 调试 模式 下 ， 那 么 需要 使 用 interp 
} else {..// 不 需要 解释 器 ， 直 接 执行 函数 对 应 的 Native Code 
bool have_quick_code = GetEntryPointFromQuickCompiledCode() ! 











if (LIKELY(have_quick_code)) {... 
if (!IsStatic()) { 
(*art_quick_invoke_stub)(this, args, args_size, self, res 
} else { 
(*art_quick_invoke_static_stub)(this, args, args_size, se 





Jelse {..// 函 数 没有 找到 对 应 的 Native Code， 报 错 
} 


// Pop transition. 
self ->PopManagedStackFragment (fragment ) ; 
} 


_ArtMethod: : Invoke 是 虚拟 机 中 最 关键 的 函数 之 一 ， 它 有 点 类 似 于 
目标 函数 执行 之 前 的 “分 发 器 ”。 这 个 函数 很 长 ， 上 述 代 码 段 是 其 中 的 
核心 实现 。 


它 的 处 理 逻 辑 如 下 : 
e !runtime->IsStarted() | | Dbg::I[sForcedInterpreterNeededForCalling 


如 果 runtime 还 没有 局 动 完成 ， 或 者 当前 处 于 debug 状 态 〈 这 是 因为 
调试 程序 时 有 可 能 需要 单 步 执行 或 者 Step into 到 函数 内 部 ， 必 须 使 用 
Interpreter 才 能 完成 ) ， 那 么 就 走 interpreter 这 个 分 支 。 
Interpreter 代 表 当 前 的 函数 由 “解释 器 ”来 执行 字 节 码 ， 而 不 是 直接 
调用 通过 dex2oat 转 化 成 的 本 地 机 器 代码 。 


e 非 interpreter 的 情况 


大 部 分 情况 下 ， 我 们 都 可 以 直接 执行 已 经 被 预先 编译 好 的 机 器 码 ， 
这 也 是 保证 Art 虚 拟 机 性 能 相 较 于 Dalvik 有 较 大 幅度 提升 的 基础 条 件 之 


e 对 于 atm、i386 等 硬件 平台 架构 ，invoke 将 利用 art_quick_invoke_stub 
或 者 att_quiick invoke_static_stub (静态 函数 的 情况 ) 来 运行 目标 了 
数 。 不 过 这 两 个 函数 都 只 是 做 了 一 下 简单 的 中 转 ， 它 们 会 进一步 调 
用 gquick_invoke_reg_setup 来 完成 任务 : 


/*art/runtime/arch/arm/quick_entrypoints_cc_arm.cc*/ 
template <bool kIsStatic> 


static void quick_invoke_reg_setup(ArtMethod* method, uint32_t* a 
uint32_t core_reg_args[4]; // r0 ~ r3 
uint32_t fp_reg_args[16]; // sO ~ s15 (dO ~ d7) 
uint32_t gpr_index = 1; // Index into core registers. Reserve 
uint32_t fpr_index = ©; // Index into float registers. 
uint32_t fpr_double_index = 0; // Index into float registers f 
uint32_t arg_index = 0; // Index into argument array. 
const uint32_t result_in_float = kArm32QuickCodeUseSoftFloat ? 

(shorty[0] == 'F' || shorty[0] == 'D') ? 1 : 0;// 结 果 值 是 否 涉 








if (!kIsStatic) { 
core_reg_args[gpr_index++] = args[arg_index++]; 


for (uint32_t shorty_index = 1; shorty[shorty_index] != '\O'; + 
char arg_type = shorty[shorty_index]; 
if (kArm32QuickCodeUseSoftFloat) { 


arg_type = (arg_type == 'D') ? 'J' : arg_type; // Regard d 
arg_type = (arg_type == 'F') ? 'I' : arg_type; // Regard f 
} 
switch (arg_type) { 
case 'D!': {.. 
} 
case 'F': 
case ng 
default: 
if (gpr_index < arraysize(core_reg_args)) { 
core_reg_args[gpr_index++] = args[arg_index]; 
} 
break; 
} 


} 
art_quick_invoke_stub_internal(method, args, args_size, self, r 
result_in_float, core_reg_args, 


上 述 这 个 函数 的 作用 是 为 后 续 执 行 汇编 代码 准备 好 各 种 寄存 器 参数 
〈 它 的 函数 名 也 很 好 地 诠释 了 这 一 点 ) ， 并 将 结果 保存 在 
core reg args 和 fp_reg args 中。 其 中 core_reg args 负责 处 理 通用 功 
能 部 分 ， 而 fp_reg_args 属 于 特殊 寄存 器 ， 专 门 用 于 浮 点 数 运算 。 浮 点 
数 在 计算 机 中 用 于 近似 表示 一 个 实数 ， 由 尾数 、 阶 码 和 阶 码 的 基数 组 
成 。1EEE754 标 准 对 浮 点 数 的 运算 有 严格 规定 ， 有 兴趣 的 读者 可 以 自行 
查阅 学 习 。 我 们 这 里 只 需要 知道 符 点 数 运算 需要 特殊 寄存 器 的 支持 就 可 


以 了 。 


我 们 在 前 面 小 节 专 门 讲解 过 AAPCS 一 一 需要 特别 指出 的 是 ，Art 虚 拟 
机 在 调用 汇编 代码 时 并 没有 严格 遵循 AAPCS 规 则 。 这 一 点 从 invoke 函 数 
的 处 理 流 程 中 也 可 以 看 出 来 。 在 qui ck_invoke_reg_setup 的 实现 中 ， 
core_reg_args 数 组 大 小 为 4， 分 别 对 应 r0-r3 这 几 个 通用 寄存 器 ; 
fp_reg_args 大 小 为 16， 对 应 的 是 s0-s15。 另 外 ，gpr_index、 
fpr_index 和 fpr_double_index 是 数组 中 的 序号 。 另 外 ， 除 了 gpr_index 
需要 预 留 r0 给 ArtMethod 指 针 所 以 初始 值 为 1 外 ， 其 他 数组 的 index 都 是 
从 0 开始 计算 的 。 


总 体 来 说 ， 各 主要 寄存 器 的 作用 如 表 21-12 所 示 。 


表 21-12 寄存 器 的 作用 


指向 目标 函数 CArtMethod) 9754 


THI 目标 函数 (ArtMethod) 所 需 的 参数 数组 (如 果 
函数 没有 参数 ， 则 为 null) 


天 二 (bytes ) 
e p ariens 





iz + 8] a register argument array | 
[sp + 12] llfp register argument array 





对 于 非 static 的 情况 ，quick_invoke_reg_setup 首 先 复 制 args 中 的 
所 有 数据 (指针 ) 到 core_reg_args 数 组 中 。 接 着 进入 一 个 for 循 环 来 逐 
一 处 理 shorty 字 符 串 中 的 元 素 。shorty 变 量 是 通过 
ArtMethod: :GetShorty 获 取 到 的 ， 简 单 来 说 它 是 对 男 数 原型 的 “ 简 
写 ”， 表 示 〈shorty 的 第 0 个 元 素 代 表 的 是 函数 的 返回 值 ， 因 而 循环 语 
句 是 从 数组 的 序列 1 开始 的 ) 。 表 21-13 展 示 的 是 常见 的 数据 类 型 对 应 的 
简写 ， 供 大 家 参考 。 


表 21-13 ”数据 类 型 对 应 的 简写 





一 下 一 一 一 一 - 





如 果 在 for 循 环 语句 对 shorty 的 处 理 过 程 中 发 现 了 double 和 float， 
那么 我 们 需要 引入 特殊 寄存 器 fp_reg_args。 不 过 在 我 们 这 个 场景 中 
ae es 并 没有 涉及 浮 点 数 的 运算 ， 所 以 可 以 直接 略 
过 。 


针对 寄存 器 的 处 理 完成 后 ， 下 面 就 要 真正 地 去 执行 目标 函数 了 ， 完 
成 这 一 步 操作 的 是 art_quick_invoke_stub_internal 。 这 个 国 数 是 由 汇 
编 代 码 编写 而 成 的 ， 它 需要 解决 如 下 的 核心 问题 点 : 


(1) 如 何 调用 和 执行 目标 范 数 ; 
(2) 函数 结果 值 是 如 何 传递 的 。 


[A] FC ek BWquick_ invoke reg setup 调 用 
art quick invoke stub_internal 时 的 实 参 格式 如 下 : 


art_quick_invoke_stub_internal(method, args, args_size, self, res 
result_in_float, core_reg_ar 


根据 ARM 的 ATPCS 规 范 ，5C 语 言 在 调用 汇编 代码 时 的 参数 如 果 超 过 4 
个 ， 那 么 余下 部 分 就 需要 通过 栈 来 传递 。 进 入 
art_qu ick_invoke_stub_ internal ej WAT BA ANWSAD ARSE A 
示 : 


r0method( method pointer [sp 12]=fp reg args(pointer) 


rl=args(argument array/null) [sp+8|=core reg ares(pomnter) 


r2=args,size(array size) [sp+4|=result in float 


r3=selfíthread pointer) 


[sp result(potnter) 





由 上 图 可 见 ， 最 终 的 函数 结果 值 (result) 将 通过 [sp] 所 指向 的 地 
址 向 外 传递 。 大 家 在 分 析 art quick_invoke_stub_internal 源 码 过 程 中 
也 可 以 验证 一 下 。 


调用 目标 函数 〈 在 我 们 这 个 场景 中 指 的 是 zygotelnit: : main ät 
编译 生成 的 Native Code) 使 用 的 是 blx 这 条 指令 。ARM 体 系 中 常用 的 几 
种 跳 转 指令 包括 : B、BL、BX、BLX 和 BXJ 等 。 其 中 BL 和 BLX 都 会 将 
PC (Program Counter) 的 下 一 个 值 保存 到 链接 寄存 器 《Link 
Register) 中 ， 并 且 把 需要 跳 转 的 目标 地 址 存 入 PC 寄存 器 中 。 


接 下 来 我 们 逐 行 分 析 art_ quick _invoke stub internal ix35C eA 
数 ， 以 帮助 大 家 理解 它 的 实现 原理 。 其 中 标注 了 “. cfi*” 的 代码 并 不 
会 影响 函数 的 最 终 执行 结果 ， 因 而 可 以 直接 略 过 。 为 了 方便 阅读 ， 我 们 
把 所 有 分 析 都 以 注释 的 方式 放 在 了 相应 代码 行 的 后 面 ， 如 下 所 示 : 


/*art/runtime/arch/arm/quick_entrypoints_arm.S*/ 
ENTRY art_quick_invoke_stub_internal 








SPILL_ALL_CALLEE_SAVE_GPRS OK Fs EIS OH Br FF a8 (FEO) Hee, WE 





























mov ri1, sp O 将 栈 指针 保存 在 r11 中 

mov r9, r3 @ 将 r3=method 的 值 保存 在 r9 中 

add r4, r2, #4 @ r4=r2+4=args_sizet4, 需要 额外 分 配 4 

sub r4, sp, r4 @ r4=sp-r4, 预 留 所 有 参数 所 需要 的 空间 ，- 

and r4, #OxFFFFFFFO @ 保证 16 字 节 对 齐 

mov sp, r4 @ sp=r4, 即 sp 指向 预 留 了 空间 并 且 做 了 对 前 

mov r4, ro @ 保存 目标 函数 地 址 到 r4 中 ， 因 为 r9 立 即 要 被 

add rO, sp, #4 @ r0=sp+4， 为 memcpy 准 备 参 数 。 函 数 memcp 
@ 带 3 个 参数 ，r0 对 应 dest,r1=args 对 应 src 

bl memcpy @ 调用 memcpy， 从 而 把 目标 函数 所 需 的 参数 全 i 

mov ip, #0 @ ip=0 

str ip, [sp] @ [sp]=null，memcpy 是 从 sp+4 开 始 复制 的 ， 


























ldr ip, [r11, #48]  @ ip=[r11+48], 加 载 fp 寄 存 器 数组 指针 (注意 之 
@ 有 读者 可 能 会 疑问 怎么 是 #48 呢 ?这 是 因为 函数 - 
@ SPILL_ALL_CALLEE_SAVE_GPRS 压 栈 了 9 个 寄 

vidm ip, {s0-s15} @ 将 内 存 中 的 内 容 复 制 到 sO - S15 寄 存 器 

ldr ip, [r11, #44] @ ip=[r11+44] , 加载 核心 寄存 器 

mov rO, r4 @ 还 原 r9 为 目标 函数 地 址 

add ip, ip, #4 @ ip=ip+4, 跳 过 4 个 字 节 

ldm ip, {ri-r3} @ 将 内 存 中 的 内 容 复 制 到 r1 - r 

ldr ip, [r0, #Art_METHOD_QUICK_CODE_OFFSET_32] @ 获取 目标 水 

b1x ip @ 调用 目标 函数 

mov sp, rid @ 还 原 栈 指针 

ldr r4, [sp, #40] @ 加 载 result_is_float 

ldr r9, [sp, #36] @ 加 载 result 指针 

cmp r4, #0 

ite eq 

strdeq r0, [r9] @ 将 ro6/ri 保 存 到 result 指 针 所 i 

vstrne do, [r9] @ 将 s0-s1/d0 保 存 到 result 指 和 

pop {r4, r5, r6, r7, r8, r9, r10, r11, pc} @ 还 原 





END art_quick_invoke_stub_internal 


寄存 器 的 数量 是 非常 有 限 的 ， 而 当 我 们 需要 占用 到 某 些 已 经 赋值 了 
的 寄存 器 时 ， 可 以 先 把 它们 保存 到 内 存 中 ， 这 个 过 程 被 称 为 寄存 器 洪 出 
(Spill) 。 除 了 上 述 注释 所 示 的 内 容 外 ， 我 们 还 需要 特别 注意 的 是 
ART METHOD _QUI1CK_CODE_OFFSET_32， 它 的 定义 如 下 : 


/*art/runtime/asm_support.h*/ 
#define Art_METHOD_QUICK_CODE_OFFSET_32 36 


ADD_TEST_EQ(Art_METHOD_QUICK_CODE_OFFSET_32, 
art: :ArtMethod: :EntryPointFromQuickCompiledCodeOffset(4) 


那么 这 个 宏 定义 的 作用 是 什么 呢 ? ADD TEST_EQ 可 以 为 我 们 回答 这 
个 问题 。 这 个 函数 会 验证 传 入 的 两 个 参数 〈 即 
ART_METHOD_ QUICK CODE OFFSET 32 和 art: :ArtMethod: :EntryPoint 
FromQuickCompi |edCodeOffset (4). Int32ValueQ)) 是 否 相 等 ， 换 句 话 
说 就 是 : 
ART_METHOD_QUICK_CODE_OFFSET_32= 


art: :ArtMethod: :EntryPointFromQuickCom 
MHEntryPointFromQuickCompi |edCodeOffset cj WAY CE: 


static MemberOffset EntryPointFromQuickCompiledCodeOffset(size_ 
return MemberOffset(PtrSizedFieldsoOffset(pointer_size) + OFFS 
PtrSizedFields, entry_point_from_quick_compiled_code_) 
/ sizeof(void*) * pointer_size); 


RTA “AS , ZE 
EntryPointFromQuickCompiledCode0ffset 所 要 获取 的 就 是 
entry _ point _ from quick compiled code 这 个 变量 在 ArtMethod 类 中 的 
偏 移 量 ， 以 便 art_quick_invoke_stub_internal 中 可 以 顺利 跳 转 到 它 所 
指定 的 Entry Point 中 。 


进入 ART_METHOD QUICK CODE 0FFSET_32 时 的 参数 分 布 如 图 21-68 所 
7J“ o 


{(=ArtMethod(method pointer) sp+48]=fp_teg_ares(pomter 


(spt44]=core reg args(pointer) 


r]=recerver pointer(non static) 


r2=core rejister argument [sp+40]=result in float 


t3=core rejister argument 


[sp+36]=result(pointer) 


9 Registers 





[6B Align 





全 图 21-68 参数 分 布 


从 前 面 小 节 针 对 Entry Point 的 学 习 我 们 知道 ， 它 的 赋值 取决 于 函 
数 的 实际 情况 比如 常见 的 一 个 值 是 
art quick_resolution trampoline， 如 下 所 示 : 





ENTRY art_quick_resolution_trampoline 
SETUP_REFS_AND_ARGS_CALLEE_SAVE_FRAME r2, r3 
mov r2, r9 @ 从 图 21-68 可 知 ，r9 代 表 的 是 当前 的 T 








mov r3, sp @ 堆栈 指针 保存 到 r3 中 




















blx artQuickResolutionTrampoline @ (Method* called, rece 
cbz rO, 1f @ is code pointer null? goto e 
mov r12, rO 

ldr rO, [sp, #0] @ 将 正确 解析 完成 后 的 函数 对 象 保存 到 r( 
RESTORE_REFS_AND_ARGS_CALLEE_SAVE_FRAME 

bx r12 @ 进入 目标 函数 真正 的 入 口 地 址 


RESTORE_REFS_AND_ARGS_CALLEE_SAVE_FRAME 
DELIVER_PENDING_EXCEPTION 
END art_quick_resolution_trampoline 


这 段 汇编 代码 的 关键 点 有 两 个 ， 其 一 是 调用 
artQuickResolutionTrampoline， 其 二 是 根据 这 个 涵 数 返回 值 AER eA 
数 的 真实 地 址 ) 来 开展 工作 。 汇 编 函 数 
art_quick_ resolution trampol ine 5 E WACK a 
artQuickResolutionTrampoline 做 好 参数 准备 一 一 因为 类 似 于 r9? 这 样 的 
寄存 器 是 不 符合 0 语言 的 调用 规范 的 ， 必 须 先 做 处 理 。 不 难 理解 ， 它 传 
递 给 后 者 的 参数 包括 : r0=ArtMethod* (callee， 但 有 可 能 为 “ 伪 目 
标 ”， 参 见 后 续 分 析 ) , r1=receiver* (类 的 实例 对 象 ， 仅 非 Stat ic 的 
情况 下 有 效 ), r2=r9=thread*, r3=sp=ArtMethod**, 





接 下 来 我 们 来 详细 解析 artQuickResolutionTrampoline 的 内 部 实 
现 。 这 个 函数 很 长 ， 我 们 采用 分 段 阅 读 的 方式 : 


/*art/runtime/entrypoints/quick/quick_trampoline_entrypoints.cc*/ 
extern "C" const void* artQuickResolutionTrampoline( 
ArtMethod* called, mirror::Object* receiver, Thread* self, Ar 
SHARED_LOCKS_REQUIRED(Locks::mutator_lock_) {... 
ClassLinker* linker = Runtime: :Current()->GetClassLinker(); 
ArtMethod* caller = QuickArgumentVisitor: :GetCallingMethod(sp); 
InvokeType invoke_type; 
MethodReference called_method(nullptr, 0); 
const bool called_method_known_on_entry = !called->IsRuntimeMet 
if (!called_method_known_on_entry) {f//called 是 否 代 表 了 真正 的 函数 对 双 
uint32_t dex_pc = caller->ToDexPc(QuickArgumentVisitor: :GetCa 
const DexFile::CodeItem* code; 
called_method.dex_file = caller->GetDexFile(); 
code = caller->GetCodeItem(); 
CHECK_LT(dex_pc, code->insns_size_in_code_units_); 
const Instruction* instr = Instruction: :At(&code->insns_[dex_ 
Instruction: :Code instr_code = instr->Opcode(); 
bool is_range; 
Switch (instr_code) { 








case Instruction: : INVOKE_DIRECT: 
invoke_type = kDirect; 
is_range = false; 


break; 
case Instruction: : INVOKE_DIRECT_RANGE: 
.其 他 case 类 同 ， 直 接 省 略 


called_method.dex_method_index = (is_range) ? instr->VRegB_3r 
instr->VRegB_35c(); 

else {// 虽 然 代表 了 页 正 的 函数 对 象 ， 但 还 未 解析 完成 。 比 如 Static 函 数 
invoke_type = kStatic; 

called _method.dex file = called->GetDexFile(); 
called_method.dex_method_index = called->GetDexMethodIndex(); 





Ww 


总 体 来 说 ， 程 序 中 会 有 如 下 两 种 常见 情况 需要 使 用 到 


artQuickResolutionTrampol ine: 





o X E Be FER HR AT 


这 有 PRAM T Be 4 习 到 的 动态 链接 库 中 的 G0T/PLT 机 制 
一 一 即 只 有 当 消 数 第 一 次 被 调用 时 才 会 去 执行 解析 动作 ， 而 不 是 在 一 开 
就 完成 所 有 函数 的 解析 ， 这 样 做 无 疑 可 以 提高 程序 的 运行 效率 。 


系统 充 怎 么 区 分 出 函数 是 第 一 次 被 调用 呢 ? 从 上 述 代 码 段 中 不 难 发 
a E NethodiX PAR. 它 的 内 部 实现 只 有 一 条 语 
句 ， Bp: 


dex_method_index_ == DexFile: :kDexNoIndex 


换 句 话说 ，Runtime Method 这 种 类 型 的 函数 的 最 大 特征 是 index 值 
为 无 效 的 kDexNolndex。 


一 旦 程序 判断 出 cal1ed 指 向 的 是 一 个 Runtime Method, AA TR 
的 重点 自然 是 : 系统 根据 什么 线索 来 找到 真正 的 目标 函数 并 替代 这 
+ “APR” We? 大 家 可 以 结合 前 面 已 经 学 习 过 的 知识 点 ， 自 行 思考 一 
下 有 哪些 对 我 们 有 用 的 信息 。 


bs 就 是 调用 者 (caller) 提供 的 字 节 三 序列 。 因 为 jnvoke 这 个 
字 节 码 命 令 本 身 是 带 有 描述 目标 对 象 的 参数 的 ， 如 此 一 来 我 们 只 要 沿 
这 一 条 “路 径 ” 融 可 以 找到 目标 函数 〈 保 存在 cal led_method 中 ) 所 对 


应 的 index 值 了 。 参 考 范 例如 下 : 


invoke-virtual {v4, vi}, Lcom/example/myapp/MyActivity; .setConten 
° HAARE 解析 


前 面 在 学 习 LinkCode 时 已 经 介绍 过 ， Stat ic 函数 因 其 特殊 性 需 要 用 
到 延迟 解析 技术 ， 对 应 的 就 是 上 述 代 码 段 中 的 el se 分 支部 分 。 因 为 此 时 
called 对 象 中 的 index 已 经 代表 了 目标 函数 的 索引 值 ， 意 味 着 我 们 不 需 
要 再 像 前 一 种 情况 那样 大 费 周章 地 去 做 查找 工作 了 : 


const bool virtual_or_interface = invoke_type == kVirtual || in 
// Resolve method filling in dex cache. 
if (!called_method_known_on_entry) { 
StackHandleScope<i> hs(self); 
mirror::Object* dummy = nullptr; 
Handlewrapper<mirror: :Object> h_receiver ( 
hs.NewHandlewrapper(virtual_or_interface ? &receiver : &d 
DCHECK_EQ(caller->GetDexFile(), called_method.dex_file); 
called = linker->ResolveMethod(self, called_method.dex_method. 


得 到 了 目标 函数 的 索引 值 后 ， 接 下 来 就 可 以 利用 ClassL inker 提 供 
的 ResolveMethod 来 得 到 目标 对 象 (ArtMethod) 了 。 当然 ， 只 有 妆 
called method known_on_entry 为 false 时 才 需 要 执行 这 一 步 操作 : 


const void* code = nullptr; 
if (LIKELY(!self->IsExceptionPending())) 4.. 
if (virtual_or_interface) {..// 虚 函数 或 者 接口 函数 ， 涉 及 多 态 性 
ArtMethod* orig_called = called; 
if (invoke_type == kVirtual) { 
called = receiver ->GetClass()->FindVirtualMethodForVirtua 





} else { 
called = receiver ->GetClass()->FindVirtualMethodForInterf 


} 


} else if (invoke_type == kStatic) {// AKZ 
const auto called_dex_method_idx = called->GetDexMethodInde 
if (called->GetDexFile() == called_method.dex_file && 
called_method.dex_method_index != called_dex_method_idx 
called->GetDexCache()->SetResolvedMethod(called_dex_metho 

















t 
} 
// 目标 函数 所 在 类 是 否 已 经 初始 化 过 


linker ->EnsureInitialized(soa.Self(), called_class, true, tru 

if (LIKELY(called_class->IsInitialized())) {// 已 经 初始 化 过 的 情况 

if (UNLIKELY(Dbg: :IsForcedInterpreterNeededForResolution(se 
code = GetQuickToInterpreterBridge(); 

} else if (UNLIKELY(Dbg: :IsForcedInstrumentationNeededForRe 





code = GetQuickInstrumentationEntryPoint(); 
} else { 
code = called->GetEntryPointFromQuickCompiledCode(); 


} 
} else if (called_class->IsInitializing()) {..// 初 始 化 未 完成 的 情 7 
} else { 

DCHECK(called_class->IsErroneous()); 


} 


pill 
“As 





} 


*sp = called; 
return code; 


J 


相信 大 家 已 经 从 上 述 的 代码 段 中 看 出 了 我 们 所 面临 的 第 二 个 障碍 
了 ， 即 多 态 性 此 时 需要 根据 this 指 针 〈 即 receiver) 来 判断 函数 是 
否 被 重 载 。 大 家 可 以 自行 学 习 FindVirtualMethodForVirtual 和 
FindVirtualMethodFor Interface 来 了 解 其 中 的 实现 细节 。 


最 后 ， 我 们 还 需要 利用 ClassLinker 的 Ensurelnitialized 来 确保 目 
标 函 数 所 在 的 类 是 否 已 经 成 功 初 始 化 。 以 初始 化 完成 的 情况 为 例 ， 此 时 
就 可 以 确定 出 目标 函数 的 入 口 地 址 了 。 


如 果 是 因为 调试 的 原因 需要 强制 使 用 Interpreter， 那 么 入 口 地 址 
会 被 设置 为 GetQuick TolnterpreterBr idge; 如 果 是 需要 局 用 
Instrumentation 〈 后 续 小 节 有 专门 介绍 ) 的 情况 ， 入 口 地 址 会 被 设置 
为 GetQuicklnstrumentationEntryPoint; 否则 入 口 地 址 是 
GetEntryPointFromQuick Compi |edCode. 


我 们 需要 注意 函数 结尾 的 如 下 几 行 语句 : 


*sp = called; 








return code; 


} 


第 一 行 语 句 表示 sp 栈 顶 位 置 将 保存 真实 的 目标 函数 对 象 
(called) 。 


第 二 行 语 句 表 示 artQui ckResolutionTrampoline 函 数 的 返回 值 是 
called 的 入 口 地 址 。 


所 以 当 artQuickResolutionTrampoline 成 功 返 回 后 ， 
art_quick_ resolution trampoline 首 先 会 判断 r0 的 值 是 否 为 0。 如 果 答 
案 是 否定 的 ， 那 么 紧 接 着 就 把 r0 赋 值 给 r12， 并 从 sp 栈 顶 加 载 真 实 目 标 
对 象 到 r0， 然 后 跳 转 到 入 口 地 址 (r12) ; 否则 就 跳 转 到 
art_quick_ resolution trampoline 中 的 exception 进 行 异常 处 理 。 


这 样 Art 虚 拟 机 就 成 功 地 执行 了 字 节 码 被 编译 生成 的 本 地 机 器 码 
Ta 
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21.12 Android x86 版 本 兼容 ARM 二 进 制 代码 
Bridge 


目前 手机 等 终端 设备 使 用 ARM 必 片 的 居多 ， 但 这 并 不 代表 Android 系 
统 只 能 运用 在 一 种 硬件 平台 之 上 。 事 实 上 ，Android 系 统 本 身 是 希望 可 
以 在 更 多 的 芯片 平台 上 运行 的 ， 而 且 这 种 愿景 也 被 越 来 越 多 的 芯片 厂商 
所 支持 一 一 其 中 就 包括 1nte1 的 x86 架 构 。 


Android x86 版 本 至 少 在 如 下 几 个 场景 中 具有 应 用 价值 : 
o 终端 设备 


不 管 是 手机 、 平 板 或 是 智能 家 居 ， 均 有 不 少 厂 商 已 经 在 x86 染 构 上 
实现 了 Android 产 品 。 


© PC 和 笔记 本 电脑 


PC 上 运行 Android 系 统 并 不 是 什么 新 鲜 事 了 ， 而 且 已 经 有 几 个 开源 
组 织 在 专门 从 事 这 方面 的 工作 。 大 家 如 果 有 兴趣 的 话 可 以 搜索 了 解 详 


情 
B o 
e Android x86 4% 3 以 ae 


Android 模 拟 器 长 期 以 来 广 受 诉 病 的 缺陷 就 是 “ 巨 慢 无 比 ”。 这 其 
中 的 一 个 重要 原因 就 是 ARM 版 本 的 Android 系 统 需要 经 过 “翻译 ”才能 运 
行 于 普遍 采用 x86 架 构 的 研发 机 器 之 上 。 换 句 话 说， 假如 我 们 可 以 直接 
为 开发 人 员 提 供 x86 版 本 的 模拟 器 镜像 ， 那 么 无 疑 可 以 极 大 地 提高 模拟 
器 的 性 能 ， 从 而 满足 开发 人 员 的 工作 需求 。 根 据 笔 者 和 1nte1 员 工 的 交 
谈 得 知 ， 他 们 和 Google 在 x86 版 本 上 开展 过 紧密 的 合作 ， 其 输出 成 果 就 
是 目前 越 来 越 好 用 的 SDK 中 的 x86 模 拟 器 了 。 

愿景 总 是 很 美好 的 ， 但 Android x86 版 本 如 果 希 望 在 市 面 上 得 到 广 
泛 应 用 ， 有 一 个 核心 问题 是 必须 要 解决 的 一 一 那 就 是 如 何在 x86 版 本 中 
兼容 ARM 二 进 制 代 码 。 


可 能 有 如 下 两 种 方案 可 以 解决 上 述 这 一 问题 : 


n 方案 1， 让 各 应 用 程序 厂商 在 提供 ARM 库 的 同时 ， 一 并 打包 提供 x86 
Æ 


这 个 方案 理论 上 讲 可 以 很 好 地 解决 问题 ， 而 且 Google 为 此 也 给 开发 
者 提供 了 很 多 便利 一 一 比如 NDK 就 已 经 支持 将 源码 同时 编译 成 针对 多 个 
心 片 染 构 的 机 器 码 。 但 是 话说 回来 ， 并 不 是 所 有 应 用 程序 厂商 都 愿意 承 
担 这 种 额外 的 工作 ; 同时 ， 添 加 新 的 库 文件 也 意味 着 APK 体 积 的 增长 ， 
这 也 是 我 们 需要 考虑 的 问题 。 


方案 2， 在 我 们 没有 办 法 保证 所 有 厂商 都 从 “APK 源 头 ” 来 配合 解决 
问题 的 情况 下 ， 如 何 从 Android 系 统 层 面 来 提高 对 ARM 二 进 制 代码 的 兼容 
性 就 成 了 “必然 的 选择 ”。 


这 种 方案 也 有 几 种 实现 方式 ， 包 括 但 不 限于 : 
e Intel Houdini 


Intel 为 了 提高 自己 的 忌 片 销量 ， 在 较 早 时 期 就 开始 思考 并 解决 与 
ARM 库 的 兼容 性 问题 。 可 惜 的 是 Inte1 并 没有 将 这 一 成 果 作 为 开源 项 目 贡 
献 给 Android 社 区 ， 而 是 只 将 这 一 技术 授权 给 采用 1ntel 芯 片 的 设备 三 
商 。lntel 考 虑 问题 通常 是 从 硬件 芯片 的 销量 角度 出 发 ， 它 并 不 关心 软 
件 本 身 所 带 来 的 直接 价值 “例如 将 Houdini 作 为 技术 方案 收取 费用 )〉。 
ee eee ene 所 以 它 的 这 种 做 法 本 身 倒是 
无 可 厚 非 的 。 


e Qemu User Mode 


另 一 种 在 Android x86 平 台中 兼容 ARM 的 实现 方式 是 利用 Qemu User 
Mode。 我 们 知道 ，Qemu 有 两 个 主要 的 工作 模式 ， 即 Sysytem Mode 和 User 
Mode。 前 者 表示 用 Qemu 来 模拟 一 个 完整 的 “硬件 平台 ”， 包 括 CPU、 内 
存 及 外 围 设备 等 ;， 后 者 的 例子 则 包括 了 著名 的 Wine 它 的 主要 职责 就 
是 以 一 种 轻 量 级 的 方式 让 Windows 应 用 程序 可 以 运行 于 POS1X-Compliant 
的 操作 系统 之 上 。 





e Native Bridge 


MAndroid 5. 0 开始 ，Google 官 方 提供 了 一 个 名 为 Native Bridge 的 
中 间 模 块 ， 以 支撑 不 同 机 器 平台 在 运行 非 对 应 平台 代码 之 间 的 问题 Can 


x86 平 台 需 要 运行 arm 代 码 ， 就 需要 转换 过 程 ) 。 由 于 兼容 性 问题 的 解决 
是 和 具体 硬件 芯片 相关 联 的 ， 所 以 Native Bridge 只 能 是 起 到 “ 框 
- 的 作用 。 而 具体 填充 什么 内 容 ， 则 由 芯片 厂商 例如 Intel) 来 完 


本 小 节 我 们 将 重点 分 析 NativeBridge 和 houdini 结 合 方案 的 部 分 实 
现 原理 。 其 中 NativeBr idge 的 实现 主体 
在 /system/core/1ibnativebridge 中 ， 只 有 一 个 native_bridge. cc 文 


件 。 
那么 NativeBridge 具 体会 在 程序 运行 中 的 什么 时 候 起 作用 呢 ? 


我 们 知道 ，Java 层 的 代码 如 果 要 能 顺利 调用 到 native 函 数 ， 首 先 得 
保证 这 个 函数 所 在 的 1ibrary 已 经 被 成 功 加 载 到 内 存 中 。 通 常情 况 下 ， 
开发 人 员 会 使 用 System，LoadLibrary () 来 预先 把 一 个 so 库 加 载 到 内 存 
中 。 这 个 函数 只 是 起 到 一 个 中 转 作 用 ， 它 又 会 通过 Java 层 的 
loadLibrary 来 进一步 判断 是 否 需要 加 载 库 。 如 果 答 案 是 肯定 的 话 ， 那 
么 程序 会 利用 doLoad 来 完成 具体 的 加 载 过 程 。 后 者 将 通过 nativeLoad 来 
简单 调用 一 个 已 经 利用 we11_known_classes. cc 完成 init 的 本 地 层 C++ 上 


数 Runt ime_nativeLoad : 


/*libcore/luni/src/main/java/java/lang/Runtime. java*/ 
static jstring Runtime_nativeLoad(JNIEnv* env, jclass, jstring ja 
jobject javaLoader, jstring javaLdLi 
ScopedUtfChars filename(env, javaFilename) ; 


SetLdLibraryPath(env, javaLdLibraryPathJstr); 
std::string error_msg; 


JavaVMExt* vm = Runtime: :Current()->GetJavavM(); 
bool success = vm->LoadNativeLibrary(env, filename.c_str(), javaL 
&error_msg); 


} 
env->ExceptionClear(); 
return env->NewStringUTF(error_msg.c_str()); 


J 


其 中 javaLdLibraryPathJstr 有 点 类 似 于 Linux 中 的 
LD_L1BRARY_PATH 环 境 变 量 ， 它 用 于 指示 1ibrary 的 搜索 路 径 。 这 个 路 径 


是 保证 后 续 动 态 库 可 以 成 功 加 载 的 关键 : 


/*art/runtime/java_vm_ext.cc*/ 
bool JavaVMExt::LoadNativeLibrary(JNIEnv* env, const std::string& 
class_loader, std::string* error_msg) {... 

SharedLibrary* library; 

Thread* self = Thread::Current(); 


// TODO: move the locking (and more of this logic) into Libra 
MutexLock mu(self, *Locks::jni_libraries_lock_); 
library = libraries_->Get(path);// 首 先 判断 是 否 已 经 加 载 过 这 个 1ibral 








} 
if (library != nullptr) {// 已 经 加 载 过 的 情况 





return true; 


} 


Locks: :mutator_lock_->AssertNotHeld(self); 
const char* path_str = path.empty() ? nullptr : path.c_str(); 
void* handle = dlopen(path_str, RTLD_NOW);//ł} F library x4} 
bool needs_native_bridge = false;//# ii native bridge 
if (handle == nullptr) {// 正 常 途径 打开 1ibrary 失 败 
if (android: :NativeBridgeIsSupported(path_str)) {// 当 前 不 一 定 支 
handle = android: :NativeBridgeLoadLibrary(path_str, RTLD_NO 











needs_native_bridge = true; 
} 
} 


bool created_library = false; 
{// 创 建 一 个 Shared Library 
std::unique_ptr<SharedLibrary> new_library( 
new SharedLibrary(env, self, path, handle, class_loader)) 
MutexLock mu(self, *Locks::jni_libraries_lock_); 
library = 1libraries_->Get(path);// 有 lock 的 保护 ， 以 处 理 好 多 线程 情况 
if (library == nullptr) {// 为 hullptr 说 明 其 他 线程 还 没有 完成 对 librai 
library = new_library.release(); 
libraries_->Put(path, library); 
created_library = true; 
} 
} 


bool was_successful = false; 
void* sym; 
if (needs_native_bridge) { 
library->SetNeedsNativeBridge(); 
sym = library->FindSymbolWithNativeBridge("JNI_OnLoad", nullp 



































} else { 
sym = dlsym(handle, "JNI_OnLoad"); 


} 

if (sym == nullptr) { 
VLOG(jni) << "[No JNI_OnLoad found in \"" << path << "\"]"; 
was_successful = true; 

} else 4.. 

Í 


library->SetResult(was_successful); 
return was_successful; 


LoadNativeLibrary 的 目的 用 一 句 话 来 简单 概况 ， 就 是 加 载 目 标 库 
并 执行 它 的 入 口 函 数 。 通 常 JNI_0nLoad 就 是 jni 库 的 入 口 函 数 ， 开 发 人 
员 会 利用 它 来 完成 一 些 初始 化 操作 。 不 过 这 个 函数 倒 不 是 必须 要 存在 
的 ， 所 以 即便 是 最 终 找 不 到 JNI_0nLoad， 也 并 不 代表 一 定 是 出 现 程序 异 
常 了 (此 时 会 有 log 打 印 出 来 ， 作 为 warning) 。 加 载 目 标 库 的 过 程 基 本 
上 分 为 两 条 途径 ， 即 正常 加 载 和 借助 native _ bridge 加 载 的 情况 。 换 句 
话说 ， 我 们 首先 利用 dlopen 来 尝试 打开 目标 1ibrary， 假 如 成 功 的 话 ， 
那么 接 下 来 就 可 以 走 正 常 渠 道 ; 否则 通过 NativeBr idge | sSuppor tedi## 
一 步 判 断 是 否 支 持 native bridge， 假如 答案 是 肯定 的 话 才 会 利用 
native _ bridge 加 载 所 需 的 动态 链接 库 ， 具 体 使 用 的 函数 是 
Nat i veBr idgeLoadLibrary. 


接 下 来 需要 创建 一 个 新 的 SharedLibrary。 可 以 看 到 我 们 实际 上 是 
先 new 了 一 个 SharedLibrary， 然 后 再 去 竞争 |ibraries lock 这 是 为 
了 避免 多 个 线程 情况 下 ， 可 能 出 现 其 他 线程 也 需要 加 载 同一 个 library 
的 竞争 环境 。 假 如 最 后 的 结果 显示 1ibrary == nullptr， 那 么 表明 我 们 
是 第 1 个 加 载 1ibrary 的 ， 此 时 就 需要 将 1ibrary 存 储 到 1ibraries_ 中 。 


接 下 来 的 操作 分 为 两 种 可 能 性 。 如 果 needs_native_bridge 为 
true， 表 明 当 前 出 现 了 目标 库 与 平台 不 兼容 性 的 情况 ， 解 决 的 办 法 就 是 
利用 library->FindSymbolWithNativeBr idge 来 查找 到 JN1_0nLoad; G 
则 就 是 普通 的 情况 ， 此 时 只 需要 通过 dlsym 就 可 以 较 容 易 地 定位 到 目标 
eK ZXUNI_ OnLoad 了。 


上 述 的 分 析 中 ， 我 们 还 需要 对 NativeBridgelsSupported 和 
FindSymbolWithNativeBridge 做 更 深入 的 解析 。 其 中 
NativeBr idgelsSupported 本 身 的 实现 很 简单 : 





bool NativeBridgeIsSupported(const char* libpath) { 
if (NativeBridgeInitialized()) { 
return callbacks->isSupported(libpath); 


return false; 


} 


在 native bridge 已 经 初始 化 的 情况 下 ， 通 过 cal1backs 提 供 的 
isSupported 来 得 到 结果 。 那 么 cal lbacks 是 什么 呢 ? 为 了 让 大 家 有 一 个 
全 局 的 认识 ， 我 们 可 以 从 native bridge 的 初始 化 过 程 入 手 来 进行 讲 


解 。 
Native bridge 的 生命 周期 包括 5 个 状态 ， 即 : 


enum class NativeBridgeState { 


kNotSetup, // 最 初始 的 状态 

kOpened, // dlopen native bridge 后 转移 到 这 个 

kPreInitialized, // pre-initialization 成 功 后 转移 到 这 - 

kInitialized, // 初始 化 成 功 后 转移 到 这 个 状态 

kClosed // 发 生 错误 或 关闭 native bridge 后 转移 : 
J; 


接 下 来 的 讲解 就 按照 native bridge 在 各 个 状态 间 的 迁移 展开 。 


我 们 知道 ，Android 应 用 程序 是 由 Zygote 孵 化 出 来 的 ， 而 后 者 又 是 
寡居 于 AndroidRuntime 之 上 的 。 当 AndroidRuntime 在 启动 一 个 虚拟 机 
时 ， 它 同时 也 会 对 native _ bridge 执行 相关 的 配置 ， 如 下 所 示 : 


/*frameworks/base/core/jni/AndroidRuntime.cpp*/ 
int AndroidRuntime::startVm(JavaVM** pJavaVM, JNIEnv** pEnv, 


{... 
property_get("ro.dalvik.vm.native.bridge", propBuf, ""); 
if (propBuf[O] == '\O') { 
ALOGW("ro.dalvik.vm.native.bridge is not expected to be e 
} else if (strcmp(propBuf, "0") != 0) { 
snprintf(nativeBridgeLibrary, sizeof("-XX:NativeBridge=" ) 
+ PROPERTY_VALUE_MAX, "-XX:NativeBridge=%s", prop 
addOption(nativeBridgeLibrary) ; 
} 


简单 来 讲 ， 系 统 变 量 “ro. dalvik. vm. native. bridge” native 
bridge 的 “开关 ”。 即 如 果 它 不 为 0， 那 么 就 表示 这 个 变量 用 于 存储 
native bridge 1ibrary 对 应 的 名 称 ; 否则 就 表示 当前 不 需要 启用 


native bridge。AndroidRuntime 中 所 做 的 这 一 配置 会 通过 “- 
XX:NativeBridge=” 传 递 给 虚拟 机 ， 以 便 后 者 在 初始 化 的 时 候 应 用 起 
来 : 


bool Runtime::Init(const RuntimeOptions& raw_options, bool ignore 
std::string native_bridge_file_name = 

runtime_options.ReleaseOrDefault (Op 

is_native_bridge_loaded_ = LoadNativeBridge(native_bridge_ fil 


其 中 native bridge library filename 就 用 于 指示 native bridge 
对 应 的 so 库 的 路 径 ， 它 最 开始 就 是 由 AndroidRuntime: :startVm 赋 值 
的 。 真 正 去 加 载 Native bridge 的 地 方 在 LoadNativeBridge 中 : 


/*art/runtime/native_bridge_art_interface.cc*/ 
bool LoadNativeBridge(std::string& native_bridge_library_filename 
return android: :LoadNativeBridge(native_bridge_library_filename 
&native_bridge_art_callbacks_); 


需要 注意 的 是 ，Art 虚 拟 机 代码 中 存在 两 个 LoadNat i veBr idge 
数 ， 上 面 所 示 的 代码 段 是 其 中 的 第 1 个 ， 它 起 到 “interface” 的 作用 ， 
以 此 来 屏 贡 不 同 虚拟 机 之 间 的 差异 。 上 述 函 数 中 的 
native bridge art callbacks 代表 了 Art 虚 拟 机 相对 于 native bridge 
的 回调 接口 ， 它 是 一 个 NativeBridgeRuntimeCal1backs 结 构 体 ， 如 下 所 
示 : 


static android: :NativeBridgeRuntimeCallbacks native_bridge_art_ca 
GetMethodShorty, GetNativeMethodCount, GetNativeMethods 
}; 


第 2 个 LoadNat i veBr idge 会 根据 上 一 个 函数 传递 的 参数 来 加 载 具 体 
的 native bridge library， 核 心 代码 如 下 : 


/*system/core/libnativebridge/native_bridge.cc*/ 
bool LoadNativeBridge(const char* nb_library_filename, 
const NativeBridgeRuntimeCallbacks* runtime_cbs 
if (nb_library_filename == nullptr || *nb_library_filename == 
CloseNativeBridge(false); 
return false; 
} else { 
if (!NativeBridgeNameAcceptable(nb_library_filename)) { 
CloseNativeBridge(true) ; 
} else { 


// Try to open the library. 
void* handle = dlopen(nb_library_filename, RTLD_LAZY) ;// 打 开 
if (handle != nullptr) { 
callbacks = reinterpret_cast<NativeBridgeCallbacks*>(dlsy 
kNativeBridgeIn 
if (callbacks != nullptr) { 
if (VersionCheck(callbacks)) { 
native_bridge_handle = handle; 
} else {.. 


} 
} else { 
dlclose(handle); 


} 

if (callbacks == nullptr) { 
CloseNativeBridge(true); 

} else { 
runtime_callbacks = runtime_cbs;// 保 存 与 runtime 之 间 的 通信 接 [ 
state = NativeBridgeState: :kopened;// 状 态 迁 移 

} 


return state == NativeBridgeState: :kOpened; 


Í 
} 


当 我 们 在 实现 类 似 函 数 时 ， 首 先 应 该 思考 的 是 上 述 这 个 函数 是 否 需 
要 lock 的 保护 ? 我们 知道 ， 当 程序 执行 到 这 里 时 还 没有 创建 其 他 线程 。 
意味 着 并 不 存在 多 线程 竞争 的 环境 ， 所 以 在 LoadNativeBr idge 中 还 不 需 
要 锁 保 护 。 


LoadNat i veBr idge 的 处 理 远 辑 并 不 复杂 ， 因 而 我 们 不 对 细节 部 分 做 
过 多 分 析 。 它 的 主要 任务 就 是 按照 nb_ library filename 打 开 native 
bridge 的 动态 实现 库 ， 然 后 dlsym 找 到 名 为 
kNativeBridgelnterfaceSymbo| 的 符号 。 
kNativeBridgelnterfaceSymbo| 是 一 个 字符 串 ， 被 赋值 
为 “NativeBridgeltf”【〔 这 个 名 字 猜 测 可 能 是 NativeBridgelnterface 
的 简写 ) ， 换 句 话说 native bridge 1ibrary 必 须要 暴露 一 个 
NativeBr idgeltf 接 口 。 而 至 于 native bridge library 的 具体 名 称 ， 则 
FH “ro. dalvik. vm. native.bridge” 来 决定 。 所 以 说 任何 基于 native 
bridge 的 实现 〈 如 houdini ) 都 需要 配置 这 个 系统 属性 。 


至 此 native _ bridge 就 加 载 成 功 了 ， 不 过 流程 还 没有 结束 ， 因 为 我 
们 在 使 用 它 之 前 还 需要 先 做 初始 化 。 那 么 什么 时 候 执 行 初始 化 呢 ? 这 个 


时 机 当然 应 该 是 在 应 用 程序 的 虚拟 机 正式 工作 前 。 具 体 而 言 ， 是 由 
Zygote 呈 化 器 来 控制 的 。 我 们 在 本 书 的 系统 启动 章节 对 Zygote 有 详细 的 
描述 ， 如 果 有 需要 大 家 可 以 结合 起 来 阅读 。 在 native bridge 这 个 场景 
中 ， 我 们 只 需要 补充 两 点 知识 : 


e 当 有 一 个 Android 新 应 用 程序 需要 启动 时 ， Zygote 会 介入 处 理 ， 并 调 
用 forkAndSpecialize。 
e 当 fotk 结 束 时 ，callPostForkChildHooks 会 被 调用 。 





函数 forkAndSpecialize 以 及 它 所 调用 的 其 他 范 数 的 作用 是 在 
Zygote 中 fork 出 一 个 子 进程 ， 并 通过 一 系列 改造 将 其 转变 为 目标 应 用 程 
序 。 另 外 ， 这 些 工作 的 主体 并 非 在 Java 层 ， 而 是 在 nat ive 层 ， 所 涉及 的 
最 核心 的 一 个 jni 逊 数 是 nativeForkAndSpecialize， 后 者 又 会 进一步 调 
用 ForkAndSpecializeCommon: 


/*frameworks/base/core/jni/com_android_internal_os_Zygote.cpp*/ 
static pid_t ForkAndSpecializeCommon(...) {... 
bool use_native_bridge = !is_system_server && (instructionSet 
&& android: :NativeBridgeAvailable();//Z Am 2 # native br 
if (use_native_bridge) { 
ScopedUtfChars isa_string(env, instructionSet); 
use_native_bridge = android: :NeedsNativeBridge(isa_string.c 
} 
if (use_native_bridge && dataDir == NULL) 4.. 
use_native_bridge = false; 
ALOGW("Native bridge will not be used because dataDir == NU 
} 


if (use native bridge) { 
ScopedUtfChars isa_string(env, instructionSet); 
ScopedUtfChars data_dir(env, dataDir); 
android: :PreInitializeNativeBridge(data_dir.c_str(), isa_st 


} 


env->CallStaticVoidMethod(gZygoteClass, gCallPostForkChildHoo 
is_system_server ? NULL : instructionSet 





} else if (pid > 0) { 
} 


return pid; 


} 
是 否 zygote fork 出 来 的 所 有 进程 都 需要 native bridge? 不 一 


定 。 辟 如 当前 是 system server (系统 类 的 进程 都 是 针对 硬件 平台 编译 
出 来 的 ， 不 会 出 现 这 种 问题 ) ， 或 者 native bridge 不 可 用 《此 时 说 明 
系统 中 没有 开启 这 个 功能 ， 或 者 是 功能 不 可 用 ) ， 或 者 data 路 径 为 空 拉 
情况 下 就 无 需 native bridge。 另 外， 即便 上 述 条 件 都 满足 ， 但 当前 进 
程 并 不 存在 兼容 性 问题 〈 比 如 当前 是 x86 平 台 ， 而 且 动 态 链接 库 也 是 针 
对 x86 编 译 的 ) ， 那 么 当然 也 不 需要 native bridge。 


如 果 确 定 必须 使 用 native bridge， 那 么 还 应 该 对 它 进行 pre- 
initialize， 即 : 


/*system/core/libnativebridge/native_bridge.cc*/ 

bool PreInitializeNativeBridge(const char* app _data_dir_in, const 

instruction_set) {... 
const size_t len = strlen(app_data_dir_in) + strlen(kCodeCacheD 
app_code_cache_dir = new char[len]; 
snprintf(app_code_cache_dir, len, "%s/%s", app_data_dir_in, kCo 
state = NativeBridgeState: :kPreInitialized;//,AILE 





#ifndef \_\_APPLE__ 
if (instruction_set == nullptr) { 
return true; 
} 


size_t isa len = strlen(instruction_set); 
char cpuinfo_path[1024]; 


#ifdef HAVE_ANDROID_OS 
snprintf(cpuinfo_path, sizeof(cpuinfo_path), "/system/1lib" 
#ifdef _ LP64__ 
W 64" 
#endif // _ LP64 _ 
"/%s/cpuinfo", instruction_set); 
#else // !HAVE_ANDROID_0S 
// To be able to test on the host, we hardwire a relative path. 
snprintf(cpuinfo_path, sizeof(cpuinfo_path), "./cpuinfo"); 
#endif 


// Bind-mount. 


if (TEMP_FAILURE_RETRY(mount(cpuinfo_path, // Source. 
"/proc/cpuinfo", // Target. 
nullptr, // FS type. 
MS_BIND, // Mount flag 
nullptr)) == -1) { // "Data." 


ALOGW("Failed to bind-mount %s as /proc/cpuinfo: %s", cpuinfo 


} 


#else // __APPLE__ 

UNUSED(instruction_set); 

ALOGW("Mac OS does not support bind-mounting. Host simulation o 
#endif 


return true; 


} 


不 难 发 现 ，pre-initialize 时 还 未 与 真正 的 native bridge (如 
houdini) 产生 关系 ， 而 是 虚拟 机 本 身 为 native bridge 的 运行 而 所 做 的 
一 系列 准备 工作 。 真 正 初始 化 native bridge 实 现 体 的 地 方 在 
Runtime: :Start 中 ， 进 一 步 讲 是 Start 调 用 的 InitNonZygote0rPostFork 
函数 中 。 因 为 在 我 们 这 个 场景 下 act ion 为 
NativeBr idgeAction::klnitialize， 所 以 InitNonZygote0rPostFork 内 
部 会 根据 这 一 action 的 值 来 执行 InitializeNativeBridge， 从 而 完成 对 
native bridge 的 初始 化 。 


接 下 来 我 们 再 回答 另 一 个 问题 ， 即 NativeBridgeLoadLibrary 是 如 
何 通 过 native bridge 来 加 载 目 标 对 象 的 : 


/*system/core/libnativebridge/native_bridge.cc*/ 
void* NativeBridgeLoadLibrary(const char* libpath, int flag) { 
if (NativeBridgeInitialized()) { 
return callbacks->loadLibrary(libpath, flag); 


return nullptr; 


} 


不 难 发 现 ， 系 统 直接 调用 了 native bridge 实 现 体 所 提供 的 
callbacks->loadLibrary， 而 最 终 如 何 完成 对 目标 库 的 加 载 则 由 native 
bridge 的 实现 体 广 商 〈 如 Intel 提 供 的 houdini ) 来 全 权 负 责 。 因 为 
houdini 并 不 是 开源 项 目 ， 无 法 直接 对 其 内 部 实现 展开 阐述 。 不 过 网 上 
已 经 有 不 少 利用 特殊 手段 对 其 进行 分 析 的 资料 ， 有 兴趣 的 读者 可 以 搜索 
阅读 ， 如 图 21-69 所 示 。 


虚拟 机 Runtme (如 Art) 


NativeBridgeRuntimeCallbacks 


ativeBridgeRuntimeCallbacks*runtime callbacks: | | libnativebridge(native_bridge.cc) 
ativeBridgeCallbacks* callbacks 


N 
N 





Native bridge(so) 


NativeBridgeCallbacksNativeBridgeltt 





全 图 21-69 Library 之 间 的 关系 
最 后 我 们 再 来 小 结 一 下 本 小 节 出 现 的 3 个 1ibrary 之 间 的 关系 。 
e Native bridge 的 具体 实现 会 被 封装 在 一 个 so 库 中 


如 果 用 户 没有 通过 “-XX:NativeBridge=” 特 别 指定 的 话 ， 那 么 so 
库 的 名 字 就 使 用 默认 值 。 另 外 ，native bridge 的 so 库 需 要 expose 一 个 
名 为 “NativeBridgeltf” 的 接口 ， 对 应 的 是 NativeBridge Callbacks 
结构 体 ， 其 中 实现 了 isSupported、loadLibrary 等 关键 函数 。 值 得 一 提 
的 是 ， 系 统 中 允许 多 个 native bridge 的 存在 


。 libnativebridge 只 是 一 个 中 介 ， 它 所 提供 的 callback 函 数 在 内 部 又 会 调 
用 真正 的 native bridge 库 的 实现 (如 Intel 提 供 的 houdini library) 。 
° jni Æ 
这 是 需要 被 native bridge 处 理 的 目标 对 象 。 在 我 们 本 小 节 的 分 析 
范围 内 ， 特 指 需要 在 x86 平 台 上 运行 的 ARM 动 态 链接 库 





21.13 ”Android 应 用 程序 调试 原理 解析 
调试 是 应 用 程序 训 开 发 过 程 中 不 可 或 缺 的 一 个 环节 ， 相 信 读 者 们 都 不 
会 陌生 。 得 蔓 于 各 类 IDE 工具 (Eclipse, Intell id=) 的 辅助 ， 开 发 


入 员 调 坛 Android 应 用 程序 可 以 说 是 相当 简单 的 以 Android Studio 为 
例 ， 调 试 Java 代 码 的 步骤 如 下 : 


Step1， 在 Android Studio 中 打开 你 的 工程 ; 

Step2， 在 需要 调试 的 地 方 打 上 断 点 ; 

Step3.， 单 击 Debug 按 钮 ; 

Step4， 选 择 需要 运行 应 用 程序 的 目标 设备 (0ptional) ; 
Step5， 开 始 调试 。 

效果 如 图 21-70 所 示 。 
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全 图 21-70 Android 应 用 程序 调试 效果 


当然 ， 这 看 似 简单 的 几 个 步骤 背后 隐藏 的 技术 细节 却 是 很 复杂 的 。 
我 们 将 在 本 小 节 对 此 展开 分 析 。 


21.13.1 Java 代码 调试 与 JDWP 协 议 


JDWP， 即 Java Debug Wire Protoco1， 是 被 调试 的 目标 Java 程 序 与 
调试 器 之 则 的 一 种 协议 规范 ， 在 Java 世 界 中 被 广泛 应 用 。 它 在 Android 
中 的 主体 框架 如 图 21-71 所 示 。 


JDWP-Compliant Targeted 
debugger Application 


Android Device 





全 图 21-71 Java 调试 原理 简 图 


在 以 JDWP 为 基础 的 调试 器 方案 中 ， 主 要 会 涉及 如 下 几 个 角色 (以 
Android 虚 拟 机 为 例 ) : 


e JDWP-Compliant Debugger 
调试 器 通常 运行 于 PC 端 ， 它 会 借助 于 JDWP Agent 来 控制 运行 于 设备 
端的 目标 程序 。 我 们 知道 ， 开 发 机 与 设备 的 连接 既 有 可 能 是 TCP/IP 的 方 
sh CAUSE) ， 也 有 可 能 是 USB 等 硬件 连接 线 的 方式 。 在 我 们 接 下 来 
的 分 析 中 ， 主 要 侧重 后 面 这 种 情况 。 
e JDWP Agent 


Agent 和 目标 程序 一 样 ， 都 运行 于 设备 端的 虚拟 机 中 ， 并 且 与 调试 


器 之 间 以 JDWP 规 范 进行 数据 传输 。 
。 目标 程序 


目标 程序 即 是 调试 对 象 ， 它 受 JDWP Agent 的 控制 ， 而 后 者 则 接受 来 
EiDebugger Client 的 指令 。 


e ADBD 


即 ADB Daemon 。 它 是 ADB 在 设备 端的 监护 程序 ， 负 责 开 发 平台 与 设 
备 之 间 的 通信 ， mated 村 程 也 同样 需要 ADBD 


下 面 我 们 以 一 个 典型 的 Android 平 台 上 Java 程 序 的 调试 过 程 为 范例 
来 做 细 化 讲解 。 


Step1@Android 平 台 Java 程 序 的 调试 过 程 一 一 ADBD 初 始 化 阶段 


当 ADBD 启 动 的 时候， 它 会 创建 一 个 名 为 “\0jdwp-control” 的 Unix 
Server Socket， 这 是 万 里 长 征 的 第 一 步 。 如 果 一 个 Java 程 序 需要 被 调 
试 的 话 ， 那 么 虚拟 机 会 启动 一 个 新 的 JDWP 的 Daemon 线 程 ， 后 者 将 负责 
与 “\0jdwp-control” 建 立 连接 。 这 个 连接 会 一 直 保 持 活跃 状态 ， 直 到 
JDWP 进 程 终止 。 


因为 调试 的 进程 有 可 能 不 止 一 个 ， 所 以 ADBD 内 部 维护 着 当前 活跃 的 
JDWP 进 程 的 一 个 列表 。ADBD 可 以 通过 “device:debug-ports” 和 它们 进 
行 通信 。 从 源码 的 角度 来 分 析 ，ADBD 会 在 adb_main 中 调用 init_jdwp 来 
完成 对 jdwp 的 初始 化 动作 : 


/*/system/core/adb/jdwp_service.cpp*/ 
int init_jdwp(void) 


{ 
_jdwp_list.next = &_jdwp_list; 
_jdwp_list.prev = &_jdwp_list; 
return jdwp_control_init( &_jdwp_control, JDWP_CONTROL_NAME, 
JDWP_CONTROL_NAME_LEN ); 
} 


其 中 _jdwp_1ist 是 当前 可 调试 进程 的 存储 列表 ; 
JDWP _CONTROL_NAMEXt RYAN “\Ojdwp- control”。 另 外 ， 


jdwp_control_init 负 责 创 建 一 个 AF_UNIX 类 型 的 socket， 并 监听 来 自 
JDWP Agent 的 连接 请 求 。 


Step2@Android 平 台 Java 程 序 的 调试 过 程 。 被 调试 的 目标 Android 应 
用 工程 ， 将 通过 如 下 命令 来 启动 : 


am start -D -n "com.example.hellojni/com.example.hellojni.HelloJn 
intent.action.MAIN -c android.intent.category.LAUNCHER 


这 里 的 “-D” 参 数 是 一 个 关键 点 ， 它 表示 我 们 希望 开启 应 用 程序 的 
调试 状态 。 以 这 种 状态 启动 的 App 在 启动 过 ED 
Debugger 的 Attach 请 求 。 


Step3@Android 平 台 Java 程 序 的 调试 过 程 ， 在 Art 虚 拟 机 中 ， 当 应 用 
程序 启动 后 ， 会 由 Runtime 在 DidForkFromZygote 中 负责 启动 一 个 JDWP 线 


/*art/runtime/runtime.cc*/ 
void Runtime: :DidForkFromZygote(JNIEnv* env, NativeBridgeAction a 


Dbg: :StartJdwp(); 
} 


Runtime 使 用 专门 的 管理 类 Dbg 来 支持 Debugger 功 能 。Dbg 内 部 维护 
着 一 个 名 为 gJdwpState 的 全 局 JdwpState 变 量 ， 后 者 用 于 记录 JDWP 的 当 
前 状态 : 


/*art/runtime/Debugger.cc*/ 
void Dbg::StartJdwp() { 





if (!gJdwpAllowed || !IsJdwpConfigured()) {// 程 序 当 前 是 否 符合 调试 条 
// No JDWP for you! 
return; 

} 


gJdwpState = JDWP::JdwpState: :Create(&gJdwpOptions); 


当前 程序 如 果 要 进入 调试 环境 ， 需 要 同时 满足 下 面 两 个 条 件 : 


e oJdwpAllowed 


这 个 变量 用 于 表示 Zygote 是 否 允许 调试 。 又 可 以 分 为 如 下 两 种 情 
oe: 


Casel: 系统 变量 ro. debuggable 为 1， 这 种 情况 下 表示 所 有 的 程序 
都 可 以 被 调试 ， 因 而 在 量 产 的 设备 中 是 不 允许 的 。 


Case2: 当 系 统 请 求 Zygote 孵 化 一 个 新 进程 时 ， 可 以 通过 “一 
enable-debugger” 来 显 式 地 要 求 后 者 将 目标 进程 置 为 可 调试 状态 。 这 
个 请 求 的 原始 来 源 就 是 AndroidManifest 中 的 android:debuggable 配 
置 ，Android 系 统 在 ActivityManagerService 中 会 对 此 进行 处 理 ， 相 应 
代码 段 如 下 所 示 : 


/*frameworks/base/services/core/java/com/android/server/am/Activi 
private final void startProcessLocked(ProcessRecord app, String h 
hostingNameStr, String abiOverride, String entryPoint, String[ ] 
if ((app.info.flags & ApplicationInfo.FLAG_DEBUGGABLE 

debugFlags |= Zygote.DEBUG_ENABLE_DEBUGGER; 
// Also turn on CheckJNI for debuggable apps. It' 

// awkward to turn on otherwise. 
debugFlags |= Zygote.DEBUG_ENABLE_CHECKJNI; 





e IsJdwpConfiguredik |E] 44 KH E 


这 个 函数 用 于 查询 jdwp 是 否 已 经 配置 完成 。 正 常情 况 下 ，runtime 
会 在 初始 化 时 通过 Dbg: :ConfigureJdwp 来 执行 jdwp 的 配置 工作 。 


只 有 上 述 两 个 条 件 都 满足 的 情况 下 ，Dbg 才 会 创建 一 个 JdwpState 变 
量 。 下 面 我 们 再 分 析 一 下 JDWP: : JdwpState: :Create 这 个 函数 ， 并 重点 
了 解 它 是 如 何 与 Adb 建 立 关 联 的 : 


/*art/runtime/jdwp/jdwp_main.cc*/ 
JdwpState* JdwpState::Create(const JdwpOptions* options) { 
Thread* self = Thread::Current(); 
Locks: :mutator_lock_->AssertNotHeld(self); 
std: :unique_ptr<JdwpState> state(new JdwpState(options)); 
switch (options->transport) { 
case kJdwpTransportSocket: 
InitSocketTransport(state.get(), options); 
break; 
#ifdef HAVE_ANDROID_OS 


case kJdwpTransportAndroidAdb: 
InitAdbTransport(state.get(), options); 


break; 
#endif 
default: 
LOG(FATAL) << "Unknown transport: " << options->transport; 
} 
CHECK_PTHREAD_CALL(pthread_create, (&state->pthread_, nullptr 
state.get()),"JDWP thread"); 
上 








if (options->suspend) {/*suspend="y "| 意味 着 需要 等 待 直到 debugger 成 功 
接 debugger 成 功 后 才 人 允许 程序 继续 往 下 运行 */ 
{ 











ScopedThreadStateChange tsc(self, kwaitingForDebuggerToAtta 
MutexLock attach_locker(self, state->attach_lock_); 


while (state->debug_thread_id_ == 0) { 
state->attach_cond_.Wait(self); 
} 
} 
} 
return state.release(); 
} 


在 讲解 上 述 这 个 函数 之 前 ， 我 们 先 来 补充 一 些 背 景 知识 。 


Android 虚 拟 机 和 大 部 Va 样 ， 它 们 都 提供 了 若干 配置 
参数 来 允许 用 户 对 调试 器 进行 


Android 虚 拟 机 中 的 调试 器 支持 的 核心 选项 如 表 21-14 所 示 。 


表 21-14 ”支持 的 核心 选项 


Options Description 


Communication transport mechanism. 支 持 以 下 两 种 类 


型 





transport fle TCP/IP Sockets 即 dt_socket。 璧 如 模拟 器 通常 情况 下 
就 是 以 TCP/P 的 方式 进行 通信 的 
e Over USB through ADB 即 dt_android_adb。 开 发 机 与 
Android 真 机 设备 以 USB 线 连接 后 ， 可 以 通过 ADB 进 
行 通信 


默认 值 “n” 这 个 选项 指明 虚拟 机 要 以 Client 或 者 Server 
的 方式 运行 。 如 果 是 后 者 ， 那 么 它 会 等 待 debugger 发 
起 的 连接 请 求 ，Client 的 情况 正好 相反 ， 它 需要 主动 
去 连接 debugger 


~ 
默认 值 “n” 人 简单 来 讲 就 是 虚拟 机 在 执行 程序 代码 之 前 
是 否 要 进入 挂 起 状态 。 如 果 设 置 为 *y”， 那 么 表明 虚 
suspend 上 拟 机 在 执行 程序 代码 前 会 先 处 于 挂 起 状态 ， 以 便 等 待 
= 





来 自 debugger 的 连接 (或 者 虚拟 机 主动 完成 与 
debugger 的 连接 一 一 取决 于 上 面 的 server 模 式 ) 


address 代 表 虚 拟 机 需要 连接 /或 者 监 昕 的 IP 地 址 以 及 
port 写 《只 对 dt_socket 的 情况 下 有 效 ) 。 当 server 模 式 
设置 为 “mn” 时 ，address 的 格式 是 hostname:port; 当 
server 模 式 设 置 为 “y” 时 ，address 的 格式 可 以 是 
hostname:port， 也 可 以 只 是 port。 如 果 port 是 0， 代 表 
当前 将 首先 尝试 在 端口 8000 进 行 监听 一 一 如 果 失 败 的 
话 ， 依 次 再 尝试 8001、8002 等 











用 于 显示 Usage 帮 助 信息 


onthrow, | 这 些 选 项 目前 会 被 虚拟 机 直接 忽略 掉 


oncaught, 
timeout 





下 面 是 一 个 Android 虚 拟 机 的 配置 范例 : 


-agentlib: jdwp=transport=dt_android_adb, suspend=y,server=y -cp /d 


它 代表 虚拟 机 将 开局 debugging 功 能 ; 并 作为 服务 端 来 等 待 客 户 端 
的 连接 请 求 ; 同时 连接 通道 采用 的 是 adb。 


我 们 再 回 过 头 来 分 析 JdwpState: :Create 国 数 。 首 先 需 要 根据 
transport 类 型 的 不 同 来 完成 两 种 情况 下 的 初始 化 ， 即 
InitSocketTransport 和 1nitAdbTransport。 对 于 前 一 种 情况 ， 
JdwpState 中 的 成 员 变 量 netState 将 是 一 个 JdwpSocketState 对 象 ; 而 如 
果 是 Adb Transport， 则 对 应 的 是 JdwpAdbState 这 两 种 State 的 基 类 
都 是 JdwpNetStateBase。 根 据 表 21-14 中 的 描述 ， 如 果 VM 是 Server 的 
话 ， 那 么 它 的 Port 端 口 要 么 来 源 于 用 户 的 特别 指定 〈 保 存在 
Jdwp0ptions 中 ) ， 要 么 从 Port 8000 开 始 尝 试 ， 直 到 最 大 值 8040 为 止 。 


Create 最 重要 的 任务 是 启动 一 个 新 线程 “JDWP Thread”， 对 应 的 
AFH pk A FEStartUdwoThread. BW Roptions P48 SF suspend=y, 那么 当 
前 线程 需要 等 待 JDWP Thread 完 成 与 Debugger 的 通信 连接 后 才能 继续 往 
下 执行 。 因 而 当前 线程 会 在 attach_cond_ 上 等 待 ， 而 JDWP 则 需要 在 完成 
操作 后 主动 发 信号 给 它 以 解除 等 待 。 


StartJdwpThread 将 进一步 调用 JdwpState: :Run 来 开展 具体 工作 。 
而 且 对 于 adb 这 种 情况 ， 事 实 上 采用 的 都 是 server=y 的 配置 ， 因 而 完成 
与 ADBD 通 信任 务 的 载体 函数 是 JdwpAdbState: : Accept。 根 据 我 们 前 面 
讲解 的 内 容 ， 不 难 推断 出 Accept 将 利用 名 为 “\0jdwp-control” 的 Unix 
Socket 与 ADBD 建 立 连 接 ， 并 且 在 成 功 后 发 送 当前 进程 1D 给 对 方 。 下 一 个 
Step 中 我 们 将 进一步 分 析 ADBD 如 何 处 理 VM 的 JDWP 连 接 请 求 。 


Step4@Android 平 台 Java 程 序 的 调试 过 程 . ADBD 中 响应 JDWP 连 接 请 
求 的 具体 函数 是 jdwp_process_event。 如 果 接 收 到 的 P1D 经 过 解析 后 确 
认 格 式 无 误 的 话 ，ADBD 会 通过 jdwp_process_1ist_updated 来 更 新 自己 
维护 的 一 个 进程 列表 。 紧 接着 程序 分 为 两 个 方向 : 


e VM JDWP Thread 


如 果 是 suspend=y 的 情况 ， 则 一 直 等 待 直到 完成 与 debugger 的 连接 ; 
否则 应 用 程序 继续 执行 代码 。 





e ADBD 


ADBD debugger #Udwp Thread 之 间 的 “媒人 ”， 它 会 响应 来 自 
debugger 的 请 求 ， 并 为 它们 牵线 搭桥 


Step5@Android 平 台 Java 程 序 的 调试 过 程 。 经 过 前 面 步骤 的 努力 ， 
此 时 已 经 是 “万 事 具 备 ， 只 欠 东 风 ” 了 一 一 Debugger 就 是 这 阵 东 风 。 


运行 于 开发 机 之 上 的 Debugger 如 果 想 连接 到 目标 JVM 中 的 Jdwp 
Thread， 它 首先 需要 使 用 如 下 命令 : 


adb forward tcp:<hostport> jdwp:<pid> 


当 adbd 收 到 上 述 命令 时 ， 它 将 执行 如 下 操作 : 


/*system/core/adb/services.cpp*/ 
int service_to_fd(const char *name) 


7 } else if (!strncmp(name, "jdwp:", 5)) { 
ret = create_jdwp_connection_fd(atoi(namet5) ); 


因为 “jdwp:” 属 于 特殊 服务 标志 ， 所 以 ADB 可 以 很 容易 地 把 它 转发 
给 Jdwp Service， 后 者 对 此 的 核心 处 理 远 辑 是 : 先 从 ADBD 维 护 的 
_jdwp_l1ist 中 查找 到 正确 的 JDWP Process， 在 此 基础 上 调用 
adb socketpair 产 生 一 对 SocketpPair 。SocketPair 是 一 种 全 双 工 的 通信 
机 制 ， 可 以 保证 通信 双方 的 同时 读 和 写 操作 。 其 中 第 1 个 Socket 将 与 ADB 
的 local socket 进 行 绑 定 ; 而 另 一 个 socket 则 发 送 给 JDWP Thread (Hk 
时 正 处 于 ReceiveClientFd 的 状态 ) 。JDWP Thread 在 后 续 操 作 中 就 可 以 
利用 这 个 socket 摘 述 符 和 debugger 建 立 直 接 的 数据 通信 〈 包 括 JDWP- 
Handshake、 彼 此 间 的 调试 命令 等 ) 了。 图 21-72 所 示 是 对 Socket 连 接 关 
系 的 摘 述 图 。 
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三 


全 图 21-72 ADB Transport 下 的 Socket 连 接 关系 图 


至 此 ， 位 于 开发 机 器 上 的 Debugger 就 已 经 和 运行 于 设备 端 JVM 之 中 
的 JDWP Thread 建 立 起 关联 了。 假如 是 suspend=y 的 情况 ，JDWP 需 要 主动 
发 送信 号 给 JVM 主 线程 ， 以 便 后 者 “处 于 等 待 状态 ， 此 时 U1 穷 面 上 也 会 
有 相应 提示 ) 可 以 恢复 运行 。 应 用 程序 进入 调试 状态 后 ，Debugger 按 照 
oe Thread 发 送 命令 ， 以 控制 程序 执行 单 步 、 断 点 
等 调试 操作 。 


接 下 来 我 们 以 单 步 调试 为 例子 ， 进 一 步 分 析 JDWP、Debugger 和 Art 
之 间 的 关系 。 


图 21-73 所 示 是 它们 的 关系 简 图 。 
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全 图 21-73 关系 图 


要 注意 区 分 这 里 的 Instrumentation 和 我 们 在 做 Android 应 用 程序 单 


元 测试 时 所 使 用 的 Instrumentat ioninvE22. ASA “UA 
控 ”Android 系 统 与 应 用 程序 之 间 的 通信 ， 从 而 实现 类 似 于 自信 盒 测 试 这 
种 需要 深入 App 内 部 来 完成 的 任务 。 


图 21-73 中 的 Instrumentation 有 异曲同工 之 妙 ， 只 不 过 目标 对 象 变 
成 了 Art 虚 拟 机 。1nstrumentation 提 供 了 一 个 AddListener 接 口 ， 意 味 
着 任何 对 虚拟 机 运行 过 程 中 相关 数据 感 SENEE 以 请 求 “ 监 
听 ”。 壁 如 除了 Debugger 之 外 ， 男 一 个 重要 的 Instrumentation 应 用 就 
是 Trace， 它 是 SDK 中 Trace Viewer 的 实现 基础 : 


/*art/runtime/Instrumentation.cc*/ 
void Instrumentation: :AddListener(InstrumentationListener* listen 


ABZ et ALAB ese SPREE BBO ANE? 这 是 通过 上 述 
AddLi stener 的 最 后 一 个 参数 ， 即 events 来 表达 的 : 


enum InstrumentationEvent { 
kMethodEntered = 0x1, / 1 By BEA 


kMethodExited = 0x2, / / PK BOR E 
kMethodUnwind = 0x4, // 

kDexPcMoved = 0x8, /VPC 指针 发 生 了 变化 
kFieldRead = 0x10, // 域 读 取 


kFieldwritten = 0x20, // 域 写 入 
kExceptionCaught = 0x40，// 异 常 发 生 
kBackwardBranch = 0x80, // 

】 


不 难 理解 ，Debugger 的 工作 要 涵盖 3 个 方面 : 


e 初始 化 ; 
e 利用 Instrumentation 获 取 虚 拟 机 的 实时 运行 状态 ; 
。 根据 开 发 者 的 调试 请 求 来 控制 虚拟 机 的 执行 情况 


针对 单 步 调试 的 场景 ，Debugger 在 初始 化 过 程 中 会 创建 一 个 
JdwpState 对 象 ， 用 于 管理 与 Jdwp 协 议 相 关 的 事情 。 同 时 ， 它 也 负责 调 
用 lInstrumentation::AddListener 来 为 自己 添加 感 兴趣 的 
InstrumentationEvent 壁 如 与 单 步调 试 相 关联 的 kDexPcMoved。 


调试 过 程 中 Art 虚 拟 机 需要 运行 于 解释 器 模式 下 。Art 中 的 
Interpreter 有 两 种 实现 类 型 (Android N 版 本 中 又 增加 了 一 种 汇编 解释 





2) ， 即 kSwitchlmp1 和 kComputedGotolmp1IKind。 不 过 无 论 哪 一 种 解释 


器 ， 它 在 每 执行 一 条 字 节 码 命令 时 都 会 调用 类 似 如 下 的 语句 : 


if(UNLIKELY(instrumentation->HasDexPcListeners())) { 
instrumentation->DexPcMovedEvent(self, 
shadow_frame.GetThisObject(code_item- 
shadow_frame.GetMethod(),dex_pc); 
} 


UNLIKELY 是 GCC 提供 的 一 个 有 趣 的 功能 ， 用 于 提高 CPU 的 执行 效率 。 
简单 来 说 ， 为 了 使 OPU 的 Pipel ine 尽 可 能 处 于 满 负 荷 的 状态 ， 我 们 可 以 
设计 让 它 提 前 加 载 下 一 条 要 执行 的 语句 。 但 是 在 某 些 情况 下 ， 这 种 设计 

没有 起 到 应 有 的 效果 。 例 如 一 个 if (condition). .else 语 句 ， 在 条 件 
没有 确定 之 前 ， 我 们 并 不 能 确定 程序 在 运行 时 会 走 哪 个 分 支 ， 这 样 导 致 
的 结果 就 是 CPU 提前 加 载 的 语句 很 可 能 用 不 上 。 因 而 GCC 提供 了 LIKELY 和 
UNLIKELY 等 属性 ， 这 样 开发 人 员 可 以 “帮助 ”CPU 来 更 精准 地 判断 出 应 
该 提前 加 载 的 指令 。 


只 要 注册 了 Listener， 那 么 HasDexPcL isteners 就 会 返回 true。 这 
种 情况 下 会 调用 DexPcMoved Event， 这 个 函数 的 主要 工作 是 遍历 
Instrumentation 中 所 有 注册 了 的 对 象 。Debugger 中 重 载 了 DexPcMoved 
哨 数 ， 后 者 的 核心 关键 在 于 UpdateDebugger: 


/*art/runtime/Debugger.cc*/ 

void Dbg: :UpdateDebugger(Thread* thread, mirror::0bject* this_obj 
ArtMethod* m, uint32_t dex_pc, 
int event_flags, const JValue* return_value) { 


if (IsBreakpoint(m, dex_pc)) {// 程 序 当 前 执行 到 断 点 了 吗 
event_flags |= kBreakpoint; 


} 


const SingleStepControl* single_ step_control = thread->GetSingl 
if (single_step_control != nullptr) { 
CHECK( !m->IsNative()); 
if (single_step_control->GetStepDepth() == JDWP::SD_INTO) {... 
} else if (Single_step_control->GetStepDepth() == JDWP::SD_OV 
int stack_depth = GetStackDepth(thread) ;// 当 前 线程 的 函数 栈 


if (stack_depth < single_ step_control->GetStackDepth()) { 
// Popped up one or more frames, always trigger. 
event_flags |= kSingleStep; 
VLOG(jdwp) << "SS method pop"; 


} else if (stack_depth == single_step_control->GetStackDept 

// Same depth, see if we moved. 

if (single_step_control->GetStepSize() == JDWP::SS MIN) { 
event_flags |= kSingleStep; 
VLOG(jdwp) << "SS new instruction"; 

} else if (Single_step_control->ContainsDexPc(dex_pc)) { 
event_flags |= kSingleStep; 
VLOG(jdwp) << "SS new line"; 

} 


} 
} else { 
CHECK_EQ(Single_step_control->GetStepDepth(), JDWP::SD_OUT) 


} 
} 


// If there's something interesting going on, see if it matches 
// of the debugger filters. 
if (event_flags != 0) { 

Dbg: :PostLocationEvent(m, dex_pc, this_object, event_flags, r 
} 


} 


大 家 试想 一 下 ， 开 发 人 员 在 1DE 〈 例 如 Android Studio, Eclipse) 
中 调试 程序 时 ， 通 常会 涉及 哪些 操作 呢 ? 


BTR 
譬如 打 断 点 、 取 消 断 点 、 查 看 断 点 等 。 
e Step Into 
单 步 执行 ， 而 且 会 进入 被 调用 的 函数 。 
。 Step Over 
单 步 执 行 ， 但 不 会 进入 被 调用 的 函数 。 
e Step Out 
执行 完 本 函数 剩余 的 代码 ， 并 返回 到 调用 者 函数 中 。 


开发 人 员 在 1DE 中 所 做 的 上 述 操作 ， 都 会 通过 Jdwp 协 议 实时 发 送 给 
设备 端 ， 并 由 后 者 做 好 记录 。 对 于 单 步调 试 来 说 ， 开 发 者 的 不 少 请 求 是 
由 Thread 〈 单 步调 试 是 针对 某 个 线程 环境 执行 的 ， 因 而 是 线程 相关 的 ) 
内 部 的 一 个 SingleStepContro1 对 象 来 负责 管理 ， 外 界 可 以 通过 
GetSingleStepControl 访 问 它 。 


有 了 这 些 背景 我 们 理解 UpdateDebugger 就 简单 多 了 。 这 个 函数 的 核 
心思 想 就 是 判断 程序 是 否 已 经 执行 到 了 某 个 我 们 “ 感 兴趣 ”的 关键 点 ， 
包括 开发 者 设置 的 BreakPoint, 开发 者 Steplnto、Step0ver 、Step0ut 命 
令 所 对 应 的 目标 位 置 等 。 针 对 3 种 Step 操 作 的 处 理 过 程 是 类 似 的 ， 我 们 
结合 Step0ver 来 讲解 一 下 上 述 UpdateDebugger 函 数 的 代码 逻辑 : 如 果 当 
前 的 函数 堆栈 深度 小 于 原先 的 深度 ， 说 明 程 序 已 经 从 子 函 数 中 返回 来 
了 ， 因 而 event_flags 会 被 设置 为 kSingleStep; 否则 ， a de 
度 一 样 ， 那 么 有 可 能 是 Step0ver ， 即 它们 的 代码 行 数 发 生 了 变化 。 一 旦 
这 些 “ 兴 趣 点 ”被 发 掘 出 来 ， ee 
步 处 理 。 这 个 函数 的 核心 工作 有 两 个 ， 其 一 是 向 Jdwp 的 另 一 方 〈 比 如 
IDE) 发 送 消息 ， 告 知 对 方 最 新 的 状态 ; 其 二 是 根据 Suspend Pol icy 来 
判断 当前 是 否 需要 挂 起 所 有 (ABD) 虚拟 机 线程 。 


这 样 一 来 整个 调试 过 JDWP 的 基本 原 
理 ， 断 点 / 单 步 操作 的 双方 交互 等 内 容 就 讲解 完成 了 。 不 过 JDWP 是 一 
相对 成 熟 的 调试 协议 ， 其 中 还 包含 了 很 多 其 他 细节 。 建 议 读 者 可 以 自行 
查阅 Java 官 方 发 布 的 JDWP 规 范 ， 并 结合 Android 虚 拟 机 的 具体 实现 来 做 
更 深入 的 分 析 。 








21.13.2 Native 代码 调试 


Android 系 统 既 支持 Java 语 言 ， 同 时 也 允许 开发 者 使 用 C/C++ 等 
Native 语 言 来 编写 程序 。 所 以 开发 人 员 不 可 避免 地 需要 一 个 基于 Native 
语言 的 调试 环境 。 


随 着 Android 放 弃 Eclipse ADT， 转 而 投向 基于 lntelliy 的 Android 
Studio 的 怀抱 ， 越 来 越 多 的 开发 者 开始 采用 这 一 新 工具 来 开展 项 目 。 客 
观 来 讲 ，Android Studio 相 对 于 它 的 “前 辈 们 ”确实 有 其 特色 所 在 。 但 
它 毕 竞 还 “ 太 年 轻 ”， 在 不 少 方面 还 不 够 “成 熟 稳定 ”。 壁 如 针对 
Native 代 码 的 调试 ，Android Studio 虽 然 在 最 新 的 版 本 中 已 经 支持 ， 但 
Android Studio 对 此 也 并 不 避讳 ， 在 其 界面 上 会 有 如 
下 提示 : 


NDK support is an experimental feature and all use cases are not yet supported. 


所 有 与 NDK 相 关 的 功能 都 仍 处 于 实验 阶段 一 一 这 或 许 也 是 不 少 开发 
者 反映 Android Studio“ 坑 ”很 多 的 原因 。 


即便 如 此 ，Android 的 NDK 调 试 机 制 还 是 有 不 少 地 方 值得 大 家 学 习 。 
接 下 来 我 们 先 通 过 NDK 的 典型 调试 流程 来 让 读者 对 如 何 利用 Android 
Studio 调 试 Native 代 码 有 一 个 直观 的 认识 “ 注 : 调试 Native 代 码 有 很 多 
ae 大 家 可 以 根据 实际 项 目 需求 选择 最 
= s 方案 o 


Step1， 新 建 Android Application 工 程 ; 
Step2， 添 加 JN1 源 文件 ， 以 及 其 他 C/C++ 文件 。 


在 Android Studio 中 添加 C/C++ 文件 有 很 多 种 途径 。 在 早期 版 本 
中 ， 开 发 者 需要 先 手工 生成 Class 文 件 ， 再 利用 javah 生 成 C/C++ 的 头 文 
件 ， 然 后 才能 编辑 源 代 码 。 这 种 手工 配置 的 方式 既 繁琐 又 浪费 时 间 一 一 
Android Studio 显 然 也 意识 到 了 这 点 ， 所 以 它 正 尝试 利用 Gradle 来 为 开 
发 者 提供 更 为 便捷 的 实现 方式 。 


可 能 是 因为 上 述 这 项 功能 还 处 于 实验 阶段 ， 所 以 事实 上 Gradle 配 置 
起 来 也 很 麻烦 。 具 体 过 程 大 家 可 以 参考 官方 的 详细 介绍 : 


http://tools.android.com/tech-docs/new-build-system/gradle-experi 


配置 完 Gradle 之 后 ， 接 下 来 我 们 就 可 以 创建 JNI 目 录 了 ， 如 图 21-74 
所 示 。 


然后 在 jni 目 录 下 创建 6/C++ 源 文件 ， 示 例如 图 21-75 所 示 。 
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全 图 21-74 JNI 目 录 
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全 图 21-75 示例 


完成 上 述 这 些 工 作 后 ， 我 们 就 可 以 根据 项 目的 具体 需要 来 添加 和 编 
写 C/C++ 代 码 了 。 如 果 希 望 运行 代码 的 话 ， 直 接 使 用 Android Studio 的 
Run 功 能 就 可 以 了 ; 如 果 想 调试 代码 ， 还 需要 做 一 下 Android Native 
面 的 配置 ， 示 例如 图 21-76 所 示 。 
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A 21-76 配置 


最 终 的 调试 效果 如 图 21-77 所 示 。 
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全 图 21-77 Android Native 应 用 程序 调试 效果 


了 解 了 Nat ive 程 序 的 典型 调试 流程 后 ， 我 们 再 来 分 析 上 述 过 程 中 所 
涉及 的 内 部 原理 。 


Android Studio 中 同时 支持 两 种 C/C++ 调试 器 ， 即 GDB 和 LLDB。 不 过 


无 论 是 哪 种 调试 器 ， 它 们 的 基本 原理 是 类 似 的 。 所 以 我 们 选取 LLDB 这 个 
新 型 的 调试 器 为 例 来 做 细 化 讲解 。 


通过 LLDB 调 试 Android Native Application 的 原理 简 图 如 图 21-78 
所 示 。 


Targeted 
LLDB Client LLDB Server a 





Android Device 


全 图 21-78 Android Native Debug 


我 们 可 以 从 Android Studio 输 出 的 Log 中 ， 得 出 整个 调试 环节 将 涉 
及 的 所 有 adb 命 令 ， 从 中 就 可 以 霸 探 出 交互 过 程 了 : 


## 命 令 行 1: 
DEVICE SHELL COMMAND: am force-stop com.example.hellojni 
Launching application: com.example.hellojni/com.example.hellojni. 


HHH AT ST 2: 

DEVICE SHELL COMMAND: am start -D -n 
"com.example.hellojni/com.example.hellojni.HelloJni" -a android.i 
### 命 令 行 3 : 

DEVICE SHELL COMMAND: run-as com.example.hellojni mkdir /data/dat 
### 命 令 行 4: 





DEVICE SHELL COMMAND: run-as com.example.hellojni mkdir /data/dat 
bin 

### 命 令 行 5: 

DEVICE SHELL COMMAND: cat /data/local/tmp/lldb-server | run-as co 
data/com.example.hellojni/lldb/bin/lldb-server' 

Starting: Intent { act=android.intent.action.MAIN cat=[android.in 


HHH TT S476: 

DEVICE SHELL COMMAND: cat /data/local/tmp/start_lldb_server.sh | 
700 /data/data/com.example.hellojni/lldb/bin/start_lldb_server.sh 
### 命 令 行 7: 

Starting LLDB server: run-as com.example.hellojni /data/data/com. 
example.hellojni/lldb/tmp/platform-1454849510931.sock "lldb proce 


Now Launching Native Debug Session 
Debugger attached to process 5186 


从 上 述 可 以 看 到 ， 整 个 过 程 涉及 的 命令 种 类 和 数量 都 不 少 。 我 们 接 
下 来 对 它们 逐一 进行 讲解 。 


命令 行 1: 


DEVICE SHELL COMMAND: am force-stop com.example.hellojni 
Launching application: com.example.hellojni/com.example.hellojni. 


命令 行 2: 


DEVICE SHELL COMMAND: am start -D -n 
"com.example.hellojni/com.example.hellojni.HelloJni" -a android.i 


上 述 这 两 条 命令 比较 简单 ， 它 们 的 任务 是 通过 /system/b in/am 这 个 
she11 脚 本 来 启动 目标 进程 Hel loJni 的 Main Activity. 


而 第 3 条 命令 行 就 没有 那么 好 理解 了 : 
DEVICE SHELL COMMAND: run-as com.example.hellojni mkdir /data/dat 
主要 的 疑问 如 下 : 


e tun-as 是 什么 ? 
e /data/data/com.example.hellojni/lldb 是 hellojni 的 私有 目录 ， 那 么 shell 
为 什么 有 权限 创建 它 呢 ? 


我 们 知道 ，Linux 平 台 上 的 调试 系统 普遍 借助 于 ptrace 来 实现 。 但 
是 一 个 不 容 忽视 的 问题 是 一 一 ptrace 并 非 “ 等 闲 之 辈 ”， 它 需要 特殊 
的 权限 才能 被 正常 使 用 。 那 么 gdb (或 者 LLDB) 在 没有 root 的 手机 上 如 
何 跨越 这 个 障碍 呢 ? 


总 体 来 说 ， 有 如 下 几 种 备 选 方案 : 
Solution1: 将 调试 所 用 的 手机 做 root 处 理 


这 不 但 是 最 “ 笨 ” 的 一 种 办 法 ， 而 且 也 显得 有 些 “ 旁 门 左 道 ”， 所 
以 绝对 不 会 是 Android 所 推崇 的 最 佳 方式 。 


Solution2: 让 GdbServer 与 被 调试 程序 运行 于 同一 个 进程 中 


由 于 Android 系 统 对 于 两 个 程序 运行 于 同一 个 进程 之 中 有 严格 的 门 
槛 限制， 所 以 这 也 不 会 是 我 们 的 首选 方式 。 


Solution3: 找 一 个 有 权限 的 “中 介 ” 帮 忙 搞定 这 个 事 


这 就 好 比 我 们 想 在 一 个 高 档 小 区 找 人 ， 无 奈 身 为 访客 没有 权限 随意 
进出 。 怎 么 办 呢 ? 大 家 的 第 一 反应 可 能 是 找 门卫 。 一 方面 门卫 是 小 区 对 
外 的 “接口 ”， 访 客 是 可 以 接触 到 的 ; 另 一 方面 他 们 也 有 正常 的 渠道 可 
以 联系 到 业主 。 这 样 一 来 问题 就 简单 了 : 只 要 我 们 能 提供 足够 的 信息 证 
明 自 己 “ 并 不 是 坏人 ”， 而 且 与 小 区 业主 确实 是 “有 关系 ”的 ， 那 么 就 
可 以 请 门卫 代为 传 话 ， 最 终 也 就 可 以 达到 让 “目标 业主 ” 现 身 的 目的 
Ta 


程序 run-as 的 作用 和 “门卫 ”有 点 类 似 。 它 的 权限 位 设置 如 图 21- 
79 所 示 。 


ft ishell@hwmt?:/ $ ls -1 /system/bin/run—as 





ruxr-x—-—-— root shell 9446 2616-61-21 21:21 run-as 
全 图 21-79 run-as 是 Native 调 试 成 功 的 关键 点 之 一 


由 图 21-79 可 见 ，run-as 的 0wner 虽 然 是 root， 但 所 属 的 群 组 却 是 
shel1。 这 样 设计 的 目的 就 是 让 我 们 (adb shell) 有 权限 〈she11 对 应 
的 权限 位 是 “r-x”) 来 调用 这 个 “门卫 ”， 从 而 保证 后 续 操 作 的 顺利 
开展 。 从 “run-as” 这 个 名 字 也 可 以 看 出 ， 它 表达 的 是 让 对 象 A 在 运行 


时 具有 和 对 象 B 相 同 的 某 种 属性 。 


那么 具体 是 指 哪 些 属 性 呢 ? 下 面 是 run-as 的 使 用 语法 : 


run-as <package-name> [--user <uid>] <command> [<args>] 


其 中 <package-name> 代 表 对 象 B 的 包 名 ; 《command> 代 表 对 象 A; 


<args> 则 表示 run-as 所 需 的 各 种 参数。 


那么 run-as 是 借助 了 什么 “魔法 棒 ” 来 让 对 象 A “脱胎 换 骨 ” 呢 ? 
事实 上 它 的 实现 原理 并 没有 那么 复杂 ， 简 单 而 言 就 是 run-as 会 迫使 


“command> 所 指示 的 对 象 A 以 对 象 B 的 User ID 来 运行 。 核 心 代码 实现 如 下 
所 示 : 


/*system/core/run-as/run-as.c*/ 
int main(int argc, char **argv) 


{ 


const char* pkgname; 

uid_t myuid, uid, gid, userAppId 
int commandArgvOfs = 2, userId = 
PackageInfo info; 

struct user_cap_header_struct capheader; 
struct user_cap_data_struct capdata[2]; 


= 0; 
0; 








/* 调用 run-as 的 必须 是 shell 或 者 root， 以 避免 它 被 滥用 的 情况 */ 
myuid = getuid(); 
if (myuid != AID_SHELL && myuid != AID_ROOT) { 
panic("only 'shell' or 'root' users can run this program\ 





memset(&capheader, ©, sizeof(capheader )); 

memset(&capdata, 0, sizeof(capdata) ); 

capheader.version = _LINUX_CAPABILITY_VERSION_3; 
capdata[CAP_TO_INDEX(CAP_SETUID)].effective |= CAP_TO_MASK(CA 
capdata[CAP_TO_INDEX(CAP_SETGID)].effective |= CAP_TO_MASK(CA 
capdata[CAP_TO_INDEX(CAP_SETUID)].permitted |= CAP_TO_MASK(CA 
capdata[CAP_TO_INDEX(CAP_SETGID)].permitted |= CAP_TO_MASK(CA 


/* 赋 予 run-as 自 身 SUID 和 SGID 的 权利 */ 
if (capset(&capheader, &capdata[0]) < 0) { 
panic("Could not set capabilities: %s\n", strerror(errno) 


} 
pkgname = argv[1];// 对 象 B 的 包 名 





























/* 处 理 用 户 通过 “-user7 主 动 提供 了 user id 的 情况 */ 
if ((argc >= 4) && !strcmp(argv[2], "--user")) { 
userId = atoi(argv[3]); 
if (userId < 0) 
panic("Negative user id %d is provided\n", userId); 
commandArgvOfs += 2; 








/* 根据 包 名 获取 到 相对 应 的 userId */ 

if (get_package_info(pkgname, userId, &info) < 0) { 
panic("Package '%s' is unknown\n", pkgname); 

} 


/* calculate user app ID. */ 
userAppId = (AID_USER * userId) + info.uid; 


/* 对 象 B 不 能 是 system package */ 
if (userAppId < AID_APP) { 
panic( "Package '%s' is not an application\n", pkgname); 


/* 对 象 B 必 须 已 经 设置 了 可 调试 标志 位 */ 
if (!info.isDebuggable) { 
panic("Package '%s' is not debuggable\n", pkgname); 


/* 检查 data 路 径 是 否 有 效 */ 

if (check_data_path(info.dataDir, userAppId) < 0) { 
panic("Package '%s' has corrupt installation\n", pkgname) 

} 


uid = gid = userAppId; 
if(setresgid(gid,gid,gid) || setresuid(uid,uid,uid)) { 
Eel at etree denied\n"); 
}// 通 过 setresgid 和 setresuid 保 证 run-as 上 共有 setuid 和 setgid 的 权利 ， 这 ; 














/* cd 进入 对 象 B 的 data 目 录 下 */ 
if (TEMP_FAILURE_RETRY(chdir(info.dataDir)) < 0) { 
panic("Could not cd to package's data directory: %s\n", Ss 


/* 运 行 对 象 A， 此 时 对 象 A 已 经 具有 对 象 B 的 User Id 了 */ 

if ((argc >= commandArgvOfs + 1) && 
(execvp(argv[commandArgvOfs], argv+commandArgvOfs) < 0)) 
panic( "exec failed for %s: %s\n", argv[commandArgvOfs], s 





/* Default exec shell. */ 
execlp("/system/bin/sh", "sh", NULL); 


panic("exec failed: %s\n", strerror(errno)); 


从 上 述 代码 段 的 注释 中 ， 读 者 们 应 该 已 经 发 现 了 如 下 几 个 实现 要 


IKK O 


。 ftun-as 的 权限 控制 


为 了 防止 run-as 被 滥用 ， 我 们 需要 对 用 户 身份 进行 验证 。 换 句 话 
说 ， 就 是 只 有 she11 和 root 才 有 资格 使 用 这 个 特殊 的 程序 ; 另外 ， 目 标 
对 象 B 不 可 以 是 System Package， 而 且 必 须 设置 了 debug 标 志 位 一 一 对 于 
Android 应 用 程序 来 说 ， 也 就 是 应 该 在 AndroidManifest. xm| 中 显 式 声明 
了 android:debuggable=true。 


e ftun-as 需 要 具备 setuid 和 seteid 的 权限 


我 们 在 本 书 安全 机 制 章节 中 会 对 Linux 平 台 下 的 各 权限 位 做 较为 详 
细 的 分 析 ， 和 希望 大 家 可 以 结合 起 来 阅读 。 与 Linux 中 passwd 作 法 不 同 的 
是 ，run-as 并 没有 给 文件 本 身 直接 设置 SUID 和 SG1D 权 限 位 ， 而 是 在 它 运 
行 时 再 通过 调用 capset 来 改变 自己 的 capacity。 一 旦 capset 成 功 后 ， 
run-as 就 有 权限 利用 setresuid 和 setresgid 来 设置 uid 和 和 gid 为 目标 对 象 
B 的 User 1D 和 Group IDS. 


。 tun-as 通 过 exec 系 列 API 来 调用 目标 对 象 A 


一 旦 run-as 的 当前 UID 和 G1D 已 经 被 设置 为 目标 对 象 B 后 ， 它 会 进 一 
步 利 用 execvp 和 execlp 等 AP1 来 加 载 和 运行 对 象 A。 

经 过 这 3 个 方面 的 努力 后 ， 对 象 A 在 运行 时 就 具有 目标 对 象 B 的 UID 
了 。 在 命令 行 3 这 个 场景 中 ， 就 是 mkdir 以 hellojni 的 U1D 运 行 后 ， 得 以 
创建 后 者 的 私人 目录 /data/data/com. example. hellojni/l|ldb. #447 
4 到 命令 行 6 的 原理 也 是 类 似 的 ， 我 们 就 不 歼 述 了 。 

命令 行 7: 


run-as com.example.hellojni 
/data/data/com.example.hellojni/lldb/bin/start_lldb_server.sh /da 


在 这 个 命令 中 ， 对 象 A 对 应 的 是 start_11db_server. sh， 目 标 对 象 B 
是 指 com. example. hellojni， 而 后 面 几 个 是 args 人 参数 。Android Studio 
在 执行 调试 之 前 ， 会 首先 将 一 些 文件 push 到 设备 的 临时 存储 空间 中 ， 如 
BARA: 





she 11@HM26145@1:/data/local/tmp $ ls 
com.example.hellojni 


lldb-server 
start_lldb_server.sh 





其 中 start 11db server. sh 的 核心 实现 如 下 : 
#!/system/bin/sh 


LLDB_DIR=$1 ###LLDB 的 工作 目录 是 /data/data/com.example.hellojni/1lldb 
BIN_DIR=$LLDB_DIR/bin 


LOG_DIR=$LLDB_DIR/1log 
TMP_DIR=$LLDB_DIR/tmp 


export LLDB_DEBUGSERVER_LOG_FILE=$LOG_DIR/gdb-server.log 
export LLDB_SERVER_LOG_CHANNELS="$3" 
export LLDB_DEBUGSERVER_DOMAINSOCKET_DIR=$TMP_DIR 


rm -r $TMP_DIR 
mkdir $TMP_DIR 
export TMPDIR=$TMP_DIR 


rm -r $LOG_DIR 
mkdir $LOG_DIR 


cd $TMP_DIR # change cwd 


# Send SIGTERM for all spawned processes. 
#trap "kill 0" SIGINT SIGTERM EXIT 


# lldb-server platform exits after debug session has been complet 
$BIN_DIR/lldb-server platform --listen $2 --log-file $LOG_DIR/pla 


这 个 脚本 的 最 后 一 行 负责 启动 11db-server， 并 在 platform- 
1454849510931. sock 端 口上 监听 事件 ， 保 证 后 续 调 试 操作 的 顺利 进行 。 
这 样 PC 端 〈 通 常 是 1DE) 和 设备 站 就 通过 LLDB 《或 者 GDB) 建立 起 关联 
了 ， 接 下 来 它们 只 需要 按照 规定 的 调试 协议 来 互相 通信 和 就 可 以 了 。 


当然 ， 关 于 11db-server 还 有 很 多 实现 细节 ， 和 譬如 它 是 如 何 与 1DE 配 
合 执行 单 步 调试 命令 的 ; 如 何 将 程序 当前 正在 执行 的 指令 与 源 代码 行 数 
实现 无 颖 对 接 的 ; 如 何 控制 目标 对 象 的 执行 逻辑 的 等 。 有 兴趣 的 读者 可 
以 自行 分 析 A0SP 工 程 中 /external/11db 里 的 源码 了 解 详情 。 


21.13.3 ”利用 GDB 调 试 Android Art 虚 拟 机 


相信 不 少 开 发 者 遇 到 过 Art 虚 拟 机 或 者 Android 系 统 服务 月 省 的 情 
况 。 虽 然 系 统 会 为 此 打印 出 一 个 BackTrace， 但 从 实践 经 验 来 看 光 靠 这 
些 信息 想 解 决 问题 可 以 说 是 “大 海 捞 针 ”。 那 么 我 们 是 否 还 有 更 好 的 办 
法 来 解决 Art 虚 拟 机 或 者 Android 自 身 服务 的 Bug 呢 ?答案 是 肯定 的 ， 那 
就 是 利用 调试 手段 来 跟踪 系统 的 内 部 实现 。 


前 两 个 小 节 我 们 所 讲解 的 调试 是 针对 应 用 程序 的 ， 其 中 Jdwp 适 用 于 
Java 语 言 ， 而 GDB 《和 LLDB〉 则 被 认为 是 Native Code 的 调试 利器 。 再 往 
深层 次 思考 一 下 ， 既 然 6DB 可 以 调试 本 地 代码 ， 而 且 是 基于 ptrace 这 类 
Linux 提 供 的 能 力 ， 那 么 理论 上 是 不 是 也 适用 于 Android 系 统 服务 (KH 
是 Art 虚 拟 机 ， 还 包括 Zygote、ServiceManager 等 ) 呢 ? 


本 小 节 我 们 就 来 验证 上 述 这 个 观点 是 否 正确 。 

事实 上 系统 程序 的 调试 原理 和 上 一 小 节 所 述 的 内 容 是 基本 类 似 的 ， 
区 别 在 于 应 用 程序 是 在 1DE (或 者 其 他 开发 环境 ) 中 发 起 的 调试 过 程 ， 
这 为 开发 人 员 节 省 了 很 多 手工 的 操作 。 

以 调试 Art 虚 拟 机 为 例 ， 典 型 步骤 如 下 : 

Step1. 准备 好 所 需 的 调试 器 程序 和 文件 。 包 括 : GDB Client, GDB 
Server, 、Symbols、 目 标 程序 等 。GDB 本 身 也 是 一 个 开源 的 项 目 ， 开 发 者 
如 果 有 兴趣 的 话 可 以 自行 下 载 并 编译 出 它 的 可 执行 文件 。 我 们 这 里 直接 
采用 Android 系 统 工程 中 提供 的 全 套 GDB 工 具 ， 所 在 目录 是 : 

AndroidRoot\prebui Its\gec\| inux-x86 


开发 人 员 需 要 根据 被 调试 对 象 所 属 的 具体 平台 来 选择 对 应 的 子 文件 
夹 ， 璧 如 arm、x86 等 。 


Step2. 将 GDB Server 推 送 到 设备 端 


如 果 是 Android 模 拟 器 ， 那 么 在 设备 的 /system/bin 目 录 下 已 经 保存 
了 gdbserver; 而 对 于 已 经 上 市 的 Android 设 备 ， 多 数 情况 下 这 个 Server 
端 程序 已 经 被 移 除 了 ， 此 时 我 们 需要 将 它 手工 推送 到 设备 端 

Step3. 利用 ps 命令 查找 需要 调用 的 目标 程序 的 P1D 值 


值得 一 提 的 是 ，GDB 既 支持 对 已 经 在 运行 的 程序 进行 调试 ， 同 时 也 
可 以 主动 启动 一 个 被 调试 程序 的 进程 实例 一 一 这 就 意味 着 它 可 以 控制 和 
调试 目标 进程 的 启动 过 程 。 


我 们 本 小 节 想 要 调试 的 对 象 是 Art 虚 拟 机 ， 并 且 知 道 它 是 以 
libart. so 的 形式 存在 的 ， 而 加 载 Art 库 的 进程 即 是 应 用 程序 本 身 。 或 者 
更 确切 的 说 ， 是 app_process (RAMANA sh SH ZyeotelR kE 
来 的 ， 而 后 者 则 又 是 基于 app_process 产 生 的 ) 。 


例如 我 们 可 以 选取 前 述 小 节 的 求 和 小 程序 为 调试 对 象 ， 如 下 所 示 : 


shell@hwmt7:/ $ps 
uQ_a272 21143 3671 1574624 48976 ffffffff 00000000 S com.examp 


即 P1D 值 是 21143 
Step4， 通 过 GDB Server 来 Attach 目 标 进 程 


我 们 这 个 例子 中 采用 Attach 的 方式 来 控制 目标 对 象 ， 所 使 用 的 命 
x. 


gdbserver :1234 --attach [PID] 


成 功 Attach 上 以 后 ，gdbserver 会 显示 如 下 信息 


# Listening on port 1234 
Step5. 将 Target 设 备 的 端口 映射 到 开发 机 上 


、 这 个 步 ai 又 是 保证 GDB Client 可 以 顺利 连接 上 Server 的 关键 。 所 使 用 
命令 范例 如 下 : 


adb forward tcp:1234 tcp:1234 


Step6， 现 在 是 “万 事 俱 备 ， 只 和 欠 东 风 ” 了 ， 这 阵风 毫 无 疑问 就 是 
Host 机 上 的 GDB Client。 我 们 首先 要 做 的 就 是 让 它 与 Server 端 建立 连 
接 ， 命 令 范 例如 下 : 


arm-eabi-gdb ## 启 动 6DB 客 户 端 
file out/target/[platform]/symbols/system/bin/app_process ##% H 
target remote :1234 ## 与 Server 建 立 连接 


此 时 GDB 连 接 已 经 成 功 建立 起 来 了 ， 只 不 过 在 调试 过 程 中 还 无 法 与 
源 代码 对 应 起 来 。 为 了 解决 这 个 问题 ， 我 们 还 需要 为 目标 程序 设置 市 有 
调试 信息 的 库 文件 。 范 例 命令 如 下 所 示 : 


set solib-absolute-prefix /out/target/product/[XX]/symbols 
set solib-search-path /out/target/product/[XX]/symbols/system/1lib 


ERA. FERREIRA LUE GDB AY — AFI ap Sik 7 
各 种 调试 操作 了 ， 璧 如 b GRAMA) 、s (BB) 、r 〈 继 续 运 行 ) 
等 。 如 果 大 家 不 熟悉 这 些 命 令 的 使 用 方法 的 话 ， 也 可 以 输入 help 来 查阅 
详细 的 帮助 信息 。 

Step7. 为 需要 调试 的 Art 虚 拟 机 〈 大 家 要 始终 记 住 一 点 : 虚拟 机 其 
实 就 是 一 个 so 库 ) 功能 设置 对 应 的 断 点 。 例 如 我 们 希望 调试 
ArtMethod: : 1nvoke 这 个 函数 的 处 理 逻 辑 ， 经 查 函 数 入 口 处 在 
art_method. cc 文件 中 的 行 数 是 370， 那 么 可 以 使 用 如 下 命令 设置 断 点 : 


b art_method.cc:370 


如 果 以 函数 名 来 设置 断 点 ， 那 么 要 注意 函数 所 属 的 Name Space 亦 要 
指定 ， 范 例如 下 : 








(gdb) b Invoke 
Function "Invoke" not defined. 
ake breakpoint pending on future shared library load? (y or [n]) n 


(gdb) b art::ArtMethod: : Invoke 

ote: breakpoint 17 also set at pc Oxb4a2f4ac. 

rect 18 at Oxb4a2f4ac: file art/runtime/art_method.cc, line 369. 
(gdb) 
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所 示 : 


Breakpoint 14, art::ArtMethod::Invoke (this=this@entry=0x6ffd7220, 
self=0xb4e36a00, args=args@entry=Oxbebb2ce4, args_size=4, 
result=result@entry=Oxbebb2ccc, shorty=0x7057ad24 "L", shorty@entry= 


@xb4a285b9 <art::JniMethodEnd(unsigned int, art::Thread*)+12> "\370\304 \324 
\370\234\060\020h\331h\335 \031a\304\370", <incomplete sequence \304>) 
at art/runtime/art_method.cc:370 
if (UNLIKELY(__builtin_frame_address(®) < self->GetStackEnd())) { 





男 外 ，GDB 也 可 以 对 汇编 代码 进行 调试 ， 而 且 使 用 过 程 和 C/C++ 并 没 
有 本 质 区 别 。 一 个 简单 的 范例 如 下 所 示 : 


(gdb) b quick_entrypoints_arm.S:909 


Breakpoint 4 at Oxb4a6d7d2: file art/runtime/arch/arm/quick_entrypoints_arm.S, l 
ine 909. 





利用 GDB 调 试 可 以 在 某 些 场合 下 很 好 地 帮助 我 们 理解 Art 这 种 复杂 系 
统 当然 ， 其 他 Android 子 系统 也 同样 适用 〉 的 内 部 实现 ， 建 议 大 家 在 
实践 中 充分 应 用 好 这 一 利器 。 


Android 安 全 机 制 透 析 


22.1 Android Secur ity 综 述 


毋庸 置疑 ， 安 全 性 一 直 是 Android 系 统 重点 改进 的 方向 之 一 《其 他 


方向 还 包括 系统 性 能 等 ) ， 它 有 专门 的 团队 来 负责 安全 性 方面 的 改进 工 
作 一 一 这 是 一 项 需要 不 断 迭 代 演 进 的 工作 ， 同 时 也 需要 很 多 探索 和 “ 攻 
防 之 间 的 相生 相克 ”过 程 。Android 安 全 小 组 的 活动 包括 但 不 限于 如 下 
几 项 见 图 22-1) 。 


在 一 个 Android 新 版 本 的 早期 阶段 ， 负 责 安全 性 的 团队 会 首先 构建 
一 个 可 配置 和 可 扩展 的 安全 模型 。 

接着 在 开发 上 述 平台 模型 的 过 程 中 ， 他 们 还 会 根据 Android Security 
Team、Google 的 Information Security Engineering Team， 以 及 其 他 安 
全 顾问 的 审视 建议 来 实时 调整 安全 策略 。 

除 此 以 外 ， 他 们 还 会 把 设计 方案 开放 给 任何 感 兴趣 的 第 三 方 人 员 ， 
以 便 可 以 集合 各 方 的 建议 来 完善 安全 机 制 。 

上 述 3 个 活动 是 在 版 本 Release 之 前 完成 的 ， 但 并 不 代表 Android 系 统 
发 布 后 就 一 定 没有 安全 性 方面 的 问题 了 。 所 以 Google 还 提供 了 各 种 
其 他 反馈 途径 ， 来 允许 任何 人 对 Android 的 安全 性 提出 质疑 和 建 
议 。 

Android Security Team 每 个 月 也 都 会 提供 安全 方面 的 更 新 包 给 Google 
Nexus 手 机 ， 以 及 各 设备 开发 商 。 


Android SDK AOS? 


Google services/APIs Googk CISCDD 
Security best practices Security updates 
Security improvement program Security best practices 


Application Google security services Device 
Developers Google Play Makers 





Applications Device with Android OS 
Application updates Security OTA 


Users 


全 图 22-1 安全 服务 
总 体 来 说 ，Android 系 统 主要 从 如 下 几 个 角度 来 保障 安全 性 : 


。 在 Linux Kernel 层 应 用 各 种 安全 机 制 ， 例 如 后 续 小 市 将 会 讲解 到 的 
DAC、SELinux 等 ; 


。 所 有 的 应 用 程序 都 被 强制 运行 在 自己 的 sandbox 中 ; 
o 严格 的 进程 间 通 信安 全 控制 ; 

。 应 用 程序 签名 ; 

e Petmission 机 制 ; 


Or 我 们 也 可 以 从 内 核 层 和 应 用 程序 层 来 考查 Android 系 统 的 安 


。 (1) Kernel 层 的 安全 保障 


Linux Kerne1 经 过 这 么 多 年 的 发 展 ， 其 在 安全 性 方面 的 长 足 进 步 是 
有 有口皆碑 的 ， 因 而 基于 其 上 的 Android 系 统 自然 可 以 利用 已 有 的 基础 来 
做 扩展 实现 。 总 体 来 说 ，Kerne1 为 Android 系 统 提供 的 关键 安全 特性 包 
括 但 不 限于 : User-based Permission Model, Process isolation, 
Extensible mechanism for secure 1PC 等 。 


我 们 知道 ， 每 一 个 Android 程 序 对 于 内 核 来 说 都 是 独立 的 进程 ， 意 
味 着 它们 之 间 可 以 充分 利用 UID 和 G1ID 机 制 来 做 安全 隔离 。 当 然 ， 
Android 系 统 为 所 有 应 用 程序 都 提供 了 Unique User 1D， 而 不 是 像 很 多 
其 他 操作 系统 那样 ， 让 多 个 进程 以 同一 个 User 身 份 来 运行 一 一 我 们 可 以 
把 这 种 做 法 称 为 具有 Android 特 色 的 Sandbox。 


内 核 的 文件 系统 访问 机 制 和 UG0 模 型 在 Android 系 统 中 也 同样 适用 。 
每 个 应 用 程序 都 有 自己 的 私有 数据 ， 在 没有 特别 允许 的 情况 下 ， 其 他 任 
何 个 体 都 无 权 访 问 ， 以 避免 破坏 情况 的 发 生 。 我 们 将 在 后 续 小 节 中 做 更 
详细 分 析 。 

除 此 之 外 ，Android 还 引入 了 Secur ity-Enhanced Linux， 并 根据 其 
自身 情况 扩展 而 成 SEAndroid。 这 使 得 设备 即便 是 在 被 Root 的 情况 下 ， 
也 能 尽量 降低 他 人 对 重要 资源 的 破坏 力 。 我 们 在 后 续 小 节 中 对 此 同样 有 
详细 齐 析 。 

。 (2) 应 用 程序 层 的 安全 保障 


默认 情况 下 ，Android 应 用 程序 仅 能 访问 一 些 非常 有 限 的 系统 资源 


〈 见 图 22-2) 。 对 于 那些 很 可 能 影响 用 户 体验 ， 及 网 络 、 数 据 、 费 用 相 
天 的 操作 ， 系 统 都 会 做 严格 的 控制 。 例 如 : 


Camera functions ; 
Location data (GPS) ; 


Bluetooth functions; 


SMS/MMS functions; 


o 
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e Telephony functions ; 

o 

e Network/data connections. 





APPLICATION 





ANDROID OS PERMISSIONS CHECK 





Personal information | | Sensitive mput devices |] Device metada 


_ 
_— 
> 








AW222 MAK 


如 下 则 是 一 些 可 能 会 产生 费用 的 程序 操作 范例 : 


e Telephony; 
e SMS/MMS; 


e Network/Data; 
e In-App Billing; 
e NFC Access. 


相信 大 家 已 经 想到 了 ， 完 成 上 述 安全 保障 的 是 Android 开 发 人 员 很 
熟悉 的 Permi ssion 机 制 ， 我 们 也 会 在 后 续 小 节 中 做 详细 解读 。 


除 此 之 外 ， 对 于 大 家 非常 关心 的 目前 的 一 些 主流 技术 ， 比 如 设备 
Root、 程 序 加 固 、 程 序 注 入 等 ， 也 将 在 本 章节 内 容 中 得 到 阐述 。 


22.2 SELinux 


22.2.1 DAC 


在 学 习 MAC 之 前 ， 我 们 有 必要 先 了 解 一 下 DAC， 即 Di scretionary 
Access Control。Discretionary 的 字面 意思 是 “任意 的 、 自 主 的 ”， 
它 很 好 地 解释 了 DAC 这 种 控制 方式 客体 的 属 主 可 以 自主 决定 是 否 将 
全 部 或 部 分 访问 权限 授 子 其 他 主体 。 主 体 通 常 是 指 进程 /线程 ， 而 客户 
则 是 文件 ， 文 件 夹 、TCP/UDP 端 口 、 内 存 段 、10 设 备 等 各 种 资源 。 


举 个 例子 来 说 ，Linux 系 统 中 的 UG0 (User、Group 和 0thers) 权限 
模型 就 是 DAC 的 一 种 表现 形式 。 按 照 UG0 的 规定 ， 权 限 主 要 分 为 读 、 写 和 
执行 3 种 ， 并 且 需 要 分 别 指定 User 用 户 、Group 属 组 和 0thers 对 客体 的 访 
问 权 限 。 我 们 来 看 一 个 实际 的 例子 : 


[xs@lap~]$ ls -1 
total 40 

drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
-rw-rw-r-- 





xs XS 4096 2010-05-24 17:04 Desktop 

XS XS 4096 2010-05-24 13:10 Documents 
xs 4096 2010-05-27 15:25 Download 

XS XS 0 2010-05-28 10:21 example.txt 


上 面 方 框 内 的 字符 串 就 是 U60 的 一 个 典型 范例 。 其 中 第 一 个 字母 位 
表示 当前 被 描述 对 象 是 文件 还 是 文件 来 ， 后 面 9 个 字母 则 分 别 表示 
User 、Group 和 0thers 《它们 各 占 3 个 字母 位 ) 对 这 个 文件 的 权限 ， 比 如 
A a eee 
行 权 限 。 


值得 一 提 的 是 ， 事 实 上 Linux 系 统 中 还 有 一 些 比较 特殊 的 权限 位 ， 
例如 SUID 和 SGID。 从 字面 意思 上 理解 ，SUID (Set User ID) 及 
SGID (Set Group ID) 分 别 表示 此 可 执行 文件 具有 设置 EU1D 和 EG1D 的 能 
力 一 一 程序 中 除了 UID 和 6G1D 外 ， 还 有 EUID 和 EG1D 两 个 特殊 1D， 它 们 的 默 
认 值 和 前 二 者 是 分 别 对 应 的 。 而 当 程 序 执行 了 带 有 SUID 和 SG1D 的 文件 
时 ， 它 的 EUID 和 EG1D 会 被 重新 设置 为 此 文件 属 主 的 UID 和 GI1D。 换 句 话 
说 ， 它 就 具备 了 该 文件 属 主 (或 Group〉 的 资源 访问 权限 ， 从 而 扩大 了 
其 原 有 的 权限 范围 。SUID 和 SG1D 就 好 比 一 肩 门 ， 只 要 你 进 得 去 ， 就 可 以 
拥有 更 广阔 的 空间 。 或 者 你 也 可 以 把 它 理解 为 一 次 婚姻 结合 ， 让 原本 属 
于 两 个 不 同 家 族 的 人 共享 了 双方 原 有 的 一 些 权 利 〈 如 出 入 对 方 家 族 的 住 
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宅 ， 看 一 些 私人 物品 等 ) 。 


在 设备 root 过 程 中 ， 通 常会 使 用 到 的 su 文件 就 具备 上 述 这 个 特性 。 
它 在 1s 命 令 中 得 到 的 权限 位 是 : 


-rwsr-sr-x root rooto 


另外 ，SUID 和 SG1D 在 Li nux 系 统 中 还 有 不 少 其 他 应 用 场景 。 例 如 
Linux 用 户 的 密码 存储 在 /etc/shadow 等 文件 中 ， 毫 无 疑问 它们 都 属于 需 
要 被 重点 保护 的 对 象 ， 因 而 理论 上 只 有 root 权 限 的 进程 才 可 以 修改 它 
们 。 但 这 同时 也 会 出 现 一 个 矛盾 ， 即 普通 用 户 如 何 更 改 自己 的 密码 呢 ? 
打破 僵局 的 是 passwd。 因 为 这 个 可 执行 文件 的 属 主 是 root， 而 且 具 有 
SUID 权 限 ， 这 样 一 来 执行 它 的 进程 就 拥有 了 root 权 限 ， 从 而 可 以 完成 密 
码 修改 等 关键 操作 。 


有 的 读者 可 能 会 有 这 样 的 疑问 一 一 除了 Read/Wr ite 之 外 ， 文 件 的 创 
建 和 删除 权限 又 是 如 何 决定 的 呢 ? 事实 上 Linux 中 的 所 有 对 象 都 可 以 被 
看 做 是 “文件 ”， 文 件 夹 本 身 也 不 例外 。 换 名 话说， 文件 的 创建 和 删除 
权限 的 决定 权 被 牢 牢 掌握 在 包含 它们 的 文件 夹 中 。 


22.2.2 MAC 


MAC (Mandatory Access Control) 是 相对 于 DAC 而 言 的 。 在 强制 控 
制 方式 中 ， 主 体 访问 客体 的 权力 取决 于 操作 系统 的 具体 控制 规则 ， 而 不 
是 由 属 主 自行 决定 。 简 单 来 说 ， 当 一 个 主体 党 试 去 访问 客体 时 ， 内 核 会 
首先 检验 本 次 访问 是 否 符合 安全 规则 ， 以 决定 是 否 允 许 操作 的 执行 。 

另外 ，MAC 不 允许 用 户 制定 或 者 修改 权限 规则 ， 不 管 这 种 行为 是 有 


意 还 是 无 意 的 。 所 有 权限 策略 都 由 一 个 Security Policy 
Administrator 控 制 |。 


22.2.3 ”基于 MAC 的 SEL inux 


SELinux (Secur ity-Enhanced Linux) 是 一 个 负责 安全 管理 的 
Linux 内 核 模 块 ， 它 提供 了 完善 的 机 制 来 支持 访问 控制 (Access 
Control) 方面 的 安全 策略 ， 比 如 MAC (Mandatory Access 
Controls) 。 


SELi nux 最 开始 是 由 美国 国家 安全 局 开发 的 ， 后 者 于 2000 年 的 12 月 
22 日 在 开源 开发 社区 发 布 了 第 一 个 基于 GPL 协议 版 本 的 SELinux。 一 开始 
的 时 候 ， 开 发 人 员 需 要 手工 将 SELi nux 应 用 到 内 核 源 码 中 ， 但 很 快 它 的 
出 色 表现 就 赢得 了 大 家 的 青睐 ， 于 是 Linux Kernel M2. 6 版 本 开始 就 将 
它 合并 到 主线 中 了 。 后 来 SELinux 又 被 逐步 应 用 到 多 个 Linux 发 行 版 本 
中 ， 从 而 为 提升 Linux 系 统 的 安全 可 靠 性 发 挥 了 重要 作用 。 


大 家 可 以 先 从 NSA 的 SELinux 开 发 小 组 的 如 下 声明 中 来 感受 一 下 : 


“NSA Secur ity-enhanced Linux is a set of patches to the 
Linux kernel and some utilities to incorporate a strong, 
flexible mandatory access control (MAC) architecture into the 
major subsystems of the kernel. It provides an enhanced 
mechanism to enforce the separation of information based on 
confidentiality and integrity requirements, which allows 
threats of tampering and bypassing of application security 
mechanisms to be addressed and enables the confinement of 
damage that can be caused by malicious or flawed applications. 
It includes a set of sample security policy configuration 
files designed to meet common, general-purpose secur ity 
goals.” 


由 此 可 见 : 


SELinux 的 架构 核心 是 MAC ; 
SELinux 是 针对 内 核 的 一 系列 “patch”， 它 们 会 “渗透 ”到 内 核 的 
各 个 子 系统 中 形成 强大 的 保护 网 ; 
e SELinux 希 望 基于 confidentiality 和 integrity 来 建立 起 对 信息 的 隔离 访问 
控制 ; 
e SeLinux 是 一 个 可 配置 的 、 灵 活 的 安全 机 制 。 
SELinux 作 为 Linux Kernel 下 的 一 种 安全 机 制 , 很 早 之 前 就 已 经 被 集 
成 到 内 核 的 主 版 本 中 了 ， 但 对 于 Android 系 统 来 说 ， 这 种 保护 直到 5. oF 
得 到 全 面 和 正式 的 应 用 。SELinux 在 安全 方面 至 少 可 以 给 Android 系 统 带 
来 三 大 好 处 : 


e SELinux 可 以 全 面 保 护 Android 中 的 各 种 系统 daemon， 让 它们 避免 来 





恶意 程序 的 危害 ; 

。 SELinux 可 以 完全 控制 Android 应 用 程序 与 内 核 层 之 间 的 交互 ， 也 能 
控制 应 用 程序 对 系统 资源 的 访问 ; 

。 SELinux 提 供 了 非常 灵活 的 安全 策略 配置 机 制 ， 使 得 Android 系 统 无 
颖 集成 这 一 成 熟 机 制 成 为 可 能 。 


接 下 来 我 们 首先 从 框架 层面 来 认识 一 下 SELinux 的 全 貌 ， 如 图 22-3 
所 示 。 
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全 图 22-3 
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引用 自 http://taiga.selinuxproject.org/~thaines/NB4-diagrams/2-high-level-arch.png 
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首先 大 家 要 清楚 一 点 ， 即 SELi nux 架 构 的 底层 基础 是 Li nux 


Security Modules (LSM) 。LSM 是 Linux 2. 6 内 核 标 准 的 一 部 分 ， 并 遵 
循 GNU GPL 开源 协议 。 简 单 来 讲 ， 它 的 宗旨 就 是 帮助 Linux 内 核 可 以 通过 
灵活 的 方式 支持 一 系列 第 三 方 安 全 模块 。 比 如 下 面 这 些 都 是 基于 LSM 框 
架 并 已 经 获得 kerne1 官 方 批准 的 优秀 项 目 : 


AppArmor 

AppArmot 是 一 个 基于 路 径 名 的 MAC 服 务 ， 而 且 不 需要 对 文件 系统 
进行 标签 化 。 其 官方 网 址 是 : 

http://wiki-apparmor.net 

SMACK 

其 全 称 为 Simplified Mandatory Access Control Kernel， 官 方 网 址 是 : 
http:/ /www.schaufler-ca.com 

Tomoyo 

基于 名 称 的 一 种 MAC 实 现 ， 其 官方 网 址 是 : 
http://tomoyo.osdn.jp/ 

SELinux 

这 是 本 小 节 的 主角 〈 见 图 22-4) 。 


SEL i nux 在 Linux 内 核 工 程 中 的 源码 位 置 是 


kernel\security\selinux， 其 下 的 文件 结构 如 图 22-5 所 示 。 可 以 看 


到 ， 


SELinux 涉 及 的 源 文件 并 不 多 ， 有 兴趣 的 读者 可 以 自行 挑选 阅读 。 
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全 图 22-4 SELinux 主 要 模块 关系 图 
引用 自 http://taiga.selinuxproject.org/~thaines/NB4-diagrams/12-lsm-selinux-arch.png 
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全 图 22-5 SELinux 源 码 目 录 
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22.3 ”Android 系 统 安全 保护 的 三 重 利 剑 


Android 系 统 的 安全 性 一 直 以 来 都 是 大 众 诉 病 的 重点 之 一 。 相 对 于 
Apple 系 统 的 闭 源 策略 ，Android 的 开源 和 开放 性 无 疑 会 引发 更 多 安全 方 
面 的 潜在 风险 。 


但 是 我 们 也 要 看 到 ，Android 系 统一 直 在 努力 提升 自身 的 安全 性 ， 
例如 它 基 于 SELinux 扩 展 出 了 SEAndroid， 即 Secur ity Enhancements 
for Android™ (SE for Android) 。 


起 初 ，SEAndroid 只 是 将 SELinux 引 进 到 了 Android 系 统 中 ， 以 控制 
恶意 应 用 程序 所 带 来 的 危害 。 随 着 时 间 的 推移 ， 这 个 项 目 已 经 不 仅仅 是 
使 用 SELi nux 这 么 简单 了 ，Android 针 对 自身 的 特点 做 了 不 少 关 键 的 扩展 
和 改进 一 一 Android 从 4. 3 版 本 开始 支持 SELinux;Android 4. 4 版 本 则 将 
SELinux 变 成 了 强制 模式 ; 而 到 了 Lol lipop 时 期 ，Android 中 所 有 的 服务 
和 应 用 程序 都 能 得 到 SELinux 的 全 面 保 护 了 。 


不 过 需要 特别 指出 的 是 ，Android 并 没有 因为 “新 
Xx” (SEAndroid) MRA “RAZ” (DAC 访 问 机 制 ) 。 这 两 种 安全 机 制 
之 间 是 一 种 “与 ”的 关系 ， 它 们 共同 构成 Android 安 全 控制 的 两 堵 坚 实 
的 城墙 一 一 任何 核心 资源 的 访问 操作 都 需要 同时 符合 SEAndroid 和 DAC 的 
安全 控制 。 如 图 22-6 所 示 。 






SEAndroid 
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全 图 22-6 Andtoid 系 统 中 的 双重 保护 机 制 


另外 ， 上 层 应 用 程序 还 同时 受到 Permi ssion 机 制 的 约束 。 所 以 接 下 
来 我 们 将 通过 3 个 小 布 来 分 别针 对 它们 做 细 化 分 析 。 





22. 3.1 第 一 剑 : Permission 机 制 | 


不 论 是 Android 应 用 程序 开发 者 还 是 系统 程序 员 ， 相 信 都 不 会 对 
Permission 机 制 感到 阳 生 。 简 而 言 之 ，Permission 是 Android 应 用 程 
序 、Android 系 统 和 用 户 的 基础 安全 保障 。 任 何 类 似 于 读 写 用 户 私 人 数 
据 〈 壁 如 E-mai 1 和 联系 人 ) 、 应 用 程序 文件 或 者 网 络 访问 等 行为 都 需要 
首先 经 过 系统 的 权限 授予 。 


那么 Permi ssion 具 体 是 如 何 发 挥 作 用 的 呢 ? 


我 们 知道 ，Android 应 用 程序 运行 于 进程 沙 盒 (Sandbox) 中 。 
Sandbox 是 分 离 运行 程序 的 一 种 安全 手段 。 它 常 被 用 于 为 不 被 信任 的 程 
序 〈 比 如 未 知 的 第 三 方 软件 ， 无 法 核实 的 网 址 等 ) 提供 特殊 的 运行 环 
境 。 目 的 是 显而易见 的 ， 就 是 为 了 防止 这 些 程 序 产生 各 种 形式 的 破坏 。 
人 特别 是 对 于 资源 的 访 
问 更 是 如 此 。 


正 因为 如 此 ，Android 中 的 应 用 程序 在 默认 情况 下 都 没有 访问 资源 
或 数据 的 权利 ， 当 它们 希望 执行 类 似 操作 时 就 要 显 性 地 做 出 申请 ， a 
明 各 种 Permissions。 声 明 过 程 并 不 复杂 ， 主 要 是 通过 
AndroidManifest. xm 中 的 Cuses-permission> 标 签 来 完成 。 下 面 是 
Android 官 方 提供 的 一 个 例子 : 
<manifest xmlns:android="http://schemas.android.com/apk/res/andro 

package="com.android.app.myapp" > 

<usesS-permission android:name="android.permission.RECEIVE_SMS 


</manifest> 
可 以 看 到 ， 这 个 应 用 程序 范例 主动 申请 了 一 个 接收 短信 的 权限 。 


表 22-1 是 Android 系 统 中 的 一 些 常见 权限 的 节选 ， 大 家 可 以 熟悉 
下 。 


表 22-1 常见 Permission 释 义 


Permissions Description 


允许 应 用 程序 发 送 “ 设 备 接收 到 新 
SMS 的 广播 ” 
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w a | 打开 网 络 sockes 
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的 定位 功能 
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m p FRA MALEK 
peap-conracts avannon 


LOCATION_HARDWARE 








系统 会 在 以 下 两 种 情况 中 使 用 到 应 用 程序 在 AndroidManifest. xml 
中 声明 的 Permission GŁ: Android M 以 上 版 本 中 针对 某 些 核心 权限 
的 处 理 过 程 发 生 了 变化 ， 人 参见 Runtime Permission) : 


。 应 用 程序 安装 时 


在 应 用 程序 的 安装 过 程 中 ， 会 在 设备 屏幕 弹出 一 个 提示 框 指明 此 
APPL1CATI10N 声 明 的 所 有 权限 。 如 果 用 户 拒 绝 了 它 的 权限 申请 ， 那 么 安 
装 过 程 将 直接 失败 ; 否则 系统 的 Package lnstaller 才 会 继续 进行 。 一 
个 典型 范例 如 图 22-7 所 示 。 


。 应 用 程序 运行 过 程 中 

o 当 应 用 程序 在 运行 过 程 中 执行 已 经 申请 过 权限 的 操作 时 ，Andtoid 
系统 并 不 会 再 次 询问 用 尸 。 这 样 做 的 目的 是 为 了 不 反复 骚扰 用 己 ， 
造成 不 好 的 用 尸体 验 。 
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全 图 22-7 应 用 程序 安装 过 程 中 的 权限 申请 


随 着 Android 版 本 的 演进 ， 不 断 会 有 新 增 的 Permi ssions 被 加 入 到 系 
统 中 一 一 而 且 新 的 平台 版 本 针对 某 些 核心 权限 的 控制 也 呈现 逐步 加 强 的 
趋势 。 比 如 Android 旧 平台 (AP1 等 级 3 及 以 下 ) 中 是 可 以 不 用 申请 
WRITE_EXTERNAL_STORAGE 的 ， 但 随后 的 版 本 中 就 明确 规定 了 应 用 程序 必 
须 显 式 声明 这 一 权限 了 。 大 家 应 该 能 想到 ， 这 种 变化 首先 要 解决 的 一 个 
问题 是 ， 新 平台 如 何 保 证 对 老 应 用 程序 的 兼容 性 。 


Android 针 对 这 个 问题 的 解决 办 法 是 : 系统 会 自动 判断 是 否 可 以 为 
旧 平 台 版 本 中 的 应 用 程序 添加 新 平台 版 本 中 的 对 应 权限 。 具 体 来 说 ， 当 
老 应 用 程序 的 targetSdkVersion 属 性 低 于 该 权限 出 现时 的 AP1 等 级 ， 那 
么 系统 将 自动 为 其 授权 ， 以 保证 它 在 新 平台 上 可 以 继续 稳定 地 运行 。 


那么 对 于 那些 没有 按照 要 求 申 请 权限 的 应 用 程序 ， 系 统 会 有 哪些 强 
制 手 段 呢 ? 接 下 来 我 们 以 网 络 访问 为 例 ， 具 体 剖 析 下 Android 系 统 是 如 
何 利 用 Permi ssion 机 制 来 控制 应 用 程序 权限 的 。 


Android 系 统 会 为 设备 中 所 有 受 保 护 的 资源 “ 贴 上 ”Permi ssion 标 
签 ， 并 提供 便捷 的 通道 供 开 发 人 员 主 动 申报 相关 的 权限 。 下 面 是 系统 规 
定 的 ， 访 问 网 络 资源 需要 主动 申请 的 Permi ssion: 


<uses-permission android:name="android.permission. INTERNET"></use 


如 果 应 用 程序 希望 访问 网 络 功能 ， 那 么 它 需要 在 
AndroidManifest. xml PRJ E 述 的 语句 否则 系统 就 会 抛 出 异常 。 如 
图 22-8 所 示 。 


05-25 21:45:54. 430 21958-22006/? E/AndroidRuntime: FATAL EXCEPTION: Thread-1231 
Process: com. example.myapp, PID: 21958 
java. lang. SecurityException: Permission denied (missing INTERNET permission?) 
at java.net. InetAddress. lookupHostByllame (ImetAddress java 464) 
at java.net. InetAddress. getAl]BylameImpl (JnetAddress java. 252) 





at java.net. InetAddress. getAl]Byllame (InetAddress java.215) 

at com. android. okhttp. internal. Network$1. resolveInetAddresses (Network. java: 29) 

at com. android. okhttp. internal. http. RouteSelector. resetlextInetSocketAddress (RouteSelector. java: 188) 
at com. android. okhttp. internal. http. RouteSelector. nextProxy (RouteSelector. java: 157) 

at com. android. okhttp. internal. http. RouteSelector. next (RouteSelector. java: 100) 





全 图 22-8 ”网络 权限 缺失 所 导致 的 异常 情况 


当 应 用 程序 在 设备 中 安装 时 ，PackageManagerService 会 扫描 APK， 
提取 出 其 中 声明 的 < uses-permission> 加 以 保存 ， 并 根据 具体 情况 将 其 
加 入 系统 的 相应 群 组 中 。 接 下 来 的 安全 检查 分 为 两 种 情况 : 既 有 可 能 是 
Android 系 统 提供 的 AP1 自 身 就 会 针对 程序 身份 和 操作 做 安全 检查 ; 也 有 
可 能 是 AP1 在 进一步 调用 内 核 层 的 功能 时 ， 由 于 应 用 程序 不 是 相应 群 组 
的 成 员 而 触发 安全 问题 不 难 发 现 ， 上 述 这 个 范例 就 是 因为 执行 到 
lookupHostByName 时 ，Android 系 统 catch 到 了 一 个 Secur ityException 
而 导致 的 失败 。 


类 似 的 例子 还 有 很 多 ， 例 如 不 少 应 用 程序 都 需要 访问 SDCARD 目 录 下 
的 文件 ， 此 时 也 会 有 安全 检查 的 过 程 。 对 于 开发 人 员 来 说 ，Java 的 标准 
AP1 就 提供 了 文件 访问 的 能 力 ， 因 而 java. io. File 是 他 们 比较 常用 的 一 
个 类 。Android N 版 本 中 的 核心 库 (1ibcore) 会 分 为 两 部 分 ， 其 一 是 移植 
自 0penJDK 的 ， 被 保存 在 /1ibcore/ojluni 路 径 下 ;其 二 是 Android 的 差异 
aes 主要 集中 在 /1ibcore/1ibart 和 其 他 相关 目录 中 。 以 下 面 的 语句 
大 省 : 


String FILENAME = "hello_file"; 
String string = "hello world!"; 





FileOutputStream fos = openFileOutput(FILENAME, Context .MODE_PRIV. 
fos.write(string.getBytes()); 
fos.close(); 


这 里 的 Fi leOutputStream : :write 会 调用 loBridge. write， 后 者 则 
进一步 通过 Libcore. os. write 来 写 数 据 到 文件 中 。Libcore. os 是 一 个 
BlockGuard0s 类 型 的 静态 变量 ， 定 义 如 下 : 


public final class Libcore {... 
public static Os os = new BlockGuardOs(new Posix()); 


BlockGuard0Os 4418 RA Te SAC EA ESM SF OsHROBI— PRA 
象 ， 即 Posix。 在 我 们 这 个 场景 中 ，Pos ix 提供 的 write 功能 又 将 调用 
nati vel žtwr iteBytes 进 入 本 地 层 。 关 系 如 图 22-9? 所 示 。 


FileOutputStream libcore.t0.0s 


loBridge Forwarding Os 





Libcore.08 


A 22-9 ”FileOutputStream 的 内 部 实现 关系 图 


首先 ，Android 系 统 需要 对 程序 的 某 些 文件 写 入 行为 《其 他 行为 也 
是 类 似 的 ) 进行 拦截 ， 以 便 执行 诸如 StrictMode 之 类 的 检查 。 比 如 在 我 
们 这 个 场景 中 : 


/*libcore/luni/src/main/java/libcore/io/BlockGuardOs. java*/ 
public int write(FileDescriptor fd, byte[] bytes, int byteOffset, 
throws ErrnoException, InterruptedIOException { 
BlockGuard.getThreadPolicy().onwWriteToDisk(); 
return os.write(fd, bytes, byteOffset, byteCount); 


} 


StrictMode 是 辅助 开发 人 员 进 行 应 用 程序 调 优 的 一 种 模式 ， 它 提供 
的 多 种 策略 可 以 让 我 们 甄别 应 用 程序 在 运行 过 程 中 是 否 在 磁盘 读 写 、 网 
络 访问 、 运 行 性 能 等 多 个 方面 存在 不 足 ， 从 而 有 针对 性 地 进行 改进 。 


另外 ， 从 操作 系统 的 层面 来 说 Java AP1 也 属于 上 层 实现 ， 因而 它 的 
ype eas the R 作 系统 的 接口 来 提供 支撑 世 x i 
统 AP1 之 则 的 关系 。 壁 如 上 述 os. write 就 是 由 pcsix 提 供 的 ， 实 现 如 下 : 


/* libcore/luni/src/main/java/libcore/io/Posix. java*/ 
public int write(FileDescriptor fd, byte[] bytes, int byteOffset, 





throws ErrnoException, InterruptedIOException { 
//This indirection isn't strictly necessary, but ensures 
//is type safe. 
return writeBytes(fd, bytes, byteOffset, byteCount); 


private native int writeBytes(FileDescriptor fd, Object buffe 


可 以 看 到 wr iteBytes 是 一 个 native 函 数 ， 它 在 内 部 可 以 通过 
C/C++ 库 来 进一步 完成 应 用 程序 的 wr ite 请 求 。 不 过 到 目前 为 止 ， 我 们 似 
乎 还 没有 看 到 系统 是 如 何 对 应 用 程序 进行 文件 写 入 权限 的 检查 的 。 大 家 
可 以 先 想 想 看 权限 检查 应 该 放 在 哪 一 个 阶段 比较 合适 呢 ? 


对 于 Android 6. 0 之 前 的 系统 ， 答 案 就 在 于 当 应 用 程序 在 
AndroidManifest. xmi FÆRA WRITE EXTERNAL STORAGE 时 , ABA ARYA 
属 的 Groups 中 就 会 有 A1D_SDCARD_RW(1015) ， 这 样 一 来 该 应 用 程序 就 具 
有 写 入 SDCARD 的 能 力 了 。 反 之 如 果 没 有 声明 WRI1TE_EXTERNAL _STORAGE， 
那么 应 用 程序 就 无 法 向 SDCARD 正 确 地 写 入 数据 了 。 图 22-10 中 的 左边 是 
应 用 程序 申请 了 WRITE_EXTERNAL_STORAGE 权 限 的 情况 ， 右 边 则 是 没有 申 
请 权限 的 情况 。 我 们 使 用 的 命令 是 : cat /proc/<pid>/status) 如 图 
22-10 所 示 。 


10053 10053 10053 10053 id: 10054 10054 10054 10054 
10053 10053 10053 10053 id: 10054 10054 10054 10054 


: 64 ize: 64 
: 1615 1828 9997 50053 ~ : 9997 50054 





A 522-10 应 用 程序 申请 权限 前 后 的 情况 对 比 


Android 6. 0 和 后 续 版 本 中 因为 加 入 了 Runtime Permission 的 功 
能 ， 权 限 的 控制 方式 也 有 所 变化 。 应 用 程序 不 光 要 在 
AndroidMani fest. xm| 中 主动 声明 需要 使 用 到 的 所 有 普通 和 敏感 权限 ， 
而 且 需 要 在 运行 过 程 中 显 式 地 请 求 敏 感 权 限 《除非 用 户 已 经 允许 过 这 一 
权限 ， 并 人 勾 选 了 “不 再 询问 ”的 选项 ) 。 用 户 同 意 或 者 拒绝 应 用 程序 的 
动态 权限 申请 则 会 直接 影响 到 它 所 能 看 到 的 “Mount View”， 从 而 决定 
了 应 用 程序 是 否 可 以 成 功 向 SDCard 中 写 入 数据 。 更 多 细节 可 以 参见 本 书 
其 他 章节 的 分 析 。 


22.3.2 加强 剑 : DAC (UGO) 保护 


即 传统 的 Linux UG0 文 件 访 问 机 制 。 从 图 22-11 中 可 以 看 到 ， 即 便 是 
最 新 的 Android 操 作 系 统 ， 仍 然 没有 按 弃 这 个 传统 的 安全 保障 手段 一 一 
毕竟 经 历 了 这 么 多 年 的 考验 ，UG0 的 表现 虽然 中 规 中 矩 ， 但 依然 能 起 到 
一 定 的 保护 作用 。 


PuxXP-XP-X root 1976-61-61 : mnvm2 -@ 
PUXP-XP—-X root 2611-61-61 z modem_log 
P-XP-XP-X root 1976-61-61 z proc 
root 1976-61-61 z property_contexts 
root 2615-62-12 : root 
root 1976-61-61 : sbin 
root 2015-04-22 z sdcard -> /storage/enulat 


root 1976-61-61 : seapp_contexts 
root 1976-61-61 : sepolicy 

PUXPuXxP-X root 2611-61-61 : splash2 

FWXF—X——X sdcard_r 2615-84-22 : storage 

P-XP-XP-X root 2615-84-22 : sys 

PUuXP-XP-X root 2615-63-16 z system 
root 1976-61-61 : ueventd.41633 .rc 
root 1976-61-61 : ueventd.4622 .rc 
root 1976-61-61 : ueventd.4845 .rc 
root 1976-61-61 : ueventd.5821.rc 
root 1976-61-61 : ueventd.71424.rc 
root 1976-61-61 : ueventd.hi363@.rc 
root 1976-61-61 : ueventd .rc 
root 1976-61-61 : update_commit_boot 

lruxruxPux root 2615-84-22 : vendor 一 > /system/vendor 





全 图 22-11 Android 系 统 中 的 UGO 机 制 


UG0 机 制 在 Android 系 统 和 Linux 中 的 表现 基本 上 是 一 致 的 ， 只 不 过 
我 们 还 要 额外 思考 的 一 个 问题 是 : Linux 是 一 个 多 用 户 系 统 〈 注 : 
Android 也 支持 多 用 户 的 概念 ， 但 和 传统 的 多 用 户 系统 有 不 小 的 差 
异 ) ， 但 是 Android 则 不 存在 “用 户 登 录 ” 的 过 程 ， 那 么 它 是 如 何 区 分 
AE “User” HIE? 


在 回答 这 个 问题 之 前 ， 我 们 可 以 首先 对 安全 机 制 做 一 个 抽象 ， 如 图 
22-12 所 示 。 





全 图 22-12 安全 机 制 的 抽象 


无 论 具 体 的 安全 机 制 怎么 变化 ， 它 们 本 质 上 要 回答 的 问题 是 不 变 
的 ， 即 主体 访问 客体 的 规则 是 什么 。 


依照 这 一 基础 原理 ， 我 们 当然 需要 思考 一 下 Android 系 统 下 的 主体 
EH? 没 错 ， 无 非 还 是 进程 /线程 。 那 么 这 样 就 好 办 了 ，Linux 系 统 既 然 
是 通过 当前 登录 的 用 户 身份 来 给 子 主 体 相应 的 UID 和 G1D 等 属性 ， 那 么 
Android 系 统 也 完全 可 以 制定 另外 一 个 规则 ， 来 赋予 每 个 主体 自己 的 UID 
和 GID。 具 体 而 言 ，Android 系 统 中 运行 的 进程 的 UID 和 G1D 是 由 
PackageManagerService 分 配 的 ， 而 且 是 在 APK 安 装 之 初 就 确定 下 来 了 
《更 为 有 趣 的 是 ， 每 一 个 APK 都 会 被 赋予 一 个 不 同 的 UID) 一 一 和 Linux 
的 做 法 相 比 其 实 就 是 “ 换 汤 不 换 药 ”。 我 们 可 以 参考 Process. java 中 对 
UID 的 分 类 ， 如 表 22-2 所 示 。 


3222-2 UID 分 类 





ROOT_UID | Root UID 


UID under which system code 
runs 


UID under which telephony 
code runs 


000 UID for shell 
1007 UID for log group 


UID for WIFI supplicant 





LOG_UID 


WIFI UID 


process 


1013 uw for mediaserver process | 
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| | AAA， 
UID for DRM process 


| | 
VPN_UID 1016 UID for VPN services 
NFC_UID 1027 UID for NFC service process 


BLUETOOTH_UID 1002 UID for Bluetooth service 
process 


Wy J o yaa y BY 5 
FIRST_APPLICATION_UID]10000 a ~ 预 留 的 UID 区 域 


的 终止 值 





大 Bi Ti BY h z 
LAST_APPLICATION_UID li9999| 为 应 用 程序 讶 留 的 UID 区 域 





这 样 一 来 Android 中 的 UG0 机 制 和 Linux 中 的 经 典 实现 就 没有 太 大 区 
别 了 。 对 于 Linux UG0 的 更 多 信息 ， 建 议 大 家 可 以 自行 查阅 相关 资料 了 


# o 
22.3.3 ”终极 剑 : SEAndroid 
相信 不 少 开发 者 都 会 有 过 类 似 的 经 历 一 一 虽然 “X X Xx 一 键 R00T 神 
器 ”显示 手机 已 经 root 成 功 了 ， 但 访问 一 些 文件 时 仍然 会 发 生 权限 不 足 
的 错误 。 这 实际 上 就 是 得 益 于 SEAndroid 对 设备 的 全 面 保 护 了 。 


与 SEAndroid 相 关 的 一 系列 重要 的 Papers 和 出 版 物 如 下 所 示 ， 大 家 
可 以 和 本 小 节 内 容 结合 起 来 阅读 理解 : 


e The Case for SE Android, Linux Security Summit 2011, Sep 2011. 
e The Case for Security Enhanced (SE) Android, Android Builders Summit 


2012, Feb 2012. 

e Security Enhanced (SE) Android, LinuxCon North America 2012, Aug 
2012. 

e Middleware MAC for Android, Linux Security Summit 2012, Aug 2012. 

e Security Enhanced (SE) Android: Bringing Flexible MAC to Android, 20th 
Annual Network and Distributed System Security Sympostum (NDSS '13), 
Feb 2013. 

e Laying a Secure Foundation for Mobile Devices, 20th Annual Network and 
Distributed System Security Symposium (NDSS '13), Feb 2013. 

e Laying a Secure Foundation for Mobile Devices, International Council on 
Systems Engineering (INCOSE) Chesapeake Chapter Monthly Meeting, 
Aug 2013. 

e Security Enhancements (SE) for Android, Android Builders Summit 2014, 
Apr 2014. 

e Protecting the Android TCB with SELinux, Linux Security Summit 2014, 
Aug 2014. 


在 开局 了 SEAndroid 的 设备 中 ， 通 过 Adb 命 令 getenforce 可 以 得 到 如 
下 信息 : 


shell@hwmt?:/ $ getenforce 
getenforce 


Enforcing 





这 个 状态 从 Android 4 4 以 后 就 成 了 一 种 强制 行为 了 ， 除 非 传递 给 
内 核 的 参数 中 带 有 androidboot. selinux=permi ssive 一 一 此 时 不 符合 
SEAndroid 规 则 的 非法 访问 只 会 被 记录 成 log， 系 统 并 不 会 强制 禁止 它 的 
执行 ，SEAndroid 的 发 展 时 间 表 如 图 22-13 所 示 。 


SE for Android: Timeline 


Oct 31 2013 
Weni Mem apma Sod20 ani 
SEfor Samsung First device 2 devie release wi SE 


Android collaboration w/ SE ship W/SEships- enforcing- 
released begins Galaxy S4 Galaxy Note3 Android 4.4 


Jan9 2012  Fed2013  Jul2013  Oct2013 Feb 2014 
Google Samsung  FistAndroid 43 update for  Samaung 


invites announces release Galaxy $4 ANNOUNCES 
submission KNOX w w $E WE KNOX2.0, 
SE for permissive- enforcing Galaxy 85 


Android Android 43 


A 22-13 SEAndtoid 的 发 展 时 间 表 
( 引 自 Secutity Enhancements (SE) for Android, Android Builders Summit 2014) 


我 们 在 上 一 小 节 对 安全 机 制 进行 了 一 个 抽象 ， 并 提出 它 需 要 回答 的 
问题 是 一 一 主体 访问 客体 的 规则 是 什么 。 对 于 SEAndroid 来 说 ， 这 个 问 


题 也 同样 适用 


在 SEAndroid 机 制 中 ， 主 体 和 客体 的 安全 标签 与 UG0 相 比 发 生 了 非常 
大 的 变化 。 我 们 可 以 通过 如 下 命令 来 显示 客体 的 SEAndroid 安 全 标签 : 


ls -Z [Obje] 
比如 下 面 所 示 的 例子 : 


:UsersNxsg>adhb shell 

hell@hwmt?:/ $ ls -Z /system/bin/vold 
ls -Z /system/bin/vold 

PUXP-xXP-x root shell u:object_r:unlabeled:sð vold 


hell@hwmt?:/ $ ls -Z /init 
ls -Z /init 
FWXP—X——— root root u:object_r:rootfs:s6@ init 





还 可 以 通过 如 下 命令 来 显示 主体 的 SEAndroid 安 全 标签 : 


ps -Z [Subject] id 
比如 下 面 所 示 的 例子 : 


hell@hwmt?:/ $ ps -Z com.huawei.ca 
-Z com.huawei.ca 
USER PID PPID NAME 
1: Pisystem_app:s@ system 3381 2421 com.huawei.ca 


hell@hwmt?:/ $ ps -Z adhd 
s -Z adhd 


USER PID PPID NAME 
shell 31297 1 /shin/adhd 





由 于 SEAndroid 涉 及 的 知识 面 比较 多 ， 我 们 将 分 为 几 个 小 市 来 对 其 
进行 深入 分 析 。 


22.4 SEAndroid 剖 析 
22.4.1 SEAndroid 的 顶层 模型 


我 们 在 前 面 讲解 Linux UG0 时 针对 安全 机 制 所 做 的 模型 抽象 对 于 
SEAndroid 也 是 适用 的 。 只 不 过 它 的 Labe | 不 再 是 U1D/GI1D 了 ， 取 而 代 之 
的 是 “user :role:type:security” 这 个 SELinux 的 安全 上 上 下文; BEM 
则 也 不 再 是 简单 固定 的 UG60， 而 是 需要 由 sepolicy 来 定义 具体 的 访问 权 
限 了 。 另 外 ，SEAndroid 主 要 通过 Labe| 中 的 Type 来 定义 安全 策略 ， 所 以 
又 被 称 为 Type Enforment 〈 这 也 是 它 的 . te 文件 后 缀 的 由 来 )。 


根据 SEAndroid 顶 层 模型 的 描述 〈 见 图 22-14) ， 我 们 不 难 理解 它 在 
设计 过 程 中 需要 重点 回答 如 下 几 个 问题 。 


sepolicy 







label 


全 图 22-14 SEAndtoid 的 顶层 模型 


Label 的 格式 和 安全 规则 的 定义 

Label 是 由 4 个 部 分 组 成 的 ， 它 们 又 分 别 有 哪 些 具体 的 规定 ? 除了 
Google 原 生 的 设计 外 ， 各 设备 厂商 是 否 可 以 自 定义 自己 的 安全 规 
则 ? 

系统 是 在 什么 时 候 ， 如 何 确定 某 个 Subject (主体 ) 的 具体 Label 的 ? 
系统 是 在 什么 时 候 ， 如 何 确 定 某 个 Object (客体 ) 的 具体 Label 的 ? 
系统 是 在 什么 时 候 ， 又 是 如 何 应 用 Subject 和 Object 之 间 的 安全 规则 
的 ? 


22.4.2 SEAndroid 相 关 的 核心 源码 


与 SEAndroid 相 关 的 源码 目录 主要 是 。 


e /system/sepolicy: 安全 策略 源 文 件 所 在 目录 ， 大 多 数 是 以 .te 结尾 的 
文件 。 
e /system/sepolicy/tools: 包含 了 编译 安全 策略 文件 所 需 的 一 系列 工 


e /external/libselinux: 用 于 生成 支撑 Andtoid 系 统 中 实现 Selinux 的 一 个 


其 中 external/1ibselinux 中 相关 的 源码 文件 结构 如 图 22-15 所 示 。 

















android avcc aventern avcintern avcsidtab avcsidtab booleans, callbacksc callbacks. canonical checkcon checkAcce compute. compute. context. 
alc alh $ h ( h ze context textc SSC anc reate.c 
fe 
| | 
| 
| | | 
context int deny unkn disablec dsoh  enabledic fgethlecon freeconc fsethlecon, getinitial getenforc gethlecon, getpeerco inte labe\c |abelandr 
emalh ownc 上 c contertc ec ( ne old_prope 


d 


label lec label fleh abe inter label supp Igetfilecon load poli Isetfilecon, mapping mappingh policyh poligvers, procattrc regexc regexh  selinux int 
nalih orte í yc c c ermalh 
































selinux net sestatusc setenforce setfilecon, —_stringrep.c 
jnkh te t 








全 图 22-15 文件 结构 


系统 预定 义 的 安全 规则 放置 在 /system/sepolicy 中 ; 各 厂商 自 定义 
的 te 文件 则 多 数位 于 /device/ [manufacturer]/device-name/sepolicy 
目录 下 ， 如 图 22-16 所 示 的 范例 。 


3884 > DATA (D:) » Work » AndroidSx > device » lge > hammerhead > sepolicy VG 82 'sepolicy 


jappte | jbluetooth loaderte | jbndgete | jcamerate devicete 
|_|domainte | Jfilete file contexts |_| genfs_contexts jhostapdte 
Liscutlte |_|mediaserver.te |_|mpdecisionte |_| netmgrdite platform appite 
qmuxte jradiote rldte mtte jsensorste 
ssrte A surfaceflinger.te |_| system_server.te jte macros |_|teete 
__thermald.te __timete |_jueventd.te | vsste | |wpate 


全 图 22-16 范例 


file_contexts 

既 包 括 编译 过 程 中 文件 的 安全 标签 ， 也 用 于 在 运行 时 态 对 设备 节 
点 、socket 端 已 、init.rc 产 生 的 /data 目 录 进 行 安全 标签 的 规划 。 当 你 
创建 新 的 安全 策略 时 ， 在 某 些 情况 下 需要 更 新 这 个 文件 来 分 配 新 的 
标签 。 而 为 了 让 新 标签 生效 ， 我 们 必需 重新 编译 文件 系统 image 或 
者 执行 restorecon。 

genfs_contexts 

这 个 文件 用 于 为 不 支持 扩展 属性 的 文件 系统 (例如 proc 和 和 vfat) 添 
加 标签 。 这 个 配置 将 作为 核心 策略 的 一 部 分 被 加 载 。 
ptoperty_contexts 

这 个 文件 用 于 制定 Android 系 统 各 属性 的 标签 ， 以 确定 哪些 进程 可 
以 设置 它们 。 它 将 在 系统 启动 时 的 init 进 程 中 被 加 载 ， 或 者 是 当 
selinux.teload_policy 被 置 于 1 时 被 重新 加 载 。 

mac_permissions.xml 

Middleware MAC policy， 即 MMAC。 这 个 文件 会 根据 应 用 程序 的 签 
名 以 及 包 名 (可 选 ) 来 为 它们 分 配 seinfo 标 识 。 然 后 在 
seapp_contexts 中 ， 系 统 将 把 seinfo 作 为 一 个 key 来 决定 给 某 些 App 分 
配 特殊 的 标签 。 这 个 文件 将 在 system_servet 启 动 时 被 加 载 读 取 。 


seapp_contexts 


这 个 文件 用 于 为 App 进 程 和 /data/data 文 件 夹 指定 标签 。 系 统 读 取 








seapp_contexts 的 时 机 为 : 
(1) 当 一 个 App 在 zygote 进 程 中 被 启动 时 ; 
(2) 当 instal1d 在 启动 时 ; 
(3) 当 selinux. reload_pol icy 属 性 被 置 为 1 时 。 


另外 ，Android 系 统 也 允许 各 设备 商定 制 自己 的 安全 策略 。 如 果 大 
家 有 需要 的 话 ， 可 以 参见 /device/1ge/hammerhead/BoardConfig. mk 中 
的 例子 。 这 个 编译 脚本 中 包含 了 若干 以 BOARD_SEPOLICY 开 头 的 变量 ， 用 
于 指明 厂商 的 自 定义 规则 。 如 下 所 示 : 


BOARD_SEPOLICY_DIRS += \ 
device/lge/hammerhead/sepolicy 


# The list below is order dependent 

BOARD _SEPOLICY_UNION += \, 
app. te \ 
bluetooth_loader. te \ 
bridge. te \ 
camera. te \ 
device. te \ 
domain. te \ 
file.te \ 
hostapd. te \ 
irsc_util. te \ 
mediaserver. te \ 
mpdecision. te \ 
netmerd. te \ 
platform_app. te \ 
amuz. te \ 
radio. te \ 
rild. te \ 
rmt. te \ 
sensors. te \ 
ssr. te \ 
surfaceflinger. te \, 
system_server. te \ 
tee. te \ 
thermald. te \ 


大 家 可 以 阅读 后 续 小 节 ， 学 习 针 对 pol icy 定 制 的 更 多 详细 信息 。 


22. 4.3 SEAndroid 标 签 和 规则 


标签 (label) 是 SEAndroid 机 制 的 基础 ， 它 用 于 为 策略 和 行为 提供 
匹配 条 件 。Android 系 统 中 的 任何 资源 〈 包 括 Socket、 文 件 、 进 程 等 ) 
都 有 自己 对 应 的 标签 。 


标签 的 基本 格式 是 : 


user:role:type:mls_level 
各 属性 释义 如 下 : 


e User 

。 在 SEAndroid 中 User 代 表 用 户 ， 而 且 到 目前 为 止 的 可 选 值 只 
有 “u 一 种 (有 可 能 是 预 留 的 属性 ) 。 

e 如 下 是 /system/sepolicy/users 文 件 中 的 内 容 : 


user u roles { r } level sO range sO - mls_systemhigh; 


e Role 

。 在 SEAndroid 中 代表 和 角色。 和 Uset 类 似 ， 这 个 属性 的 可 选 值 也 比较 
固定 : 对 于 主体 来 说 是 t, 对 于 客体 来 说 则 是 object_r。 

。 下 面 是 /system/sepolicy/roles 中 的 内 容 : 


role r; 
role r types domain; 


e Ht “roer” 声明 了 一 个 名 为 tf 的 角色 ; m “toler types domain” Jl 
表示 它 是 与 domain (主体 Type) 相关 联 的 ， 见 下 面 一 项 的 说 明 

e Type 

e SEAndtoid 中 定义 了 超过 130 种 的 Type 类 型 ， 比 如 device type. process 

type (又 被 称 为 domain) ~ file system type. network type. IPC type 

> 
a 

。 下 面 是 /system/sepolicy/domain.te 中 的 部 分 内 容 : 


\# Rules for all domains. \# Allow reaping by init. allow domain 


init:process sigchld; \# Read access to properties mapping. allow 

domain kernel:fd use; allow domain tmpfs:file { read getattr }; \# 

Search /storage/emulated tmpfs mount. allow domain tmpfs:dir 

r_dir_perms; \# Intra-domain accesses. allow domain self:process { 
fork sigchld sigkill sigstop signull 

signal getsched setsched getsession getpgid 
setpgid getcap setcap getattr setrlimit }; 





一 Security level (Multiple Level Security) MLS 的 格式 为 : [: 
category list] [- sensitivity [: category list]] 在 Android 系 统 
的 Type Enforment 中 ，4 个 标签 属性 中 只 有 Type 才 是 决定 安全 策略 执行 
结果 最 重要 的 考量 参数 ， 所 以 我 们 可 以 在 分 析 过 程 中 有 所 侧重 ， 有 针对 
性 地 提高 效率 。 ### 22.4.4 如 何在 Android 系 统 中 自 定 义 SEAndroid 
本 小 节 我 们 将 介绍 Android 系 统 应 用 SEAndroid 需 要 做 哪些 工作 ， 以 及 各 
设备 厂商 如 何 才能 自 定义 安全 规则 。 Step1， 在 内 核 中 开启 SEL inux 支 
持 。 对 应 的 变量 如 下 所 示 : 


CONFIG_SECURITY_SELINUX=y 
Step2. 修改 内 核 局 动 参数 ， 具 体 来 说 是 在 Android 工 程 中 添加 如 下 


的 命令 行 : 





BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive 


Step3， 以 permi sive 模 式 局 动 系统 ， 然 后 可 以 看 到 在 局 动 过 程 中 会 
遇 到 哪些 denials。 


在 Ubuntu 14. 04 及 以 后 : 
adb shell su -c dmesg | grep denied | audit2allow -p 
out/target/product/board/root/sepolicy 

在 Ubuntu 12. 04: 


adb shell su -c dmesg | grep denied | audit2allow 


Step4. 评估 上 一 步 中 的 输出 结果 。 


SELinux 的 log 消 息 都 包含 了 “avc:” 字 符 串 ， 因 而 可 以 很 容易 地 找 
žl 


通过 这 一 评估 结果 ， 我 们 可 以 知道 目前 有 哪些 违反 规则 的 行为 ， 然 
后 有 针对 性 地 进行 更 正 。 如 下 是 一 个 典型 的 例子 : 


avc: denied { connectto } for pid=2671 comm="ping" 
path="/dev/socket/dnsproxyd" 


scontext=u:r:shell:sO tcontext=u:r:netd:s0O 
tclass=unix_stream_socket 





其 中 { connectto } 代表 的 是 发 生 的 形 为 。 整 个 句子 表示 有 人 尝试 


去 连接 一 个 unix stream socket. 


参数 scontext 代 表 的 是 发 起 上 述 形 为 的 主体 的 具体 环境 。 在 这 个 例 
子 中 就 是 某 个 以 shel1 运 行 的 程序 。 


参数 tcontext 是 客体 的 具体 环境 。 在 这 个 例子 中 就 是 一 个 
unix_stream socket 的 所 有 者 netd。 


而 comm=”ping” 表 示 的 是 当 denial 发 生 时 究竟 执行 了 什么 语句 。 
Step5. 鉴别 出 哪些 设备 或 者 其 他 新 增 文件 需要 添加 Labe|。 
Step6， 使 用 现存 的 或 者 新 增 的 1abels 为 客体 添加 标签 。 可 以 借鉴 


工程 中 的 *_contexts 文 件 来 看 一 下 别人 是 怎么 做 的 ， 包 括 如 何 新 增 标 
签 。 如 下 例子 所 示 : 


HHAHHRHARHERRERAR HERRERA RRR RE RRR RRR RRR REE 
# Root 
j: u:object_r:rootfs:s0 


# Data files 

fadb_keys u:object_r:adb_keys_file:s0 
/default\. prop u:object_r:rootfs:s0 
/fstab\.. * u:object_r:rootfs:s0 

Jini Pak u:object_r:rootfs:s0 
fres(/. *)? u:object_r:rootfs:s0 
fueventd\. . * u:object_r:rootfs:s0 


# Executables 

/charger u:object_r:rootfs:s0 
finit u:object_r:rootfs:s0 
/sbin(/.*)?  u:object_r:rootfs:s0 


# Empty directories 
/lost\t+found u:object_r:rootfs:s0 
/proc u:object_r:rootfs:s0 


Step7. 为 系统 中 的 所 有 由 init 启 动 的 services (process 或 daemon) 
分 配 一 个 自己 的 domain。 


如 何 识别 出 这 些 services 了 呢 ? 官方 推荐 了 几 种 方法 : 
(1) Minit. <device>. rc 文件 中 获取 


(2) 检查 dmesg 输 出 中 所 有 与 “init: Warning! Service name 
needs a SELinux domain defined; please fix!” 相 关 的 语句 


(3) 通过 ps -Z | grep init 来 检查 有 了 哪些 service 是 以 init 
domain 来 运行 的 ， 如 图 22-17 所 示 ; 


hell@hwmt?:/ $ ps -Z igrep init 

-Z igrep init 

*:init:s@ root /init 
*:kerne1:s@ root rdr_init_thread 
shin/oeminfo_nvm_server 
/system/bin/servicemanager 
/system/bin/vold 
/system/bin/netd 
/system/bin/debuggerd 
/system/bin/rild 
/system/bin/surfacef linger 
zygote 
/system/bin/drmserver 
/system/bin/f ilebackup 
/system/bin/mediaserver 
/system/bin/installd 
/system/bin/keystore 
/system/bin/hupged 
/system/bin/thermal-—daemon 


*:init:s@ root 
*:init:s@ system 
*:init:s@ root 
*:init:s@ root 
*:init:s@ root 
*:init:s@ radio 
*:init:s@ system 
*:init:s@ root 
*:init:s@ drm 
*:init:s@ root 
*:init:s@ media 
*:init:s@ install 
*:init:s@ keystore 
*:init:s@ root 
*:init:s@ root 
*:init:s@ system 
s:init:s@ root 


/system/bin/ logserver 
/system/bin/hw_ueventd 
*:init:s@ root /system/bin/diagserver 


*:init:s@ root /system/bin/hunffserver 


=F 
=E 
=E 
=E 
=E 
=E 
=E 
=E 
=E 
=E 
=E 
=E 
=} 
SS 
=F 
=F 
=F 
=F 
=F 
=F 
=F 
=F 
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ažinit:sð root /system/bin/device_monitor 





全 图 22-17 以 init domain 运 行 的 进程 


(4) 通过 如 下 命令 查看 是 否 还 有 其 他 需要 注意 的 遗漏 项 : 


$ adb shell su -c dmesg | grep ‘avc: ' 


Step8. 在 BOARD CONFIG. mk 中 为 BOARD SEPOLICY *IRA. XARI 
在 前 面 小 节 已 经 提 到 过 了 。 


Step9. 检查 init. <device>. rc 和 fstab. 《device》 来 确保 所 


有 “mount” 使 用 的 都 是 已 经 正确 添加 了 标签 的 文件 系统 ， 或 者 已 经 指 
定 了 context=mount 选 项 。 


A 略 来 确保 所 有 被 限制 的 权限 都 可 以 得 到 合理 的 
管理 。 这 一 步 我 们 将 在 下 一 小 节 中 做 展开 讨论 。 


22.4.5 ”TE 文件 的 语法 规则 
我 们 接着 前 一 小 节 的 步骤 ， 讲 解 一 下 安全 策略 的 书写 与 注意 事项 。 


在 SEAndroid 中 ， 安 全 策略 文件 通常 以 . te 为 后 缀 名 ， 比 如 
adbd. te, app. te, Bluetooth. te, device. te 等 。 厂 商 自 定义 的 te 文件 
建议 放置 在 /device/manufacture/ [device-name]/sepolicy 文 件 夹 下 ， 
并 通过 BOARD_SEPOLICY 变 量 来 将 它们 添加 到 编译 环境 中 ， 以 保证 安全 策 
略 可 以 被 正确 纳入 到 系统 中 加 以 实施 。 


在 自 定义 安全 策略 的 过 程 中 ， 有 如 下 几 个 注意 事项 : 


。 切记 不 要 删除 目前 已 有 的 安全 策略 文件 。 建 议 各 个 厂商 根据 自己 的 
实际 需要 ， 新 增 针 对 某 些 资源 的 保护 策略 ; 

为 所 有 新 增 的 daemons 新 增 安全 策略 ; 

在 合适 的 情况 下 ， 尽 量 使 用 已 经 定义 过 的 domain ; 

对 于 从 init 中 启动 的 任何 进程 ， 都 确保 它 有 独立 于 init 的 domain; 

在 书写 安全 策略 前 ， 先 要 了 解 清楚 它 的 规则 ， 多 参考 别人 已 有 的 范 
例 ; 

。 在 可 能 的 情况 下 ， 将 核心 策略 提交 给 AOSP 工 程 组 。 

另外 ， 以 下 是 Android 官 方 给 出 的 “Not to do list” : 

创建 一 个 不 兼容 的 安全 策略 ; 

允许 终端 用 户 自 定义 安全 策略 ; 

允许 MDM 策 略 的 自 定义 ; 

让 用 户 感觉 处 处 都 充满 了 策略 违规 行为 ， 造 成 很 差 的 用 户 体 验 ; 
添加 后 门 。 


可 以 参考 以 下 文章 中 关于 安全 特性 要 求 的 详细 描述 : 














https://static.googleusercontent.com/media/source.android.com/zh- 


CN//compatibility/android-cdd.pdf。 





还 有 一 点 也 是 我 们 反复 强调 的 ， 即 一 开始 在 调试 阶段 可 以 只 开启 
permissive 模 式 ， 来 找 出 当前 系统 中 还 存在 哪些 问题 ， 然 后 不 断 迭 代 地 
解决 这 些 问题 ， 最 终 在 量 产 时 再 开启 强制 模式 。 

在 前 述 Labe1 的 基础 上 ，Policy 的 基本 格式 是 : 
1 


allow domains types:classes permissons: 
上 述 格式 中 的 几 个 关键 字 的 释义 如 下 : 


e Domain 
用 于 标识 单一 进程 或 一 系列 进程 。 
e Type 


用 于 标识 客体 〈 文 件 、Socket 等 ) 或 一 系列 客体 。 


e Class 


被 访问 的 客体 (文件 、Socket 等 ) 的 具体 种 类 。 
e Permission 
可 以 被 允许 的 操作 〈 读 、 写 等 ) 
除了 上 述 规则 格式 所 提 到 的 关键 词 外 ， 我 们 还 可 以 通过 属性 
(attribute) 来 指定 domai n 或 者 Type 一 一 它们 都 可 以 与 任意 数量 的 
attribute 相 挂钩 。 换 句 话说 ， 当 一 条 规则 是 通过 attribute 来 书写 的 
话 ， 那 么 系统 将 自动 把 其 中 的 attribute 解 析 成 具体 的 domai ns 和 
Types。 
举 个 例子 来 说 ， 如 下 的 一 条 策略 : 
这 条 策略 允许 与 属性 值 qomain 相 关联 的 进程 可 以 打开 “Type 为 
nul1 device，class 为 chr_ file” 的 客体 。 值 得 一 提 的 是 ， 
nul1_device 用 于 标识 /dev/nul1 设 备 。 


l 下 面 我 们 以 adbd. te 为 例 讲解 一 下 如 何 书写 一 个 合格 的 安全 策略 文 
牛 。 


//Note 1: 
allow adbd shell:process noatsecure; 





//Note 2: 

allow adbd self:capability { setuid setgid }; 
//Note 3: 

net_domain(adbd) 

//Note 4: 

allow adbd adb_device:chr_file rw_file_perms; 
allow adbd functionfs:dir search; 

allow adbd functionfs:file rw_file_perms; 
//Note 5: 

allow adbd devpts:chr_file rw_file_perms; 
//Note 6: 

allow adbd shell_data_file:dir create_dir_perms; 
allow adbd shell_data_file:file create_file_perms; 
//Note 7: 

allow adbd sdcard_type:dir create_dir_perms; 
allow adbd sdcard_type:file create_file_perms; 
//Note 8: 

allow adbd anr_data_file:dir r_dir_perms; 
allow adbd anr_data_file:file r_file_perms; 
//Note 9: 

allow adbd system_file:file rx_file_perms; 
//Note 10: 

binder_use(adbd) 

binder_call(adbd, surfaceflinger) 

allow adbd gpu_device:chr_file rw_file_perms; 
//Note 11: 

allow adbd adb_keys_file:dir search; 

allow adbd adb_keys_file:file r_file_perms; 





首先 要 说 的 是 ，SEAndroid 安 全 策略 文件 使 用 的 是 M4 语言 ， 因 而 支 
持 一 系列 预定 义 的 宏 。 大 家 可 以 参考 如 下 官方 网 站 了 解 详情 : 


https:/www.gnu.org/software/m4/manual/index.html 
我 们 在 前 面 小 节 提 到 过 ，TE 文 件 的 基本 语句 格式 如 下 : 
allow domains types:classes permissons: 


接 下 来 针对 上 面 的 adbd. te 具体 分 析 一 下 。 

Note 1: 这 条 语句 比较 特殊 ， 它 表明 不 能 对 she11 的 环境 做 净化 
(sanitize) 或 者 打开 shel1 的 fds。 为 了 让 大 家 更 好 地 理解 
noatsecure， 我 们 首先 要 知道 什么 是 atsecure。 

当 一 个 应 用 程序 初始 化 另 一 个 程序 时 ， 它 首先 执行 fork， 然 后 通过 
execve 来 把 程序 加 载 到 内 存 中 一 一 后 面 这 一 加 载 动作 通常 是 由 binary 
loader 完 成 的 ， 在 Linux 中 对 应 的 是 ELF Loader。 而 ELF auxiliary 
vectors 则 是 由 loader 设 置 的 一 系列 参数 ， 它 们 为 应 用 程序 提供 了 与 操 
作 系 统 相关 的 特殊 信息 。 比 如 AT_SECURE。 这 个 参数 用 来 告诉 ELF 动 态 链 
接 器 unset 一 些 可 能 会 对 系统 产生 潜在 威胁 的 环境 变量 ， 如 
LD_PRELOAD。 所 以 简 而 言 之 ，noatsecure 将 关闭 对 环境 的 净化 功能 。 

Note 2: 允许 adbd 对 she11 执 行 setuid 和 setgid。 

Note 3: 创建 并 使 用 网 络 Sockets。 

Note 4: 人 允许 访问 /dev/android adb 和 /dev/usb-ffs/adb/ep0。 


这 是 因为 adb_device 对 应 的 是 /dev/android_adb.*， 定 义 在 
file contexts 中 : 


/dev/android_adb. * u:object_r:adb_device:s0 


Note 5: 允许 使 用 一 个 虚拟 tty。 


Note 6: 允许 adb pul1l/push 指 定 的 文件 夹 : /data/1local/tmp， 定 
xaT: 


/data/local/tmp(/. *) ? u:object_r: shell_data_file:s0 
Note 7: 允许 adb pull/push sdcard。 


Note 8: 允许 adb pul1 指 定 文件 夹 : /data/anr/traces. txt， 因 为 
只 有 read 的 权限 。 


Note 9: 允许 运行 /system/b in/bu。 
Note 10: 人 允许 与 surfaceflinger 进 行 binder 的 1PC 通 信 。 


Note 11: 允许 读 取 /data/misc/adb/adb keys. 





22.4.6 SEAndroid 中 的 核心 主体 init 进 程 

SEAndroid Subject 的 载体 是 进程 ， 换 句 话说 设备 中 运行 的 绝 大 部 
分 进程 都 应 该 是 和 安全 上 下 文 相 关联 的 ， 这 样 才能 保证 系统 在 判断 它们 
是 否 具有 访问 客体 权限 时 “有 据 可 依 ”。 


我 们 知道 ，init 是 Android 系 统 运行 的 第 一 个 进程 ， 包 括 程序 
器 一 一 Zygote 在 内 的 所 有 后 续 进程 都 是 由 它 直 接 或 间接 启动 的 。 可 想 而 
知 ， SEAmdroid 对 系统 的 实时 保护 也 一 定 和 1nit 有 关联 例如 policy 
文件 的 加 载 就 是 在 init 中 进行 的 。 另 外 init 本 身 也 是 系统 中 的 一 个 进 
程 ， 因 而 本 小 节 将 以 它 作 为 SEAndroid 的 主体 代表 来 进行 详细 剖析 。 


init 程 序 对 应 的 源码 目录 是 /system/core/init。 我 们 首先 看 一 下 
它 的 main 哨 数 中 与 SELinux 相 关 的 实现 : 


/*system/core/init*/ 
int main(int argc, char **argv) 


{ 


selinux_initialize(is_first_stage); 


FALE AT DL, ini tiztsEb ma i ney he ARH) AA HASEL i nux Aye 
点 ， 其 中 selinux_initialize 的 核心 实现 如 下 : 


/*system/core/init/init.cpp*/ 
static void selinux_initialize(bool in_kernel_domain) { 
Timer t; 


selinux_callback cb; 

cb.func_log = selinux _klog_callback; 
selinux_set_callback(SELINUX_CB_LOG, cb); 
cb .func_audit = audit_callback; 
selinux_set_callback(SELINUX_CB_AUDIT, cb); 


if (in_kernel_domain) { 
INFO("Loading SELinux policy...\n"); 


if (selinux_android_load_policy() < 0) { 
ERROR( "failed to load policy: %s\n", strerror(errno) ) 
security_failure(); 


} 


} else { 
selinux_init_all_handles(); 
} 





在 N 版 本 之 前 ，init 进 程 会 通过 selinux_is disabled 来 判断 当前 
SELi nux 是 否 被 禁用 了 一 一 此 时 存在 如 下 两 种 可 能 的 情况 : 


Case 1: /sys/fs/selinux 无 法 访问 ， 这 很 可 能 是 SELinux 没 有 编译 
进 内 核 中 ， 或 者 通过 内 核 命令 参数 “selinux=0” 关 闭 了 


Case 2: 系统 属性 ro. boot. selinux 的 值 为 disabled。 


紧 接 着 的 重点 是 se | inux_callback， 它 的 源码 实现 在 se|inux.h 


/*external/libselinux/include/selinux*/ 
/* Callback facilities */ 
union selinux_callback { 
/* log the printf-style format and arguments, 
with the type code indicating the type of message */ 
int 
#ifdef _ GNUC__ 
__attribute__ ((format(printf, 2, 3))) 
#endif 
(*func_log) (int type, const char *fmt, ...); 
/* store a string representation of auditdata (corresponding 
to the given security class) into msgbuf. */ 
int (*func_audit) (void *auditdata, security_class_t cls, 
char *msgbuf, size_t msgbufsize); 
/* validate the supplied context, modifying if necessary */ 
int (*func_validate) (char **ctx); 
/* netlink callback for setenforce message */ 
int (*func_setenforce) (int enforcing); 
/* netlink callback for policyload message */ 
int (*func_policyload) (int seqno); 


}; 
可 以 看 到 ，selinux_callback 是 一 个 union 数 据 结 构 ， 在 调用 时 需 


要 同时 指定 所 针对 的 是 哪 种 类 型 的 回调 ， 如 下 所 示 。 
e SELINUX_CB_LOG: (*func_log) (int type, const char *fmt, ...) 
回调 log 信 息 ， 并 通过 type 指 示 log 类 型 。 


e SELINUX_CB_AUDIT: int (*func_audit) (void *auditdata, 


security_class_t cls, 


char *msgbuf, size_t msgbufsize) 

将 auditdata 中 的 数据 以 一 定格 式 保存 到 msgbuf 中 。 

e SELINUX_CB_VALIDATE: int (*func_validate) (char **ctx) 
验证 ctx 这 个 安全 上 下 文 环境 。 

e SELINUX_CB_SETENFORCE: int (*func_setenforce) (int enforcing) 
用 于 setenforce 消 息 的 回调 。 

e SELINUX_CB_POLICYLOAD: int (*func_policyload) (int seqno) 
用 于 安全 策略 加 载 时 的 回调 。 


上 述 的 se1inux_initialize 函 数 中 设置 了 两 个 回调 函数 ， 即 
log callback 和 haudit callback。 


接 下 来 初始 化 函数 将 继续 运行 并 加 载 安全 策略 。 我 们 在 前 面 小 节 已 
经 讲解 过 ， 这 些 安全 策略 是 专门 为 Android 系 统 设计 的 ， 因 而 它 的 实现 
是 在 android. c: 


/*external/libselinux/src/android.c*/ 
int selinux_android_load_policy(void) 
{ 
int fd = -1, rc; 
struct stat sb; 
void *map = NULL; 
static int load_successful = 0; 
if (load_successful){// 已 经 加 载 过 policy 了 


selinux_log(SELINUX_WARNING, "SELinux: Attempted reload of 
return 0; 


J 


set_selinuxmnt (SELINUXMNT) ; 
fd = open(sepolicy_file, O_RDONLY | O_NOFOLLOW | O_CLOEXEC); 


if (fstat(fd, &sb) < 0) { 
selinux_log(SELINUX_ERROR, "SELinux: Could not stat %s 
sepolicy_file, strerror(errno) ); 
close(fd); 
return -1; 


map = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0); 
rc = security_load_policy(map, sb.st_size); 


munmap(map, sb.st_size); 

close(fd); 

selinux_log(SELINUX_INFO, "SELinux: Loaded policy from %s\n" 
load_successful = 1; 

return 0; 


在 Android N 版 本 之 前 ， 系 统 首 先 会 尝试 mount selinux 的 结 点 
SELINUXMNT， 即 “/sys/fs/selinux”。 如 果 这 一 步 失 败 的 话 ， 又 有 两 
种 可 能 性 


Case 1: errno ==ENODEV 


设备 不 存在 ， 这 种 情况 下 说 明 SEL inux 在 系统 中 没有 被 启用 ， 因 而 
直接 返 回 错误 码 


Case 2:errno == ENOENT 


目录 不 存在 ， 此 时 需要 新 建 一 个 SELINUXMNT 文 件 夹 。 如 果 mkdir 仍 
然 失 败 ， 则 直接 返回 错误 ;否则 重 试 上 面 的 mount 操 作 。 


假如 mount 成 功 ， 我 们 紧 接 着 就 需要 先 保存 当前 的 挂 载 节点 ， 县 
set_sel inuxmnt as XS ey? i ihe to Parle SOIR 
配 的 一 个 字符 串 ， 然 seen inux_mnt 指 向 它 。 变 量 sel inux_mnt 是 全 局 
的 ， BU ae 过 程 中 的 SE1inux 挂 载 点 。 


Android N 版 本 中 的 处 理 方式 发 生 了 一 些 变 化 ， 简 单 来 说 就 是 不 支 
持 动 态 重 加 载 pol icy 了 。 所 以 可 以 看 到 se|inux_android load policy 
通过 1oad_successful 变 量 来 判断 系统 是 否 已 经 加 载 过 安全 策略 了 ， 如 
REESE ENE, BASRA. 


接着 尝试 打开 策略 文件 sepolicy_file。 在 Android N 版 本 之 前 ， 它 
是 一 个 数组 ， 定 义 如 下 : 


static const char *const sepolicy_file[] = { 
"/sepolicy", 
"/data/security/current/sepolicy", 
NULL }; 


变量 policy_index 的 初始 值 为 0， 但 是 会 随 着 set_policy_index 的 
调用 而 可 能 产生 变化 。 


Android N 版 本 中 的 情况 则 更 为 简单 ， 即 sepolicy_file 只 代 
表 “/sepolicy” 一 种 可 能 了 。 


如 果 open 成 功 的 话 ， 将 接着 执行 fstat。 这 个 函数 的 作用 是 获取 文 
件 的 当前 状态 ， 并 把 结果 存储 到 stat 数 据 结构 〈 上 述 代 码 中 对 应 的 是 sb 


变量 ) 中 。 


如 果 上 面 步 又 执行 正常 的 话 ， 我 们 就 可 以 开始 内 存 映射 mmap 了 ， 即 
将 fd 描述 的 文件 映射 到 sb. st_size。 注 意 mmap 的 第 一 个 参数 给 的 是 
NULL， 然 后 通过 了 泡 数 返回 值 将 指针 传递 给 map 变 量 。 一 切 准 备 就 绪 后 ， 
鲜 数 接着 执行 secur ity load policy: 


/*external/libselinux/src/load_policy.c*/ 
int security_load_policy(void *data, size_t len) 
{ 

char path[PATH_MAX]; 

int fd, ret; 


if (!selinux_mnt) { 
errno = ENOENT; 
return -1; 


} 


snprintf(path, sizeof path, "%s/load", selinux_mnt); 
fd = open(path, O_RDWR); 
if (fd < 0) 


return -1; 


ret = write(fd, data, len); 
close(fd); 
if (ret < 0) 
return -1; 
return 0; 


可 以 看 到 ， 这 个 函数 主要 是 通过 snpr intf 来 组 成 一 个 新 的 路 径 《〈 即 
在 selinux_mnt 的 尾部 加 上 “/load”) ， 并 将 这 个 path 指 示 的 文件 打 
开 ， 然 后 把 data (BI “/sepol icy” 安全 策 RAR SCF) a 
径 中 。 概 括 来 说 ， 就 是 把 Android 的 策略 文件 通过 SEL inux 的 挂 载 点 
到 内 核 中 。 


执行 完 上 述 函 数 和 selinux_android_load_ policy 后 ， 我 们 回 到 
sel AA ize 中 继续 分 析 。 如 果 加 载 策 SRR AMEE, 说 明 当 前 系 
统 出 现 了 非常 严重 的 问题 ， 因 而 设备 将 直接 重启 并 进入 recovery 模 式 。 


如 果 策 略 加 载 成 功 ， 接 下 来 还 需要 初始 化 sehandle， 然 后 调用 
secur ity_setenforce 将 系统 的 SELinux 设 置 为 合适 的 状态 ， 即 : 


如 果 系 统 属性 ro. boot. sel inux 没 有 设置 或 者 为 enforcing， 进 入 
enforcing 状 态 ; 否则 ， 如 果 ro. boot. sel inux 等 于 permissive， 则 进入 
自由 模式 : 


/*external/libselinux/src/setenforce.c*/ 
int security_setenforce(int value) 
{ 

int fd, ret; 

char path[PATH_MAX]; 

char buf[20]; 


if (!selinux_mnt) { 
errno = ENOENT; 
return -1; 


} 


snprintf(path, sizeof path, "%s/enforce", selinux_mnt); 
fd = open(path, O_RDWR); 
if (fd < 0) 

return -1; 


snprintf (buf, 
ret = write(fd, buf, 
close(fd); 
if (ret < 0) 

return -1; 


sizeof buf, "%d", value); 
strlen(buf)); 


return 0; 


由 上 述 代 码 段 可 知 函 数 secur ity_setenforce 和 前 面 讲 解 的 
security_load_policy 是 类 似 的 ， 均 是 通过 向 selinux_mnt 下 的 文件 写 


入 数据 来 与 内 核 中 的 SELinux 进 行 通信 。 这 样 一 


来 我 们 就 把 Android 上 层 


的 安全 策略 成 功 与 入 到 Linux 的 LSM 模 块 中 ， 并 设置 了 正确 的 防护 模式 


了 ， 如 图 22-18 所 示 。 


hell@hwmt?:/sys/fs/selinux $ ls -1 
ls 一 1 
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A 22-18 /sys/fs/selinux 文 件 结构 


从 本 小 节 的 分 析 大 家 应 该 不 难 发 现 ，init 程 序 
policy 策 略 通 常情 


access 
avec 

boo leans 
checkreqprot 

class 
commit_pending_hbools 
context 

create 

deny_unknown 

disable 

enforce 
initial_contexts 
load 

member 

mls 

null 

policy 

policy capabilities 
policyvers 

_unknown 


reject 
re label 
status 


user 





向 SELinux 设 置 的 


况 下 就 来 源 于 设备 根 目录 下 的 sepolicy 文 件 ， 而 后 者 


又 是 由 A0SP 工 程 下 的 /enternal/sepolicy 的 各 种 . te 编译 而 成 的 。 


那么 init 进 程 自身 的 安全 上 下 文 是 什么 呢 ? 


在 Android 旧 版 本 中 ， 它 是 在 init. rc 中 通过 setcon 接 口 直接 指定 
的 ;目前 版 本 中 的 实现 则 略为 复杂 ， 会 把 init 拆 分 成 两 个 阶段 。 


Stage1 : 


此 时 init 进 程 运行 在 kernel domain 中 ， 同 时 selinux_initialize 
的 函数 入 人 参 in_kerne1_domain 为 true， 所 以 说 前 述 的 安全 策略 的 加 载 过 
程 就 是 在 这 一 阶段 完成 的 。 


在 执行 完 第 一 阶段 的 se 1 inux_initializela, initi#tFeAyma i neg ay 
会 re-exec 程 序 ， 并 人 为 地 添加 一 个 参数 “--second-stage”， 从 而 进 
入 第 二 阶段 。 


Stage2 : 


此 时 in_kernel_domain 为 false， 并 且 init 进 程 运行 于 init domain 
下 。 


另外 ，init 文 件 的 安全 上 下 文 关联 是 由 restorecon ("/init") 完 成 
的 ， 对 应 的 源码 如 下 所 示 : 


/*system/core/init/init.cpp*/ 
if (is_first_stage) { 
if (restorecon("/init") == -1) { 
ERROR("restorecon failed: %s\n", strerror(errno)); 
security_failure(); 


国 数 restorecon 会 在 system/sepolicy/file_contexts 提 供 的 信息 
CEE: file_contexts 会 和 其 他 策略 一 起 放 在 设备 的 /sepolicy 文 件 
E) 去 查找 上 述 指 定 的 路 径 ， 最 终 匹 配 到 如 下 内 容 : 


/init u:object_r:init_exec:s0 
也 就 是 说 init 文 件 的 type 是 init_exec 〈 可 执行 文件 ) 。 


除了 init 外 ， 系 统 中 还 运行 着 很 多 其 他 的 进程 ， 例 如 
zygote (app_process) 、 各 应 用 程序 进程 等 。 读 者 可 以 在 本 小 节 的 基础 


上 自行 分 析 它 们 的 安全 上 下 文 是 如 何 完 成 关联 操作 的 。 
22.4.7 ”SEAndroid 中 的 客体 


SEAndroid 中 的 客体 包括 系统 文件 、 应 用 程序 文件 、 系 统 属性 等 很 
多 被 保护 的 资源 对 象 。 为 了 简化 分 析 ， 本 小 节 我 们 以 应 用 程序 文件 为 例 
来 讲解 一 下 它们 是 如 何 关联 安 全 上 下 文 的 。 


与 系统 文件 这 类 预 置 的 资源 不 同 (系统 文件 主要 由 file_contexts 
来 设 定 安全 上 下 文 ) ， 应 用 程序 的 文件 多 数 是 在 程序 安 北 或 者 运行 过 程 
中 才 会 产生 ， 而 且 用 户 设备 将 要 安装 哪些 应 用 程序 事先 是 未 知 的 ， 所 以 
针对 它们 的 处 理 方式 也 需要 更 加 灵活 。 


我 们 知道 ， 应 用 程序 专 有 的 数据 存储 目录 在 /data/data 中 ， 因 而 问 
题 自 然而 然 地 转化 为 : 这 个 目录 下 的 文件 夹 和 文件 是 如 何 关 联 安全 上 下 
文 的 呢 ? 进一步 来 讲 ， 它 们 又 是 由 PackageManagerService 和 和 installd 
在 应 用 程序 的 安装 过 程 中 创建 的 ， 所 以 需要 重点 关心 的 就 是 这 两 个 系统 
服务 了 。 


应 用 程序 的 具体 安装 过 程 在 本 书 其 他 章节 已 经 有 过 详细 分 析 ， 这 里 
不 再 苍 述 。 我 们 只 要 知道 PMS 会 调用 installer. java 中 的 instal1 接 口 来 
发 起 一 个 安装 过 程 就 可 以 了 ， 原 型 如 下 所 示 : 


public int install(String uuid, String name, int uid, int gid, St 


大 家 应 该 注意 到 了 最 后 一 个 函数 参数 seinfo， 它 是 PMS 通 过 前 面 小 
节 曾 讲解 过 的 system/sepolicy 下 的 专门 文件 mac_permi ssions. xml Rž% 
取 的 〈 应 用 程序 签名 和 seinfo 有 对 应 的 映射 关系 ) 。 


系统 服务 instal1d 将 响应 PMS 的 安装 请 求 ， 并 通过 
selinux android setfilecon 来 为 应 用 程序 的 data 目 录 设 置 上 下 文安 全 


/*external/libselinux/src/Android.c*/ 

int selinux_android_setfilecon(const char *pkgdir, 
const char *pkgname, 
const char *seinfo, 
uid_t uid) 


char *orig_ctx_str = NULL; 


out: 


err: 


oom: 


char *ctx_str 
context_t ctx 
int re = -1; 


NULL; 
NULL; 


if (is_selinux_enabled() <= 0)//SELinux# JF A 
return 0; 


rc = getfilecon(pkgdir, &ctx_str); 
if (re < 0) 
goto err; 


ctx = context_new(ctx_str); 
orig_ctx_str = ctx_str; 
if (!ctx) 

goto oom; 


rc = seapp_context_lookup(SEAPP_TYPE, uid, 0, seinfo, 
if (re == -1) 

goto err; 
else if (rc == -2) 

goto oom; 


ctx_str = context_str(ctx); 
if (!ctx_str) 
goto oom; 


rc = security_check_context(ctx_str); 
if (re < 0) 
goto err; 


if (strcmp(ctx_str, orig_ctx_str)) { 
rc = setfilecon(pkgdir, ctx_str); 
if (re < 0) 
goto err; 


freecon(orig_ctx_str); 
context_free(ctx); 
return rc; 


pkgnam 


selinux_log(SELINUX_ERROR, "%s: Error setting context for p 


__FUNCTION__, pkgdir, uid, strerror(errno)); 
re = -1,; 
goto out; 


selinux_log(SELINUX_ERROR, "%s: Out of memory\n", __FUNCTIO 


rc = -1; 
goto out; 


libselinux 是 对 SELinux 的 上 层 封 装 ， 以 使 程序 可 以 非常 方便 地 使 
用 SELinux 机 制 。 在 上 述 这 个 函数 中 ， 我 们 首先 判断 当前 是 否 已 经 开启 
了 SELinux 安 全 机 制 ， 只 有 在 答案 是 肯定 的 情况 下 ， 才 需要 执行 下 一 步 
操作 。 紧 接着 的 getfi lecon 是 获取 目录 路 径 的 当前 安全 上 下 文 (目录 的 
默认 安全 上 下 文 将 继承 自 它 的 父 目 录 ) ， 并 将 其 保存 在 ctx_str 变 量 中 。 
有 了 这 个 基础 后 ， 再 创建 新 的 context 就 有 依据 了 一 一 前 后 两 个 context 
最 大 的 不 同 在 于 Type， 而 新 的 Type 值 则 由 seapp_context_lookup 来 负责 
获取 。 


最 后 ， 如 果 两 个 context 之 间 存 在 差异 的 话 (strcmp 不 等 于 0) ， 那 么 
我 们 就 调用 setfi lecon 来 为 应 用 程序 的 目录 设置 新 的 环境 ， 从 而 完成 它 
的 安全 上 下 文 关 联 。 


22.5 Androidix Root fai tT 


如 何 获 取 Root 权 限 是 Android 中 一 个 老生 常 谈 的 话题 。Root 这 个 词 
虽然 大 家 都 耳熟能详 ， 但 是 究竟 应 该 如 何 定义 它 呢 ? 从 系统 设计 的 角度 
来 看 ，Root 是 一 个 “名 词 ”， 它 代表 的 是 一 个 操作 系统 〈 如 Linux) 的 
最 高 权限 用 户 〈Superuser) 。Linux 操 作 系 统 中 ， 不 同 user 针 对 同一 个 
文件 的 操作 权限 是 有 区 别 的 ， 而 Root 则 拥有 至 高 无 上 的 权利 理论 上 
讲 它 对 任何 文件 都 具有 “ 生 杀 予 夺 ” GES: 在 开启 了 SEAndroid 的 设 
备 上 ，Root 的 权限 受到 了 限制 ) 的 大 权 。 也 因为 它 的 权利 过 大 ， 所 以 通 
eo DA E a 后 者 则 会 被 加 以 各 种 强制 约 


Android 操 作 系统 虽然 没有 用 户 登 录 的 概念 ， 但 却 也 有 U1D 的 存在 。 
而 除了 系统 开始 时 短暂 的 “放权 ”外 ， 所 有 后 续 启动 的 应 用 程序 都 只 
非常 有 限 的 普通 权限 。 由 此 就 引申 出 了 Root 的 动词 用 法 ， 即 “获取 Root 
权限 ”。“ 道 高 一 太 ， 魔 高 一 丈 ”，Root 技 术 总 是 要 随 着 Android 系 统 
的 更 新 换代 而 “天 天 向 上 ”。 


目前 市 面 上 已 知 的 Root 手 段 既 有 手工 的 ， 也 有 各 种 “XxX Xx 一 键 
Root” 之 类 的 便捷 工具 。 不 过 ， 大 家 应 该 知道 ， 并 非 所 有 Android 设 备 
都 可 以 被 轻松 Root 。 这 一 方面 和 Android 版 本 有 关 一 一 通常 情况 
下 版 本 越 高 ，Root 的 难度 也 越 大 。 这 同时 也 说 明了 Android 项 目 在 安全 
性 保护 方面 也 在 日 趋 成 熟 。 另 一 方面 ， 一 些 设备 广 商 们 为 了 更 好 地 保护 
用 户 的 利益 ， 也 会 对 产品 实施 “刷机 加 锁 ” (比如 华为 系列 手机 就 有 类 
似 的 保护 ) 。 这 就 意味 着 各 位 发 烧 友 们 可 能 需要 先进 行 解 锁 操 作 后 ， 才 
有 办 法 实施 各 种 Root 方案 。 当 然 ， 很 多 大 的 设备 厂商 也 会 提供 专门 的 渠 
Se 例如 华为 EMUI 提 供 的 官方 
网 址 如 下 : 


http://emui.huawei.com/cn/plugin. php?id=unlock&mod=detail 


那么 如 何 才能 越过 系统 设置 的 重重 障碍 ， 获 取 到 Root 权限 呢 ? 我 们 
就 以 曾经 风靡 一 时 的 “adbd 提 权 ” 为 例 ， 为 大 家 阐释 一 下 利用 系统 漏洞 
达到 “非法 ”手段 的 大 致 原理 。 


不 过 在 讲解 这 个 Root 手 法 之 前 ， 我 们 有 必要 先 补 充 一 些 基础 知识 。 





相信 做 过 Android 开 发 的 人 都 清楚 ，Android 原 生 模 拟 器 默认 情况 下 
提供 的 就 是 Root 权 限 。 我 们 可 以 通过 adb she11 来 针对 模拟 器 做 一 下 验 
证 ， 如 下 所 示 : 


:Wesers\xs@>adb shell 


root@generic:/ # 





为 什么 模拟 器 中 的 she11 可 以 获取 到 Root 权限 呢 ? 原因 就 在 于 系统 
属性 的 配置 。 我 们 知道 ，adb 最 终 是 通过 设备 中 的 adbd 来 完成 任务 的 ， 
而 adbd 的 父 进 程 其 实 就 具有 Root 权 限 。 当 adbd 局 动 后 ， 会 调用 如 下 的 函 
数 来 判断 是 否 要 主动 降低 权限 : 


/*system/core/adb/adb.c*/ 
static int should_drop_privileges() { 
#ifndef ALLOW_ADBD_ROOT 
return 1; 
#else /* ALLOW_ADBD_ROOT */ 
int secure = 0; 
char value[PROPERTY_VALUE_MAX]; 
property_get("ro.kernel.qemu", value, ""); 
if (strcmp(value, "1") != 0) { 
property_get("ro.secure", value, "1"); 
if (strcmp(value, "1") == 0) { 
// don't run as root if ro.secure is set... 
secure = 1; 
property_get("ro.debuggable", value, ""); 
if (strcmp(value, "1") == 0) { 
property_get("service.adb.root", value, ""); 
if (strcmp(value, "1") == 0) { 
secure = 0; 
} 


} 


return secure; 
#endif /* ALLOW_ADBD_ROOT */ 


} 


上 面 这 段 代 码 的 逻辑 是 : 如 果 没 有 定义 ALLOW_ADBD_R00T， 那 么 就 
直接 返回 1， 表 示 需 要 降 权 。 否 则 接着 判断 系统 属 
性 “ro. kernel. qemu”， 如 果 值 为 1 表示 当前 是 qemu 模 拟 器 ， 那 么 就 直 
接 返 回 0， 表 示 不 要 降低 权限 ; 如 果 当 前 不 是 模拟 器 也 仍然 有 机 会 获取 
到 Root 权限 一 一 不 过 必须 满足 “ro. secure” 没 有 被 置 为 1， 或 者 当前 是 


可 调试 状态 〈 
状态 (“ro. debuggable” 为 1) H “service. adb 
.adb. root” 为 1。 


状态 梳理 图 如 图 22-19 所 示 。 






ro.kemel. qemu 


| 4 
{ 
ro,debuggable 
service.adb.toot 


ALLOW ADBD ROOT 








> 







全 图 22-19 adbd&t F F RIEA Fi hy ee 


也 就 是 说 ，adbd 在 一 开始 时 是 以 Root 权限 来 运行 的 ， 并 且 会 在 后 期 
利用 should_ drop_privileges 的 返回 结果 来 判断 自己 是 否 需要 执行 降 权 
操作 。 对 这 个 过 程 的 梳理 给 了 我 们 至 少 如 下 两 点 启发 : 


。 如 果 在 真 机 设备 中 ，should_drop_ptivileges 也 可 以 像 模 拟 器 中 的 情况 
那样 返回 0， 那 么 adbd 或 许 就 会 一 直 以 Root 权限 来 运行 了 ; 

e 即便 是 should_drop_ptivileges 本 身 返 回 1， 但 是 adbd 在 执行 降 权 操作 
时 失败 了 ， 那 么 它 也 可 能 会 一 直 以 Root 权限 来 运行 了 。 


上 述 这 两 条 其 实 就 是 早期 Android 版 本 中 adbd 提 权 的 重要 依据 ， 很 
多 Root 手 法 就 是 利用 它们 来 达到 目的 的 。 壁 如 有 一 个 研究 小 组 ， 就 使 用 
了 一 种 巧妙 的 手法 来 让 adbd 的 降 权 操作 失败 一 一 首先 ， 在 系统 中 产生 足 
够 多 的 she11 用 户 僵尸 进程 ; 然后 强制 结束 掉 原 有 的 adbd 进 程 ， 人 迫使 它 
被 重启 。 因 为 内 核对 于 用 户 可 以 运行 的 进程 数量 是 有 限制 的 ， 所 以 adbd 
在 切换 到 she1 1 身份 时 就 会 遭遇 失败 。 再 加 上 早先 Android 版 本 对 此 并 没 
有 做 必要 的 处 理 ， 最 终 得 到 的 结果 就 是 adbd 会 以 Root 身份 来 一 直 运 行 ， 
我 们 的 目标 也 就 达到 了 。 


除 此 之 外 ，Root 过 程 还 有 很 多 党 用 的 手法 ， 例 如 利用 栈 溢出 来 执行 
非法 操作 ; 利用 “0 地 址 ”造就 特殊 的 函数 调用 等 。 


一 旦 有 可 控 的 程序 获取 到 了 Root 权限 后 ， 接 下 来 我 们 还 可 以 执行 如 
下 几 步 操作 。 


Step1. 将 su 程序 放置 到 /system/bin 下 。 


Step2， 将 Superuser. apk (或 者 其 他 管理 者 程序 ) 放置 
到 /system/app 下 。 


Step3. 管理 权 限 申请 。 


这 样 做 的 目的 是 方便 我 们 对 Root 权限 进行 管理 。 举 个 例子 来 说 ， 如 
果 系 统 本 身 已 经 被 Root ， 那 么 也 可 以 通过 下 面 的 方法 来 为 adbd 提 取 : 





D=\game>adb shell 
she ll@Lan?79:/ $ su 


she ll@Lan??79:/7 # 





这 种 方式 需要 得 到 系统 中 Root 管理 者 的 批准 ，Android 系 统 中 最 有 
名 的 Root 管 家 是 Superuser， 界 面 如 图 22-20 所 示 。 


其 他 应 用 程序 在 已 Root 设 备 上 的 提 权 过 程 也 是 类 似 的 。 


了 解 了 adbd 的 提 权 示例 后 ， 我 们 再 来 讨论 下 如 何在 程序 中 判断 当前 
设备 是 否 被 Root 过 ? 


superuser 请 GETELITE 


已 显示 2 条 记录 
2015-11-24 22:01 shell 被 允许 


21:59 shell 被 允许 





全 图 22-20 界面 


典型 的 方法 有 两 种 ， 其 一 是 读 取 /system/bin/ 或 者 /system/xbin 目 
其 二 就 是 直接 执行 su 程序 并 观察 执行 情况 ， 范 例 
AT: 


Runtime.getRuntime().exec("su"); 


当然 ， 这 两 种 方法 都 可 能 有 缺陷 ， 并 不 能 保证 100% 的 准确 性 。 不 过 
对 于 大 多 数 应 用 场景 还 是 有 参考 价值 的 。 


Root 本 身 是 一 个 相对 复杂 的 过 程 。 随 着 时 间 的 推移 ， 和 Android 系 
统 的 不 断 更 新 换代 ，“ 攻 ”与 “ 防 ” 之 间 的 较量 也 在 更 替 进 行 ， 复 杂 程 
度 也 越 来 越 高 。 在 这 些 Root 方法 中 ， 很 多 都 是 借助 于 系统 自身 的 漏洞 
〈 而 且 多 数 属于 Linux 的 漏洞 ) 来 完成 的 。 随 着 漏洞 不 断 被 填补 ， 发 掘 
新 的 漏洞 的 难度 也 越 来 越 大 了 。 当 然 ， 还 有 一 个 方法 也 值得 一 试 ， 

即 “ 带 Root 的 Rom” 包 。 因 为 Android 系 统 本 身 就 是 开源 的 ， 所 以 要 制作 
一 个 带 Root 权 限 的 Rom 包 并 非 难 事 。 这 也 在 另 一 侧面 带 火 了 刷机 市 场 ， 
导致 市 面 上 各 式 各 样 的 Rom 品种 层出不穷 。 


22.6 APK 的 加 固 保护 分 析 


APK 加 固 保 护 是 近 几 年 应 用 程序 开发 的 一 个 趋势 ， 它 的 出 现 和 当前 
的 市 场 环境 有 很 大 关系 。 


中 国 互 联网 协会 12321 所 提供 的 报告 显示 ，“2015 年 12 月 ， 共 有 269 
款 App 受 到 了 12321 举 报 中 心 和 应 用 商店 的 联动 下 架 处 置 。 被 下 架 App 数 
量 比 11 月 增加 83 款 ， 环 比 增加 44. 6%。 在 269 款 具有 危害 风险 的 App 中 ， 
RAGE ET AMADA 195m, 具有 恶意 广告 行为 的 pp 有 71 款 ， 具 有 色 

青 内 容 的 App 有 14 款 ” ， 如 图 22-21 所 示 。 


而 这 些 被 下 架 的 App 中 ， 不 乏 一 些 知名 软件 。 它 们 并 非 有 意 制 造 亚 
ai e ee eee 徒 提供 了 “可 趁 之 


从 技术 实现 的 角度 来 看 ， 入 侵 App 的 手段 有 很 多 。 换 言 之 ， 加 固 保 
护 方式 也 需要 覆盖 这 些 可 能 的 场景 ， 包 括 但 不 限于 如 下 几 种 : 


e 防止 二 次 打包 ; 
© 防止 反 编 译 ; 
。 防止 筑 改 ; 

。 防止 调试 ; 





防止 穷 取 ; 
防止 注入 。 
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全 图 22-21 2015 下 半年 App 问 题 统 计 
(AIR F 12321) 


接 下 来 我 们 对 其 中 的 经 典 保护 手法 进行 细 化 讲解 。 
(1) 防止 二 次 打包 


如 果 Android 应 用 程序 未 采取 任何 保护 措施 的 话 ， 那 么 对 其 进行 二 
次 打包 还 是 比较 容易 的 。 这 主要 是 由 于 Android 系 统 对 程序 的 要 求 只 是 
自 签 名 ， 而 不 需要 权威 机 构 的 认证 。 因 而 部 分 不 法 之 徒 完全 可 以 解析 原 
有 的 APK 文 件 ， 添 加 或 者 纂 改 其 中 的 内 容 ， 然 后 二 次 打包 来 得 到 一 个 新 
的 程序 文件 。 那 么 如 何 防止 程序 被 二 次 打包 呢 ? 


我 们 知道 ，Android 系 统 虽 然 是 自 签名 ， 但 是 在 安装 时 还 是 会 做 校 
验 工作 一 一 任何 无 法 通过 校 验 的 程序 都 是 无 法 正常 使 用 的 “详细 信息 可 
以 参考 本 书 应 用 程序 打包 章节 ) 。 因 而 对 于 那些 被 算 改 了 内 容 的 APK 文 
件 来 说 ， 如 果 希 望 能 在 Android 系 统 中 正常 运行 的 话 ， 就 必须 经 过 重 签 
名 。 换 句 话说 ， 只 要 我 们 可 以 检测 出 程序 的 签名 和 原始 签名 是 否 产 生 了 
差异 ， 那 么 理论 上 就 能 侦查 出 APK 被 自 改 的 情况 了 。 


防止 二 次 打包 的 一 个 典型 处 理 逻 辑 是 : 

Step1， 程 序 局 动 ; 

Step2， 获 取 当 前 APK 的 签名 ; 

Step3. 获取 正确 的 签名 ; 

Step4. 判断 二 者 是 否 有 变化 。 

虽然 步骤 并 不 复杂 ， 但 其 中 的 实现 细节 还 需要 进一步 其 酌 。 比 如 在 
程序 的 什么 地 方 启动 上 述 逻 辑 ， 如 何 获取 到 正确 的 签名 ， 判 断 签 名 是 否 
变更 的 代码 段 是 否 也 可 能 被 人 破解 并 算 改 等 。 假 如 验证 二 次 打包 的 代码 
本 身 就 存在 安全 隐患 ， 那 么 它 的 输出 结果 就 存在 不 可 确定 性 了 。 这 些 都 
是 我 们 在 为 App 设 计 安全 保护 时 需要 去 深究 的 。 

(2) 防止 反 编译 


反 编 译 是 利用 一 定 手 段 ， 获 取 到 程序 可 读 代 码 《因为 混淆 机 制 的 存 
在 ， 通 党 情况 下 是 没有 办 法 完全 还 原 出 原始 代码 的 ) 的 过 程 。 获 取 到 的 
程序 可 读 代 码 ， 可 以 被 用 于 分 析 程 序 内 部 的 运行 逻辑 。 因 而 如 何 守 住 这 

一 轮 攻 击 ， 对 于 保护 程序 也 至 关 重 要 。 


当前 市 面 上 已 经 有 很 多 成 熟 的 反 编译 工具 ， 除 了 收费 版 本 外 ， 还 不 
乏 一 些 主流 的 开源 工具 “例如 ApkToo1 和 ApkAnalyser 都 可 以 从 github 找 
到 对 应 的 源码 工程 ) 。 这 些 反 编译 工具 的 功能 都 是 类 似 的 ， 包 括 但 不 限 
于 : 反 编 译 、 修改 、 优化 、 dex 转 jar、 签名 、 打包 等 。 


防止 反 编译 的 一 个 关键 点 在 于 ， 如 何 让 上 述 这 些 工 具 (或 者 其 他 同 
类 衍生 产品 ) 或 者 反 编译 手法 “ 功 败 垂 成 ”。 


最 直接 的 办 法 ， 就 是 对 保护 对 象 进行 加 密 。 辟 如， 如果 是 为 了 
TE 那么 就 可 以 对 其 中 的 dex 文 件 执行 加 密 操 
作 。 当 然 ， 仅 仅 对 dex 做 加 密 是 不 够 的 ， 因 为 我 们 还 需要 告诉 Android 系 
统 如 何 运 行 被 处 理 过 的 dex， 即 程序 在 运行 过 程 中 的 解密 操作 。 


典型 的 处 理 步骤 如 下 所 示 : 


Step1， 将 原 classes. dex 做 加 密 操作 ， 并 将 处 理 后 的 结果 《假设 名 
称 是 encrypted. data) 转移 至 APK 的 其 他 路 径 中 (如 assets 或 者 


resource 中 ) 。 


Step2. ee 训 进 行 加 壳 处 理 〈 也 可 以 将 encrypted. data 存 储 到 过 
程序 的 dex 中 ) 


Step3.， 当 程序 运行 时 ， 首 先 会 执行 壳 程 序 〈 通 常 是 通过 JNI| 和 so 动 
态 库 实现 的 ) ， 后 者 会 根据 预先 设计 的 逻 RAN a ET data. 


Step4， 壳 程序 对 加 载 后 的 data 进 行 解密 操作 。 

Step5， 执 行 解 密 后 的 dex 代 码 。 

上 述 步骤 中 我 们 提 到 了 一 个 重要 的 概念 一 一 过 (Shell) . Shel |F# 
非 是 Android 系 统 首创 的 ， 它 的 诞生 由 来 已 久 ， 例如 Linux 或 者 Windows 


操作 系统 中 也 经 常 采 用 这 种 技术 来 防止 程序 被 破解 。 其 基本 原理 可 以 参 
见 图 22-22。 





全 图 22-22 党 的 基本 原理 


在 Android 系 统 中 ， 壳 的 一 个 典型 应 用 束 是 上 面 所 提 及 的 dex 加 密 。 
其 内 部 原理 和 图 22-22 所 述 的 是 基本 一 致 的 ， 只 不 过 在 细节 处 理 上 有 些 
差异 。 大 家 可 以 从 “ 攻 ” 和 “ 防 ” 的 角度 来 再 多 思考 一 下 ， 在 Android 
系统 中 应 该 如 何 具体 落地 加 壳 措施 才 是 最 安全 的 。 


。 (3) WEZA 


执行 算 改 的 前 提 是 可 以 正确 反 编译 出 代码 ， 而 算 改 之 后 的 APK 能 
常 运行 于 Android 系 统 中 的 条 件 则 是 二 次 打包 ， 所 以 理论 上 来 讲 做 到 我 
们 前 面 分 析 过 的 两 点 就 可 以 有 效 阻止 算 改 事件 发 生 ae 


。 (4) 防止 动态 分 析 调 试 


那么 有 没有 可 能 在 不 改变 APK 的 情况 下 ， 来 完成 一 些 “ 非 常规 ”的 
cee 答案 是 肯定 的 ， 比 如 利用 调试 手段 来 获取 APK 的 某 些 关键 内 部 
在 Android 系 统 中 ， 能 否 调试 应 用 程序 是 需要 同时 满足 多 个 条 件 

(譬如 AndroidMan ifest. xm| 中 需要 指明 


android: debuggable= “true” ) 的 ， 因 而 我 们 可 以 从 这 些 条 件 入 手 防 
止 APK 被 调试 。 
另外 ， 除 了 预 置 这 些 条 件 外 ， 我 们 还 需要 阻止 第 三 方 人 员 非 法 算 改 
它们 。 一 个 简单 的 做 法 是 在 代码 中 做 二 次 检查 ， 确 保 这 些 条 件 符合 我 们 
最 初 的 设置 。 
。 (5) 防止 模拟 器 运行 
在 某 些 情况 下 ， 模 拟 器 可 以 为 非法 分 析 APK 提 供 便利 条 件 ， 例 如 : 


o 模拟 妖 可 以 很 方便 地 获得 root 权 限 ; 
o 模拟 器 对 应 用 程序 调试 条 件 的 限定 相对 宽松 。 


所 以 对 于 将 要 发 布 的 应 用 程序 ， 我 们 可 以 通过 一 些 必要 的 手段 来 阻 
止 它们 (或 者 增加 难度 ) 被 安装 和 运行 于 模拟 器 中 。 模 拟 器 和 真 机 从 多 个 
方面 都 存在 差异 ， 包 括 但 不 限于 : 

。 模拟 器 中 的 IMEI 号 并 不 是 真实 的 硬件 设备 号 ; 
o 模拟 器 中 的 dev 目 录 下 有 某 些 特殊 的 文件 ， 例 


如 /dev/socket/qemud; 
。 模拟 器 中 的 build 信 息 和 真 机 存在 差异 ; 


例如 模拟 器 的 BRAND 可 能 为 “generic”，HARDWARE 可 能 
FAV “goldfish” ; 











虽然 以 上 这 些 信 息 经 过 努力 都 是 可 以 被 伪造 出 来 ， 但 不 法 分 子 多 少 
都 需要 付出 一 些 额 外 的 代价 。 所 以 在 一 定 程度 上 可 以 提高 破解 的 难度 ， 
为 应 用 程序 增添 更 多 的 安全 性 。 


本 小 节 的 最 后 ， 我 们 再 来 对 加 固 技术 做 个 小 结 。 现 有 的 加 固 技术 虽 
然 很 多 ， 但 它们 大 多 具备 如 下 几 个 特点 。 


o 这 些 技术 的 实现 都 是 在 应 用 程序 进程 中 完成 的 ， 换 名 话说 它们 的 能 
力 在 一 定 程度 上 会 受 限于 Android 系 统 。 模 型 如 图 22-23 所 示 。 





framework 
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全 图 22-23 ”Andtoid 加 固 技术 实现 模型 简 图 


多 数 加 固 技 术 会 运用 到 反射 等 技术 来 完成 一 些 系 统 禁 止 的 “ 非 
法 ”操作 


这 样 一 来 随 着 Android 系 统 策 略 的 收 紧 ， 它 们 的 处 境 也 会 越 来 越 困 
难 。 壁 如 从 AndroidN 版 本 开始 ，Android 系 统 就 不 允许 应 用 程序 使 用 非 
标准 NDK 的 接口 ;对 于 反射 调用 系统 接口 的 做 法 也 子 以 控制 。 这 些 问题 都 
是 加 固 技术 所 需要 去 重点 考虑 的 。 


。 所 有 加 固 技术 都 必须 遵循 标准 的 Android 应 用 程序 生命 周期 

o 在 系统 调用 加 固 程 序 所 提供 的 代码 之 前 ， 它 们 必须 处 于 就 绪 状 态 

。 例如 加 壳 技 术 会 对 dex 或 者 部 分 函数 进行 加 密 保 护 ， 那 么 就 必须 保 
证 系统 在 访问 特定 函数 之 前 ， 后 者 已 经 被 解密 并 且 处 于 正确 的 状 
态 ， 这 样 一 来 应 用 程序 才能 正常 地 运行 。 


“ 攻 ” 和 “ 防 ” 是 一 个 相生 相克 的 过 程 ， 相 信 随 着 Android 系 统 的 
个 断 发 展 ， 市 面 上 会 出 现 更 多 的 加 固 和 解 固 技术 ， 租 请 期 待 。 





SHAR 
Android 系 统 工具 


Android 系 统 这 个 “大 杂烩 ”不 仅 融 合 了 众多 知名 的 开源 大 项 目 ， 
同时 也 有 各 式 各 样 的 小 工具 。 这 也 是 开源 工程 的 一 大 好 人 处， 可 以 最 大 限 
度 地 使 用 已 有 资源 ， 从 而 防止 重复 开发 。 而 且 通 过 合理 的 组 织 ， 各 个 工 
程 项 目 又 有 自己 独立 的 发 展 方向 ， 形 成 “百花 齐 放 ”的 局 面 。 


一 方面 ， 这 些 工 具 是 Android 系 统 不 可 或 缺 的 一 部 分 ， 如 adb， 
adt，logcat 等 。 无 论 是 系统 移植 、 驱 动 开 发 人 员 ， 还 是 上 层 应 用 程序 
的 开发 者 ， 相 信 都 不 可 避免 地 要 借助 它们 来 完成 项 目的 研发 工作 。 另 一 
方面 ， 我 们 在 实际 项 目 经 验 中 发 现 ， 不 少 工程 人 员 对 这 些 工 具 “ 只 知 其 
一 ， 不 知 其 二 ”。 换 名 话说， 只 对 他 们 常用 的 一 些 功 能 熟悉 ， 而 当 项 目 
提出 新 的 需求 时 就 束手无策 了 。 

这 主要 是 因为 不 少 人 没有 系统 地 研究 过 这 些 工 具 的 实现 原理 ， 所 以 
还 未 形成 完整 的 “知识 体系 ”。 本 篇 内 容 将 同时 从 理论 和 实践 两 个 角度 
来 思考 这 些 项 目 研 发 中 的 常用 工具 ， 和 希望 读者 在 学 习 后 对 它们 能 有 更 彻 
底 的 认识 。 
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IDE#OGradle 


Android Studio 除 了 让 越 来 越 多 的 开发 者 了 解 到 1ntel1iJ 这 个 优秀 
1DE 平 台 的 存在 外 ， 还 同时 “ 带 红 ”了 另 一 个 工具 ， 这 就 


是 “Gradle”。 


相信 大 家 对 这 个 新 一 代 的 自动 化 编译 工具 并 不 卫生 ， 因 为 Android 
Studio 上 的 应 用 程序 开发 默认 情况 下 就 采用 了 Gradle 做 为 自动 化 构建 工 
具 ， 如 图 23-1 所 示 。 
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A 23-1 Gradle# Android Studio 默 认 的 自动 化 工具 


那么 Gradle 为 什么 可 以 得 到 6oogle 如 此 的 青睐 ， 它 和 以 前 的 Ant、 
Maven 自 动 化 构建 工具 相 比 有 什么 区 分 呢 ? 对 于 普通 开发 人 员 来 说 ， 如 
何 了 迅速 掌握 Gradle 的 核心 要 点 ， 并 融入 到 这 一 新 家 庭 中 来 昵 ? 


这 些 都 是 我 们 在 本 章节 中 所 要 回答 的 问题 。 


23.1 Gradle 的 核心 要 点 


科技 的 发 展 历史 折射 出 一 个 潜在 的 规律 ， 即 一 个 新 技术 的 出 现 总 是 
伴随 着 行业 未 手 问题 的 解决 而 来 。 也 只 有 在 这 种 背景 下 产生 出 来 的 新 技 
术 ， 才 能 在 “ 适 者 生存 ”的 环境 中 获得 更 好 的 发 展 。 


对 于 不 少 开发 人 员 来 说 ， 新 技术 的 出 现 对 他 们 则 是 “有 利 有 
次 ”的 。“ 利 ”的 方面 就 是 可 以 帮助 他 们 更 快 地 解决 工作 中 的 难点 ， 捍 
脱 旧 技术 瓶颈 市 来 的 恒 梦 般 的 “ 修 修 补 补 ”; “BE” th RAMA, bean 
他 们 需要 对 现 有 工作 做 升级 改造 ， 需 要 学 习 一 门 新 的 技术 甚至 语言 等 ， 
这 些 都 意味 着 精力 和 时 间 成 本 的 投入 。 


换 句 话说 ， 如 果 一 门 新 技术 可 以 满足 以 下 两 点 条 件 ， 那 么 无 疑 将 获 
得 更 多 人 的 喜爱 。 


。 条 件 1: 较为 全 面 地 兼容 开发 者 的 现 有 工作 。 
。 条 件 2: 学 习 曲 线 相对 平缓 。 


Gradle 是 在 Ant、Maven 等 自动 化 编译 工具 “前 辈 ” 们 的 基础 上 发 展 
起 来 的 。 从 它 的 官方 宣传 中 可 以 看 到 ，Gradle 从 一 开始 就 吸收 了 以 上 这 
些 工具 的 优势 ， 并 通过 开创 性 的 技术 来 弥补 它们 中 的 不 足 。 从 这 个 角度 
上 来 讲 ，Gradle 是 满足 条 件 1 的 。 不 过 ， 由 于 Grad1e 的 很 多 知识 点 对 于 
开发 者 人 员 而 言 是 从 未 接触 过 的 〈 壁 如 Groovy 语 言 和 DSL， 更 多 的 人 可 
能 是 “只 闻 其 名 ， 未 见 其 身 ”) ， 所 以 初学 者 如 果 想 迅速 掌握 Gradle 并 
非 易 事 ， 甚 至 有 些 分 析 人 员 将 Gradle 的 学 习 曲 线 定 义 为 “非常 陡峭 ” ; 
也 有 部 分 开发 人 员 在 Gradle 官 方 论坛 表达 了 他 们 在 学 习 Gradle 过 程 中 的 
烦恼 ， 比 如 下 面 这 位 : 


“Being a newbie, | often struggle with creating the 
wiring necessary for writing and automated testing custom 
plugins. It's a big leap for a not-so-smart guy like me to go 
from Java/Ant/Ivy to Groovy/DSL/Gradle. 


Let me throw out another idea that might be unpopular: 
Provide more APIs and examples in pure Java. | think you might 


find more adopters if the learning curve didn't appear to be 
so steep. Sometimes, Groovy is the only way you can do some 
things. However, | constantly find myself being tripped up 
having to learn Groovy at the same time as Gradle. If | could 
just learn one thing at a time, that would have been better. 
It'd be great if the adoption curve had a roadmap with 
examples & APIs that were initially Java based with a few 
necessary Groovy closures and let people discover the more 
elegant solutions later on.” 


上 面 这 段 话 反映 出 了 不 少 初学 者 的 “烦恼 ”一 一 对 于 Groovy 等 新 语 
言 的 不 熟悉 ， 阻 碍 了 他 们 学 习 Gradle 的 步伐 。 再 加 上 Gradle 在 超越 前 辈 
们 的 同时 ， 也 需 要 更 多 创新 点 。 对 此 ，《Building and Testing 
Gradle》 有 过 精确 的 描述 ， 如 下 所 示 : 


“Gradle is occasionally described as a Groovy-based Ant. 
That would be the role that 


Gant fills, but Gradle has much more ambitious aims. 
Gradle offers the flexibility of 


Ant, which many teams still cherish, but with the 
dependency management style of 


Ivy, the intelligent defaults of Maven, the speed and 
hashing of Git, and the metaprogramming power of Groovy. That 
potent best-of-breed blend is an intrinsic motivator for 
joining the Gradle movement. ” 


但 是 对 于 开发 者 ， 特 别 是 普通 应 用 程序 开发 人 员 而 言 ， 并 不 是 所 有 
这 些 优秀 的 特性 对 他 们 都 是 必需 的 。 如 何 避 免 少 走 弯路 ， 把 精力 放 到 我 
们 需要 用 到 的 知识 点 的 学 习 上 ， 既是 Grad1e 初 学 者 共同 的 诉求 ， 同 时 也 
是 接 下 来 我 们 想 要 帮助 大 家 达成 的 目标 。 


23.1.1 Groovy 与 Gradle 


如 果 把 Gradle 构 筑 的 编译 工程 比 作 “大 厦 ” 的 话 ， 那 么 毫 不 夸张 地 
说 ，Groovy 是 这 栋 大 厦 的 “地 基 ” 。Gradle 正 是 站 在 巨人 的 肩膀 上 ， 充 


分 利用 了 Groovy 语 言 本 身 的 优秀 特性 才能 获取 如 此 迅速 地 发 展 。 


我 们 不 希望 在 本 书 中 大 谈 特 谈 Groovy 的 各 种 语法 ， 因 为 大 家 完全 可 
以 查阅 专门 的 资料 来 获取 这 些 信 息 。 本 小 节 的 重点 是 为 大 家 剖析 Groovy 
人 en once ce ne 
原理 。 


在 学 习 Gradle 的 过 程 中 ， 我 们 一 定 要 记 住 下 面 这 句 话 ， 这 有 利于 大 
家 在 游 走 于 Gradle 所 构筑 的 摩天 大 楼 中 不 至 于 迷失 方向 : 


Gradle 脚 本 是 基于 Groovy 语 言 的 ， 因 而 它 一 定 需 要 遵循 Groovy 





的 语法 


Groovy 和 Java 语 法 很 类 似 ， 从 这 个 角度 来 说 可 以 在 一 定 程 度 上 降低 
开发 人 员 学 习 新 语言 的 难度 。 同 时 ，Groovy 和 Java 可 以 达到 二 进 制 级 别 
的 兼容 一 一 换 句 话说 ， 对 JVM 而 言 它们 两 者 没有 任何 区 别 。Groovy 还 可 
以 使 用 Java 中 的 各 类 AP |， 两 者 可 以 进行 混合 编程 。 这 些 都 是 Groovy 这 

不 二 语言 与 生 俱 来 的 优势 。 


(1) 与 Gradle 相 关 的 Groovy 核 心 特性 1: 闭 包 (Closure) 
先 来 让 读者 有 一 个 感性 的 认识 ， 下 述 代码 段 就 使 用 到 了 闭 包 : 


def greeting = { "Hello, $it!" } 
assert greeting('Patrick') == 'Hello, Patrick!' 


第 一 行 语句 中 ， 我 们 定义 了 一 个 闭 包 greeting; 然 后 在 第 二 个 语句 
中 ， 通 过 向 闭 包 传 入 “Patr ick” 来 使 用 它 ， 并 判断 输出 结 采 是 否 符合 


预期 。 大 家 应 该 会 觉得 这 和 函数 调用 有 点 类 似 ， 只 不 过 更 为 新 颖 ， 而 且 
控制 更 加 灵活 。 


官方 对 Closure 的 定义 如 下 : 


A closure in Groovy is an open, anonymous, block of code 
that can take arguments, return a value and be assigned to a 
variable. 


它 的 基础 语法 规则 如 下 : 


{ [closureParameters -> ] statements } 


顾名思义 ，c1losure 需 要 一 对 “{} ”来 将 所 要 表述 的 代码 块 (block 
of code) “ 框 ” 起 来 ， 并 作为 一 个 整体 对 象 来 处 理 。 
[closureParameters -> ] 则 用 于 表示 这 个 闭 包 中 所 需 的 各 种 参数 ， 类 
似 于 Java/C 等 语言 中 的 函数 参数 。“[] ”表示 这 一 字段 是 可 选 的 ， 壁 如 
我 们 在 上 面 举 的 例子 中 就 没有 带 任 何 参 数 声明 。 不 过 这 并 不 代表 这 种 情 
况 下 Closure 是 没有 参数 的 ， 只 是 Groovy 会 自动 帮 有 我 们 判 断 和 分 析 ， 从 
而 省 去 了 人 工 书写 的 繁琐 过 程 。 紧 随 参 数 的 是 真正 的 代码 实现 部 分 
即 “statements”， 对 应 我 们 例子 中 的 “Hello，$it!”。 


为 了 加 深 大 家 的 理解 ， 我 们 再 从 Groovy 官 方 文档 中 摘录 部 分 合法 的 
Closure 样 式 来 供 大 家 参 者， 如 下 所 示 : 


{ -> item++ } 样式 1 
{ println it } 样式 2 
{ it -> println it } 样式 3 
{ name -> println name } 样式 4 
{ String x, int y -> 

println "hey ${x} the value is ${y}" 样式 5 
} 
{ reader -> 

def line = reader.readLine() 样式 6 


line.trim() 


{ item++ } 样式 7 
样式 1: A closure referencing a variable named item. 
样式 1: 通过 “->” 来 显 式 分 隅 开 闭 包 参 数 和 代码 实现 。 
样式 2: 使 用 隐 含 的 参数 “it” 


样式 3: 实现 和 上 一 样式 同样 的 功能 ， 只 不 过 这 一 次 参数 是 显 式 


样式 4: 在 茶 些 情况 下 最 好 使 用 显 式 的 参数 。 
样式 5: 在 闭 包 中 使 用 两 个 参数 。 

样式 6: 闭 包 中 可 以 包含 多 条 代码 语句 。 
样式 7: 完全 不 使 用 参数 的 情况 


ee 需要 了 解 闭 包 的 更 多 详细 资料 ， 建 议 大 家 可 以 参考 官方 的 文档 
说 明 。 
(2) 与 Gradle 相 关 的 Groovy 核 心 特性 2: Command Chains 


人 g VA 
用 。 举 个 例子 来 说 ， 有 如 下 一 个 函数 : 


void turn(String direction) 


//Do sth 


在 Java 语 法 下 ， 我 们 想 表达 “向 左 转 ”时 用 的 是 turn( “left” ); 
而 Groovy 下 则 可 以 让 也 数 调用 看 上 去 更 为 自然 : 


turn left 


GE: 个 人 认为 这 种 “自然 ”是 相对 而 言 的 ， 对 于 习惯 于 严格 的 语 
法 规则 的 开发 人 员 来 说 ， 这 种 “ 随 性 ”的 方式 反而 有 可 能 让 他 们 “无 所 
适 从 ”。 因 而 凡事 都 有 两 面 性 ， 应 该 一 分 为 二 地 看 待 问题 ) 


不 仅 如 此 ，Groovy 还 可 以 在 上 述 的 基础 上 让 多 次 的 连续 函数 调用 间 
不 需要 书写 “. ”。 也 就 是 说 当 同 左 转 了 以 后 还 需要 向 右 转 ， 那 么 
Groovy 中 的 表达 就 是 : 
turn left then right 


这 句 话 对 应 的 函数 调用 则 是 : turn( “left”).then( “right”)。 


这 就 是 Groovy 的 Command Chains 想 要 达到 的 效果 。 


当然 ， 这 种 表达 方式 如 果 遇 到 没有 涵 数 参数 的 情况 就 要 特别 注意 
Y, bean: 


select(all).unique().from(names) 


显然 如 果 还 按照 之 前 的 方式 来 表达 就 会 引起 混乱 ， 因 而 我 们 需要 这 
样 来 调用 : 
select all unique() from names 

因为 风格 不 统一 ， 这 个 语句 多 少 看 起 来 有 点 奇怪 。 所 以 在 使 用 
Groovy 的 这 一 特性 时 ， 建 议 大 家 多 想 一 下 有 没有 可 能 出 现 类 似 的 现象 ， 
不 然 很 可 能 是 “得 不 偿 失 ”的 。 

(3) 与 Gradle 相 关 的 Groovy 核 心 特性 3: 运算 符 重 载 

Groovy 中 的 不 少 运算 符 会 被 映射 为 针对 对 象 的 常规 函数 调用 。 壁 
如 : 
atb ”会 被 6roovy 解 释 为 a.plus(b) 


a-b 会 被 Groovy 解 释 为 a.minus(b) 
a[b]=c ”会 被 6roovy 解 释 为 a.putAt(b,c) 


开发 者 可 以 灵活 利用 这 个 特性 来 达到 一 些 特殊 的 效果 。 比 如 Gradle 
脚本 中 添加 一 个 task 可 以 采用 如 下 的 语句 : 


task helloworld << { 
println ‘hello, world' 


也 可 以 通过 如 下 语句 来 为 同一 个 task 添 加 多 个 action: 


task multiAction 
multiAction << { 
println 'This is ' 


multiAction <<{ 
printJln 'multiAction' 
} 


那么 当 我 们 执行 “gradle multiAction” 时 ， 会 打印 出 “This is 


multiAction” o 


(4) 与 Gradle 相 关 的 Groovy 核 心 特 性 4: ”动态 类 型 


Grad1le 和 不 少 脚本 语言 一 样 ， 可 以 不 需要 显 式 地 声明 变量 类 型 ， 而 
由 系统 在 运行 时 动态 地 识别 出 变量 的 类 型 。 如 下 代码 范例 所 示 : 


private TestFile hashFile(TestFile file, String algorithm, in 
def hashFile = getHashFile(file, algorithm) 
def hash = getHash(file, algorithm) 
hashFile.text = String. format("%0${len}x", hash) 
return hashFile 


} 


可 以 看 到 ， 变 量 hashF i le 和 hash 都 没有 特别 指明 它们 所 属 的 类 型 ， 
这 样 并 不 会 导致 任何 问题 〈 当 然 ， 主 动 声明 也 是 可 以 的 ， 比 如 变量 len 
Malgorithm) 。 另 外 ， 各 个 语句 间 不 需要 像 C++/C 和 Java 那 样 以 分 
号 “;” 相 隔 ， 这 种 做 法 普遍 存在 于 各 类 脚本 语言 中 。 


23.1.2 Gradle 的 生命 周期 
和 其 他 自动 化 编译 工具 一 样 ，Gradle 也 有 其 生命 周期 ， 具 体 而 言 包 


括 Initialization、Configuration 和 Execution 三 个 阶段 ， 如 图 23-2 所 
示 。 


build 






Initialization Configuration Execution 





files 


全 图 23-2 Gradle 的 生命 周期 


e Initialization 


在 初始 化 阶段 ，Gradle 的 主要 职责 是 定位 有 哪些 需要 处 理 的 bui Id 
文件 。 当 Gradle 启 动 后 ， 它 会 分 析 开 发 者 是 希望 编译 单个 工程 还 是 多 个 
工程 。 如 果 是 前 者 的 话 ， 它 会 识别 出 一 个 单独 的 bui 1d 文 件 并 作为 下 一 
阶段 的 输入 ; 而 如 果 是 多 个 工程 的 情况 ， 它 需要 找 出 潜在 的 多 个 bui 1d 
文件 并 让 它们 成 为 下 一 阶段 重要 的 编译 依据 。 


e Configuration 


在 配置 阶段 ，Gradle 会 根据 上 一 阶段 的 结果 主动 处 理 单 个 或 多 个 
buil1d 文 件 。 可 想 而 知 这 些 文件 对 它 而 言 都 是 Groovy 脚 本 ， 相 当 于 是 
Gradle 解 释 执 行 了 一 个 由 bui1d 源 代码 组 成 的 编译 “小 工程 ”。 


不 过 需要 特别 注意 的 是 ， 此 时 并 不 意味 着 Gradle 已 经 开始 进行 真正 
的 工程 编译 了 ， 它 在 这 一 阶段 的 目标 产物 实际 上 是 一 个 由 task 所 组 成 的 
DAGA] (Directed Acyclic Graph) 。 这 一 点 和 我 们 在 本 书 Android 系 统 
编译 章节 所 讲 的 Make 自 动 化 工具 非常 相似 ， 因 为 只 有 先决 定 出 Target 的 
依赖 关系 ， 才 能 够 保证 其 正确 地 获取 最 终 的 目标 产物 。 


男 外 ， 这 一 阶段 会 主动 回调 开发 者 编写 的 各 种 hook 方 法 (如果 有 的 
W) 。 


e Execution 


这 是 真正 体现 Gradle 价 值 的 一 个 阶段 ， 它 会 基于 上 一 步 中 的 DAG 结 
果 来 生成 目标 产物 。 人 毋庸 置疑 ，Grad1e 对 各 个 task 的 执行 顺序 是 严格 按 
上 照 它们 的 依赖 关系 的 。 所 有 的 bui 1d 活 动 (包括 编译 源码 、 拷 贝 文件 
等 ) 在 task 中 定义 的 action 都 将 在 这 一 阶段 得 到 执行 。 


开发 者 同样 可 以 为 这 一 阶段 设置 各 种 hook 方 法 ， 以 按照 自己 的 需求 
来 改变 Gradle 的 编译 行为 。 


经 过 这 3 个 阶段 ，Gradle 才 能 完成 它 的 自动 化 编译 使 命 。 由 此 可 以 
推断 ，Gradle 本 身 的 编译 过 程 不 会 很 快 ， 在 某 些 情况 下 (比如 依赖 于 网 
络 包 ) 甚至 会 出 现 让 用 户 感觉 “缓慢 ”的 现象 。 当 然 ， 鉴 于 Gradle 所 提 
供 的 非常 灵活 的 实现 方式 ， 这 些 代价 都 还 在 可 接受 的 范围 。 


23.2 ” Gradle 的 Console 证 法 


Android Studio 对 采用 Gradle 进 行 编译 的 方式 进行 了 封装 ， 让 开发 
者 只 需 单 击 几 个 按钮 就 可 以 完成 工作 了 。 因 而 如 果 开 发 者 不 需要 对 
build 脚 本 做 任何 修改 ， 那 么 我 们 并 不 一 定 要 掌握 Gradle 的 Console 语 
法 ;反之 如 果 我 们 希望 了 解 bui 1d 脚 本 的 运行 过 程 ， 并 根据 自己 的 需求 来 
编辑 bui 1d 文 件 ， 那 么 Gradle 的 命令 行 控制 方式 是 大 家 必须 要 熟悉 的 。 


从 Gradle 官 网 上 下 载 的 发 行 版 本 目录 结构 如 图 23-3 所 示 。 
其 中 bin 目 录 下 保存 的 就 是 Gradle 的 可 运行 文件 ， 如 图 23-4 所 示 。 

















名 称 类 型 大 小 

|l bin 文件 夫 

|] initd 文件 夫 

加 ib 文件 去 

| | media 文件 去 

[E] changelog.txt 文本 文档 1 KB 

[e] getting-started.html HTML 文件 855 KB 

| | LICENSE 文件 51 KB 

| NOTICE 文件 1 KB 
全 图 23-3 目录 结构 

名 称 类 型 大 小 

| ] gradle 文件 5 KB 

[=Œ] gradle.bat Windows 批 处 理 .. 3 KB 


全 图 23-4 可 运行 文件 


Windows 系 统 下 对 应 的 是 批 处 理 文件 “gradle. bat”。Gradle 是 基 
于 Groovy 语 言 的 ， 换 人 句 话 说 它 的 运行 环境 依赖 于 JVM， 所 以 这 个 bat 文 件 
a eee 并 通过 以 下 语句 来 局 动 和 运行 Gradle 的 
交心 程 序 : 


"%JAVA_EXE%" %DEFAULT_JVM_OPTS% %JAVA_OPTS% %GRADLE_OPTS% "-Dorg. 


Gradle 的 命令 行 语法 如 下 所 示 : 
gradle [option...] [task...] 


目前 支持 的 option 如 表 23-1 所 示 。 


表 23-1 Gradle 的 主要 option 释 义 


打印 帮助 信息 


指定 Gradle 的 settings 文 件 


指定 Gradle 的 build 文 件 


指定 Gradle 的 user home 日 录 


打开 调试 模式 


使 用 Gradle daemon 来 编译 工程 。Daemon 是 一 个 守护 进 
程 ， 优 点 是 可 以 在 非 首 次 编译 时 加 快速 度 ， 缺 点 则 是 












这 和 Jack Server 的 原理 是 基本 一 致 的 。 开 发 者 可 以 根据 
上 自己 的 需求 做 折衷 选择 











今 行 选项 ， 大 家 可 以 通过 使 用 “gradle --help” 来 获取 和 


Gradle 也 提供 了 GUI 形式 的 控制 万 式 ， 主 丙 面 如 图 23-5 所 示 。 
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全 图 23-5 ”Gradle 的 GUI 主 界面 


不 过 Gradle 所 提供 的 上 述 GU1 还 不 能 满足 Android Studio 1DE 的 需 


求 。 所 以 它 自 己 对 Grad1e 进 行 了 一 定 的 UI 封装， 如 图 23-6 右 边 部 分 所 示 
的 “Gradle tasks”。 
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Gradle tasks # >| 





È MyApplication6 x | [ok RepositoryHandler.class x| [bk Project.class x | Ò app x | 


an~lavel build tile where van can and contiguretion ontians emman to a 
Top-Level build file where you can add configuration options common to all 


Cbuildseript { 





repositories { 
jeenter() 
o] 
G dependencies { 
classpath ‘com. android. tools. build: gradle:1. 0.0 














Dallprojects { 





repositories { 


jente 


} 











ah 


sub-pr 





(j + 


| Recent tasks 


| MyApplication6 [generateDebugAssets] 


“All tasks 


È MyApplicationé 
} androidDependencies 
© assemble 
 assembleDebug 
 assembleDebugTest 
Ü assembleRelease 
build 
© buildDependents 
Ë buildNeeded 
check 
党 checkDebugManifest 
© checkReleaseManifest 
& clean 
& compileDebugAidl 
% compileDebugJava 
Č compileDebugNdk 
 compileDebugRenderscript 


A&23-6 Android Studio %}Gradle % 4h & 


Gradle 提 供 了 查询 工程 项 目 中 所 有 可 用 任务 的 命令 ， 即 “gradle 
task”。 一 旦 用 户 使 用 了 这 个 命令 ，Gradle 会 通过 解析 bui 1d 脚 本 来 分 
析 针 对 这 个 工程 项 目的 所 有 tasks。 上 述 的 “Gradle tasks” 实 际 上 就 
是 针对 这 一 命令 的 图 形 化 。 我 们 可 以 通过 一 个 小 实验 来 做 一 下 验证 ， 就 
是 给 bui 1d 脚 本 的 最 后 面 手工 添加 一 个 task， 如 下 所 示 : 


task aNewTask{ 
println “This a new task” 
} 


然后 单 击 Gradle tasks PAI © 来 刷新 列表 ， 更 新 后 的 结果 如 图 23- 


ove 
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全 图 23-7 更 新 后 的 结果 


可 以 看 到 左下 角 的 Message 框 中 打印 出 了 我 们 这 个 新 Task 中 定义 的 
Action, BJ “This is a new task”， 同 时 右边 部 分 的 “All tasks” tH 
列 出 了 新 增 的 这 个 任务 。 我 们 从 这 个 小 实验 还 可 以 得 出 男 一 个 结论 : 
Gradle 在 Configuration 阶 段 会 首先 处 理 Project Level 的 脚本 ， 然 后 才 


23.3 Gradle Wrapper #Cache 


Android 开 发 人 员 对 于 Gradle Wrapper 应 该 不 会 陌生 ， 因 为 不 论 是 
Intelliy 还 是 Android Studio， 都 提供 了 Wrapper 相 关 的 配置 项 ， 如 图 
23-8 所 示 。 





| Settings 


Editor 
> Copyright 
Emmet 
GUI Designer 
Images 
Intentions 
> Language Injections 
Spelling 
1000 
Plugins 
» Version Control 
¥ Build, Execution, Deployment 
Y Build Tools 
> Maven 
Gradle 
Gant 
Y Compiler 
Excludes 
Java Compiler 
Annotation Processors 
RMI Compiler 
Groovy Compiler 
Gradle-Android Compiler 
Android Compilers 
Coverage 
» Debugger 
Path Variables 
» Languages & Frameworks 
> Tools 
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日 
日 


a @ 


| 


a 。 E 


> 


Q) Buld Exeewtion Deployment» Build Tools Gradle © For curent project Reset 


Linked Gradle projects 





MyApplication3 


Project-level settings 
Use auto-import 
J Create directories for empty content roots automatically 
(*) Use default gradle wrapper (recommended) 


() Use customizable gradle wrapper () Gale wapper custoniaton in scipt ors wth Gradle 17 rte 











() Use local gradle distribution 

Gradle home; | C:\Program Files\Android\Android Studio\gradle\gradle-2.2.1 图 
Global Gradle settings 

Offline work 

Service directory path: CUsers\s0\ gradle B 








Gradle VM options: 





全 图 23-8 配置 项 


图 23-8 中 提供 了 3 个 单 选 项 。 


e Use default gradle wrapper 





这 是 推荐 的 方式 ， 使 用 wrapper 形 式 的 Ggradle。 
e Use customizable gradle wrapper 


使 用 定制 的 Gradle Wrapper. 


e Use local gradle distribution 


使 用 本 地 的 Gradle 版 本 。 


从 上 述 几 个 选项 中 大 家 应 该 能 大 概 猜 测 到 ，Wrapper 是 一 种 类 似 

于 “包装 纸 ” 的 东西 一 一 我 们 只 能 看 到 外 面 的 “接口 ”， 而 里 面 的 具体 
Sai wien ice. 这 样 的 话 我 们 就 可 以 不 要 求 开 发 机 器 上 
一 定 要 预先 安装 Gradle 了 ，Wrapper 会 根据 需要 自动 连接 网 络 ， 并 下 载 
Gradle 版 本 来 完成 编译 工作 。 


当 我 们 新 创建 一 个 利用 Gradle 来 构建 的 Android 工 程 〈 注 : 这 里 需 
要 特别 说 明 的 是 ，Android 工 程 并 非 只 能 通过 Gradle 来 构建 。 璧 如 早期 
的 Android 应 用 程序 开发 大 部 分 是 在 Eclipse 中 完成 的 ， 而 默认 的 构建 工 
具 是 Ant。 随 着 Android Studio 指 定 Gradle 为 默认 的 构建 方式 以 后 ， 越 
来 越 多 的 开发 者 采用 它 来 代替 之 前 的 构建 工具 ) 时 ，1DE 会 自动 为 我 们 
生成 一 个 Gradle 目 录 ， 其 中 就 包含 了 Wrapper 实 现 ， 如 图 23-9 所 示 。 


C3 MyApplication3 (C 
> © gradle 

© idea 

[3 app 

© build 

© gradle 


Ë] gradle-wrapper.jar 





[à gradle-wrapper.properties 
全 图 23-9 Gradle 目 录 


如 果 我 们 手工 删除 掉 这 个 Gradle 文 件 夹 ， 那 么 1DE 中 的 Gradle 配 置 
先 项 就 会 发 生变 化 ， 如 图 23-10 所 示 。 


Project-level settings 
[C] Use auto-import 
(_] Create directories for empty content roots automatically 


(©) Use default gradle wrapper (not configured for the current project) 


(©) Use customizable gradle wrapper  ( Gradle wrapper customization in script, works with Gradle 1.7 or later 


©) Use local gradle distribution 





Gradle home: | A | 





全 图 23-10 配置 选项 的 变化 


因为 无 法 找到 可 用 的 Wrapper，1DE 会 自动 将 之 前 
的 “recommended” 更 换 为 “not configured for the current 
project” o- 


通过 上 面 的 描述 ， 我 们 知道 Wrapper 应 该 随 工 程 文件 一 起 被 check 
in 到 version control 库 中 。 这 样 做 的 男 一 个 好 处 是 ， 用 户 总 可 以 使 用 
到 与 工程 最 匹配 的 Grad1e 版 本 来 完成 编译 ， 同 时 也 意味 着 持续 集成 服务 
器 上 不 需要 预先 安装 和 配置 Gradle 了 。 


那么 Wrapper 是 如 何 做 到 这 些 的 呢 ? 


事实 上 ， 除 了 前 面 所 述 的 Wrapper 文 件 外 ， 新 建 的 Android 工 程 根 目 
录 下 还 有 几 个 重要 的 可 执行 文件 ， 如 下 所 示 : 


E3 myapplication 
E] .gitignore 

O build.gradle 

[à gradle.properties 
E] gradlew 

E] gradlew.bat 


其 中 gradlew. bat 针 对 的 是 Windows 平 台 ， 而 gradlew 则 适用 于 其 他 
操作 系统 平台 。 这 和 前 一 小 节 中 所 见 的 Gradle 命 令 行 程序 可 以 说 是 “如 
Hi” 。 我 们 只 要 保证 Gradle 和 gradlew 在 “包装 纸 ” 上 保持 一 致 ， 


WARTS Ri A LAE “EAR” To 


理解 了 Gradle Wrapper 的 实现 原理 后 ， 我 们 最 后 再 简单 分 析 一 下 
gradle cache。 可 想 而 知 ，Gradle 程 序 本 身 ， 及 Gradle 脚 本 中 描述 的 工 
程 中 的 各 种 依赖 关系 库 在 构建 阶段 都 需要 在 本 地 存在 。 换 名 话说， 如 果 
发 现 这 其 中 有 任何 文件 缺失 的 话 ，Gradle 有 责任 通过 开发 者 声明 的 
jcenter 、maven 仓 库 去 获取 并 下 载 。 为 了 避免 多 次 地 重复 下 载 ，Gradle 
会 在 本 地 建立 一 个 cache 来 保存 这 些 文 件 。 


Gradle 同 样 提供 了 选项 来 帮助 开发 人 员 管 理 cache， 大 部 分 1DE 则 提 
供 了 更 为 便捷 的 GUI 界面 ， 如 图 23-11 所 示 是 Intel1iJ 中 的 截图 。 


Global Gradle settings 


[C] Offline work 











Service directory path: C:\Users\xs0\.gradle | vs | 





全 图 23-11 IntelliJ RA 


“Offline work” 会 告诉 Grad1le 不 要 尝试 连接 和 使 用 网 络 功 能 。 这 
会 出 现 两 种 情况 ， 假 设 本 工程 所 需 的 所 有 依赖 文件 和 内 容 在 本 地 都 可 以 
找到 ， 那 么 Gradle 仍 然 可 以 顺利 地 完成 编译 工作 ; 否则 它 会 报错 ， 并 提 
示 开 发 者 有 哪些 无 法 找到 的 文件 。 


“Service directory path” 就 是 Gradle 保 存 缓存 文件 的 地 方 ， 在 
Windows 操 作 系 统 下 通常 对 应 的 是 用 户 目 录 。 大 家 可 以 做 一 个 实验 来 证 
实 我 们 的 猜测 : 准备 两 台 PC， 其 中 一 台 可 以 正常 连接 网 络 ， 此 时 新 创建 
的 Android 工 程 应 该 可 以 成 功 编译 通过 ; 另 一 台 机 器 无 法 使 用 网 络 ， 并 
只 预先 安装 了 Gradle 的 发 行 版 本 ， 此 时 新 创建 的 Android 工 程 应 该 会 有 
依赖 文件 无 法 找到 EA i dE 
为 'com. android. tools. bui Id:gradle:1. 0.0' 的 Gradle 插 件 ) 。 此 时 如 
果 我 们 把 第 一 台 机 器 的 “Service directory path” 文 件 夹 中 的 内 容 复 
制 到 第 二 台 机 器 的 相应 位 置 ， 那 么 后 者 也 同样 可 以 正常 构建 和 运行 了 。 


关于 cache 还 有 很 多 技术 细节 ， 有 兴趣 的 读者 可 以 自行 研究 Gradle 
的 源码 来 了 解 详情 。 


23.4 Android Studio 和 Gradle 


23.4.1 Gradle 插 件 基础 知识 


Gradl1e 支 持 通 过 插件 的 方式 来 扩展 功能 ， 以 保证 开发 者 可 以 按照 自 
己 的 需求 来 完成 自动 化 构建 。 而 且 Gradle 插 件 允许 以 任何 语言 编写 一 一 
当然 前 提 是 插件 代码 最 终 可 以 被 编译 成 字 节 码 。 实 际 上 JVM 的 宗旨 是 成 
为 一 个 通用 的 规范 标准 ， 因 而 它 并 没有 强制 限定 开发 人 员 必 须 通 过 Java 
语言 来 编写 能 在 虚拟 机 上 运行 的 程序 。Groovy、Scala、Clojure 这 些 语 
言 都 充分 利用 了 JVM 的 这 一 特点 ， 既 在 巨人 的 肩膀 上 实现 了 自身 语言 的 
独特 优势 ， 同 时 也 保证 了 与 其 他 JVM 程 序 的 兼容 性 ， 可 谓 一 举 多 得 。 


除了 语言 的 选择 外 ，Gradle 还 提供 了 如 下 几 种 插件 编写 方式 “ 任 君 


选择 ”: 
e Build Script 


你 可 以 在 bui 1d 脚 本 中 直接 完成 插件 代码 的 编号 。 这 种 方式 的 缺点 
是 ， 代 码 只 能 在 一 个 脚本 中 使 用 ， 优 点 是 开发 编译 都 很 方便 ， 而且 
Gradle 会 自动 将 其 加 到 classpath 〈 注 意 ， 这 个 classpath 不 是 指 应 用 程 
序 工 程 中 的 classpath) 中 。 因 而 适合 于 插件 代码 不 多 ， 且 不 需要 与 其 
他 工程 共用 的 情况 。 


e buildstc 工 程 


除了 应 用 程序 工程 ，Gradle 脚 本 同样 也 可 以 作为 工程 进行 管理 。 默 
认 情 况 下 ， i 并 将 其 添加 到 
classpath: 


[Project_root]/buildSrc/src/main/groovy 


这 种 方式 的 可 见 范围 相 比 上 一 种 要 大 一 些 ， 即 这 个 应 用 程序 工程 的 
所 有 buil1d 脚 本 中 都 可 以 使 用 ， 但 也 仅 限 于 本 应 用 程序 范畴 。 


e Standalone project 


以 独立 工程 的 形式 来 实现 Grad1e 插 件 是 不 少 开发 者 的 选择 ， 特 别 是 


那些 应 用 范围 广泛 的 插件 ， 如 android plugin。 在 这 种 情况 下 ， 插 件 以 
JAR 包 存在 ， 并 支持 在 一 个 包 中 包含 多 个 插件 。 


接 下 来 我 们 将 以 一 个 简单 的 范例 来 让 大 家 对 上 述 第 一 种 方式 实现 的 
插件 有 一 个 直观 的 认识 ;下 一 个 小 节 中 的 android gradle plugin 则 是 
Android Studio 工 程 提供 的 以 Standalone 方 式 存在 的 Gradle 插 件 : 
android plugin。 对 于 第 二 种 方式 感 兴 趣 的 读者 可 以 自行 查阅 官网 资 
料 。 


按照 Gradle 的 规定 ， 用 户 自 定 义 的 Gradle 插 件 需 要 实现 Plug in 接 
口 。 当 我 们 在 bui 1d 脚 本 中 使 用 插件 时 ， 则 可 以 通过 apply plugin: 
[PLUG_IN] 来 指明 。 然 后 Grad1e 会 调用 该 插件 中 的 apply 了 水 数 ， 实 例如 
下 : 


apply plugin: GreetingPlugin 


class GreetingPlugin implements Plugin<Project> { 
void apply(Project project) { 
project.task('hello') << { 
println "Hello from the GreetingPlugin" 
} 


} 
Í, 


上 述 插 件 范例 用 于 添加 一 个 名 为 “hello” 的 task。 值 得 一 提 的 
是 ，Gradle 会 通过 函数 参数 传 入 一 个 重要 的 对 象 ， 即 工程 对 应 的 
Project 实 例 一 一 这 个 变量 可 以 说 是 插件 参与 到 工程 中 的 “桥梁 ”， 例 
如 GreetingPlugin 就 使 用 到 了 pro ject. task. 


这 个 范例 虽然 简单 ， 但 “ 麻 浊 虽 小 ， 五 脏 俱全 ”， 其 他 复杂 的 
Gradle Plugin 就 是 在 这 些 基 础 上 构建 起 来 的 。 


23.4.2 Android Studio 中 的 Gradle 编 译 脚本 

本 小 节 我 们 以 Android Studio 中 的 编译 脚本 为 基础 ， 结 合 Gradle 内 
部 的 实现 原理 来 帮助 大 家 理解 Android Studio 中 应 用 程序 的 编译 过 程 ， 
以 及 Grad1le 所 支持 的 Standalone 方 式 的 插件 。 图 23-12 即 是 通过 Android 
Studio 新 建 一 个 工程 后 由 1DE 产 生 的 bui 1d 脚 本 。 


值得 一 提 的 是 ， 这 个 例子 很 好 地 解释 了 Gradle 的 Multi-project 结 


构 。 从 图 23-12 中 可 以 看 到 ，Android Studio 自 动 生成 了 两 个 Gradle 脚 
本 ， 一 个 是 面向 整个 Project 的 ， 另 一 个 则 属于 module 的 管辖 范畴 。 
Project 和 Module 是 Intel1iJ 平 台 管理 工程 文件 的 两 个 概念 ， 类 似 于 
Eclipse 中 的 WorkSpace 和 Project。 除 此 之 外 ，1ntel1iJ 中 还 包含 
Facet、SDK 等 重要 元 素 ， 它 们 共同 组 成 这 个 日 益 取代 Eclipse 平台 的 
Project Structure。 如 图 23-13 所 示 。 


除了 Project 和 Module 级 别 的 bui Id. gradle 外 ，Multi-project 还 需 
要 一 个 settings. gradle， 这 个 文件 的 内 容 很 简单 ， 如 下 所 示 : 


/*settings.gradle*/ 
include ':app' 





E Project | O = | He fr 
E3 MyApplication6 (C:\Users\xs0\AndroidStudioPre 
© idea 
Pa app 
© build 
© libs 
E src 
E] .gitignore 
Jl app.iml 
® build.gradle 
E] proguard-rules.pro 
© gradle 
© wrapper 





目 gradle-wrapper.jar 
(ull gradle-wrapper.properties 

E] .gitignore 

(© build.gradle 

(ul gradle.properties 

目 gradlew 

目 gradlew.bat 

[i local.properties 

Jl MyApplication6.iml 

(© settings.gradle 

hy External Libraries 


全 图 23-12 采用 Gradle 的 默认 Android 应 用 工程 





全 图 23-13 Intelli] + #9 Project Structure 
《引用 自 InteliJ 官 方 文档 ) 


include 用 于 包含 想 要 被 编译 的 所 有 子 项 目 ， 我 们 这 个 范例 中 只 
一 个 module， 即 app。 如 果 有 多 个 子 项 目的 话 ， 会 以 “, ”分 隔 。 


接 下 来 我 们 再 看 一 下 Project 层 级 的 Gradle 脚 本 都 包含 了 哪些 内 
/*build.gradle (Project Level)*/ 
buildscript { 


repositories { 
jcenter() 


dependencies { 
classpath 'com.android.tools.build:gradle:1.0.0' 


// NOTE: Do not place your application dependencies here; 
// in the individual module build.gradle files 


Í 


allprojects { 
repositories { 
jcenter() 


这 和 大 家 以 前 用 的 Ant、Maven 等 工具 应 该 有 显著 区 别 。 这 种 区 别 实 
际 上 会 带 来 两 面 性 : 对 于 初学 者 来 说 ， 可 能 会 不 太 适 应 这 种 变化 ; 对 于 
熟悉 Gradle 的 人 来 说 ， 这 种 转变 又 的 确 能 给 他 们 带 来 更 多 的 便利 。 
相信 刚 接 触 Gradle 的 人 在 看 到 上 述 脚本 时 一 定 会 有 一 连 串 的 疑 
a]: “buildscript”“allprojects” 是 什么 ? 它们 内 部 包含 


的 “repositories” 是 属性 值 吗 ? 又 有 哪些 其 他 的 属性 是 可 供 使 用 的 
呢 ? 


还 记得 我 们 在 前 面 小 节 特 别提 醒 大 家 注意 的 准则 吗 ? 即 “Gradle 脚 
本 是 基于 Groovy 语 言 的 ， 因 而 它 一 定 需要 遵循 Groovy 的 语法 ”。 


Gradle 为 了 提高 脚本 的 可 读 性 ， 在 Groovy 的 基础 上 做 了 不 少 工作 。 


譬如 上 面 所 列 的 bui ld. gradle 中 的 bui Idscript kin ke—Th RAM, H 
后 所 跟着 的 以 大 括号 包含 的 内 容 是 函数 的 参数 closure。 更 具体 地 
说 ， 上 述 脚 本 中 出 现 的 “buildscript” “allprojects” 都 属于 Script 
Block。 大 家 可 以 参考 Grad1e 的 官方 文档 ， 如 图 23-14 所 示 。 





Build script structure 


A build script is made up of zero or more statements and script blocks, Statements can include method calls, property assignments, and local 
variable definitions. A script block is a method call which takes a closure as a parameter. The closure is treated as a configuration closure 
which configures some delegate object as it executes. The top level script blocks are listed below. 

Block Description 

allprojects { } Configures this project and each of its sub-projects. 

artifacts { } Configures the published artifacts for this project. 

buildscript { } Configures the build script classpath for this project. 

configurations { } Configures the dependency configurations for this project. 

dependencies { } Configures the dependencies for this project. 

repositories { } Configures the repositories for this project. 

sourceSets { } Configures the source sets of this project. 

subprojects { } Configures the sub-projects of this project. 


publishing { } Configures the PubLishingExtension added by the publishing plugin. 


A 423-14 Build script structure 
( 4] JA) Á https://docs.gradle.org/current/dsl/) 


根据 Grad1e 的 官方 描述 ，bui 1d script 是 由 statements+scr ipt 
blocks 组 成 的 。 其 中 statements 可 以 包括 函数 调用 、 属 性 赋值 ， 以 及 局 
部 变量 的 定义 等 ; 而 script block 是 将 闭 包 作为 参数 的 一 个 函数 调用 
这 种 特性 让 它们 看 起 来 更 像 是 一 些 配置 项 ， 从 而 提高 了 可 读 性 。 


按照 面向 对 象 的 编程 思想 ， 读 者 们 可 能 会 想 这 些 函 数 都 属于 哪些 对 
RE? 这 就 要 得 益 于 Goovy 语 言 的 灵活 性 了 。 以 bui ld. gradle 中 经 常 看 





到 的 bui 1dscr ipt 为 例 ， 它 实际 上 等 价 于 project. buildscript. HA 
Project 是 Gradle 定 义 的 一 个 全 局 的 Project 对 象 。 换 名 话说， 上述 这 些 
消 数 都 属于 org. gradle. api. Project 中 定义 的 函数 。 例 如 bui ldscript 
的 定义 如 下 : 


buildscript { } 


Configures the build script classpath for this project. 


The given closure is executed against this project's ScriptHandler. The ScriptHandler is passed to the closure as the closure's delegate. 


Delegates to: 
ScriptHandler from buildscript 


由 此 可 见 bui 1dscr ipt 的 闭 包 是 以 一 个 ScriptHandler 对 象 为 
delegate 的 ， 这 也 就 解释 了 为 什么 我 们 在 bui 1dscr ipt 中 可 以 使 用 
repositories, dependencies RAHBA, HAERA EE 
ScriptHandler 中 定义 的 ， 具 体 可 以 参考 : 


https://docs. gradle. org/current/ javadoc/org/gradle/api/init 
Project 中 还 有 不 少 常用 的 函数 ， 它 们 的 释义 如 表 23-2 所 示 。 


表 23-2 Project uty MAB AEX 


为 这 个 项 目 配置 编译 脚本 的 


void buildscript(groovy.lang. classpath。ScriptHandler 会 作为 
Closure closure); closure 的 delegate 传 递 给 它 







mal 目 和 它 所 有 子 项 目 做 配 









void 
allprojects(groovy.lang.Closure 





closure); 


org.gradle.api.AntBuilder 
ant(groovy.lang.Closure 
closure); 


void 
artifacts(groovy.lang.Closure 
closure); 


void 
configurations(groovy.lang. 
Closure closure); 


全 局 的 Project 变 量 会 作为 closure 
的 delegate 传 递 给 它 


用 于 在 build 文 件 中 执行 ant 任 务 。 
AntBuild 会 作为 closure 的 delegate 
传递 给 它 


为 这 个 项 目 配置 published 
artifacts。ArtifactHandler 会 作为 
closure 的 delegate 传 递 给 它 。 
官方 苑 例如 下 : 


configurations { 

//declaring new configuration 
that will be used to 
associate with artifacts 
schema 


} 


task schemaJar (type: Jar) { 
//some imaginary task that 
creates a jar artifact 

with the schema 


} 


//associating the task that 
produces the artifact with the 


//configuration name and the 
task: 
schema schemaJar 


} 





配置 该 项 目的 dependency 
configuration 。 
ConfigurationContainer 会 作为 
closure 的 delegate 传 递 给 它 


void 配置 该 项 目的 依赖 关系 。 
dependencies(groovy.lang. DependencyHandler 会 作为 closure 
Closure closure); 的 delegate 传 递 给 它 


配置 该 项 目的 repositories 。 
RepositoryHandler 会 作为 closure 的 
Closure closure); delegate RAE 会 作为 


void repositories(groovy.lang. 





现在 大 家 可 以 对 照 上 述 的 分 析 来 理解 Android Studio 生 成 的 默认 工 
程 了 。 和 譬如 bui ldscript 中 的 closure 语 句 : 


repositories { 
jcenter() 


dependencies { 
classpath 'com.android.tools.build:gradle:1.0.0' 
} 


表示 Gradle 在 bui 1d 阶 段 需 要 到 jcenter 仓 库 中 查找 名 
为 'com. android. tools. build:gradle:1. 0.0' 的 jar 包 ， 这 是 后 面 我 们 
将 要 分 析 的 android plugin 的 实现 体 。 如 果 不 加 上 这 句 依赖 的 话 ， 
Gradle 将 无 法 正常 生成 DAG， 并 报错 ， 如 图 23-15 所 示 。 


© C\Users\xs0\AndroidstudioProjects\MyApplication6\app\ build.gradle 
@ Error(1, 0) Pugin with id ‘com.android application’ not found. 


sages E Terminal Android € T000 EventLog El Gradle Console å Memory Monitor 
A 23-15 报错 


“allprojects” 则 预先 设置 了 jcenter 做 为 所 有 子 项 目的 依赖 关系 


包 存 储 仓库 。 另 一 个 常见 的 仓库 是 maven， 对 应 的 函数 是 
mavenCentral ， 开 发 者 可 以 根据 自己 的 实际 需求 进行 选择 。 


接 下 来 我 们 再 分 析 一 下 上 述 范 例 工程 中 sub-project 的 bui ld 
file， 如 下 所 示 : 


apply plugin: 'com.android.application' 


android { 
compileSdkVersion 21 
buildToolsVersion "21.1.1" 


defaultConfig { 
applicationId "com.example.xs0.myapplication" 
minSdkVersion 15 
targetSdkVersion 21 
versionCode 1 
versionName "1.0" 


} 
buildTypes { 
release { 
minifyEnabled false 
proguardFiles getDefaultProguardFile( 'proguard-androi 


} 


dependencies { 
compile fileTree(dir: ‘libs', include: ['*.jar']) 
compile 'com.android.support:appcompat-v7:21.0.2' 


上 面 这 个 bui ld. gradle 很 明显 是 针对 Android 工 程 的 ， 它 使 用 到 了 
id 值 为 “com. android. application” Hiit, HimwapplywRIEC 
引入 到 Gradle 的 脚本 中 。 这 个 plugin 对 应 的 jar 包 是 我 们 前 面 看 到 
的 'com. android. tools. build:gradle:1. 0.0'。 而 apply 则 属于 
org. gradle. api.Project 提 供 的 范 数 ， 只 有 通过 调用 这 个 函数 来 显 式 声 
明 我 们 需要 用 到 的 插件 名 ， 才 能 保证 插件 中 提供 的 各 种 函数 和 属性 能 在 
Gradle 中 正常 使 用 。 


大 家 应 该 已 经 猜 到 了 ， 上 述 脚本 中 的 “compileSdkyersion 
21” JA “buildToolsVersion "21.1.1"”?” 等 看 似 人 参数 配置 的 写法 实际 
上 也 是 函数 调用 。 这 些 函 数 都 是 在 Android 的 Gradle 插 件 中 声明 的 。 大 


家 可 以 通过 如 下 命令 获取 到 源 代 码 ， 并 自行 阅读 分 析 : 


$ repo init -u https://android.googlesource.com/platform/manifest 
$ repo sync 


，Gradle 的 源码 下 载 与 编译 流程 ， 也 可 以 参见 其 官方 网 站 的 介 
， 我 们 这 X BARB : 


https://docs.gradle.org/current/userguide/userguide. html 


上 面 所 说 的 bui ldscr ipt 函 数 的 源码 声明 如 下 所 示 : 


/*subprojects/core/src/main/groovy/org/gradle/api/Project.java*/ 

public interface Project extends java.lang.Comparable<org.gradle. 

gradle.api.plugins.ExtensionAware, org.gradle.api.plugins.PluginA 
java.lang.String DEFAULT_BUILD_FILE = "build.gradle"; 
java.lang.String PATH_SEPARATOR = ":"; 
java.lang.String DEFAULT_BUILD_DIR_NAME = "build"; 
java.lang.String GRADLE_PROPERTIES = "gradle. properties"; 
java.lang.String SYSTEM_PROP_PREFIX = "systemProp"; 
java.lang.String DEFAULT_VERSION = "unspecified"; 
java.lang.String DEFAULT_STATUS = "release"; 





void buildscript(groovy.lang.Closure closure); 


当然 ， 对 于 普通 开发 人 员 来 讲 ， 我 们 学 习 Gradle 的 最 主要 目的 是 了 
解 清楚 如 何 配置 和 使 用 它 ， 从 而 让 它 更 好 地 为 Android 应 用 程序 开发 过 
程 服务 。 只 有 先 把 “ 知 其 然 ”做 好 了 ， 才 有 可 能 进一步 地 “ 知 其 所 以 


AKS o 


软件 版 本 省 理 


对 于 Android 这 种 规模 的 大 项 目 ， 软 件 版 本 管理 非常 重要 ， 因 而 我 
们 首先 为 大 家 介绍 其 中 的 相关 知识 。 当 然 ， 如 果 读 者 对 这 部 分 内 容 已 经 
很 熟悉 ， 可 以 直接 略 过 并 进入 下 一 章节 的 学 习 。 


24.1 版 本 管理 简 述 


20 世 纪 计 算 机 发 展 的 早期 ， 软 件 项 目的 普遍 开发 特点 如 下 《有 点 类 
似 于 家 庭 式 作 坊 ) : 


。 开 发 人 员 数 量 很 少 ， 甚 至 往往 只 是 由 个 人 单独 完成 的 ; 
。 项 目 所 涉及 的 源 文件 不 多 ， 完 成 的 功能 相对 单一 ; 
。 开发 人 员 之 间 的 沟通 通常 是 面对面 的 。 


在 这 种 情况 下 ， 工 作 人 员 完 成 一 个 软件 项 目的 研发 并 不 需要 太 多 交 
互 。 因 此 他 们 可 以 独立 编写 、 修 改 、 调 试 代码 ， 并 在 个 人 的 机 器 上 进行 
项 目 源 文 件 的 存储 和 管理 。 这 个 阶段 还 没有 出 现 软件 版 本 管理 的 概念 ， 
开发 过 程 存在 一 定 的 主观 随意 性 一 一 软件 源码 的 管理 完全 取决 于 开发 人 
员 自 身 的 专业 素养 和 研发 习惯 。 


随 着 软件 行业 的 不 断 发 展 ， 软 件 开发 复杂 度 越 来 越 大 ， 而 且 项 目 源 
码 的 数量 也 呈现 出 指数 级 增长 。 比 如 19981 年 Li nux 的 0. 11 版 本 发 布 时 ， 
其 代码 总 量 不 过 2 万 多 行 ; 而 到 了 2. 6. 0 版 本 发 行 时 ， 这 个 数字 已 经 变 成 
了 近 6 百 万 只 由 一 个 人 或 者 几 个 人 来 完成 一 个 大 型 的 现代 软件 项 目 
已 经 成 为 天 方 夜 谭 。 调 查 资 料 显示 ，Windows 7 操作 系统 项 目的 技术 开 
发 人 员 超 过 了 2000 人 ， 并 分 布 在 世界 各 地 。 而 作为 开源 项 目的 概 楚 ， 
Linux 也 早已 不 再 是 由 Linus Torvalds 一 人 来 维护 升级 。 全 球 每 天 都 有 
新 人 不 断 加 入 这 一 伟大 项 目的 开发 工作 中 。 


面 对 如 此 庞大 的 开发 团队 ， 有 如 下 几 个 问题 不 可 避免 : 


。 如 何 做 好 这 么 多 开发 人 员 的 项 目 分 工 ; 

。 如 何 协调 他 们 之 间 的 交互 ; 

。 如 何 有 效 地 把 每 个 人 的 工作 成 果 快 速 体现 在 整个 项 目 上 

。 如 何 处 理 好 冲突 ， 如 多 个 开发 人 员 同 时 对 同一 个 文件 进行 修改 ; 
o 如 何 做 文件 的 历史 追踪 和 回 退 ; 

。 如 何 做 好 每 个 源 文件 、 每 个 版 本 的 信息 记录 工作 。 


以 上 这 些 疑 问 都 是 一 个 版 本 管理 系统 所 必须 要 解决 的 。Android 系 
统 首选 Git 作 为 版 本 管理 的 工具 一 一 虽然 它 是 一 个 功能 相当 强大 的 版 本 
管理 系统 ， 但 不 少 人 抱怨 其 使 用 方法 过 于 烦琐 ， 吻 用 性 比较 差 。 为 此 








Android 系 统 又 特别 提供 了 一 个 方便 的 小 工具 ， 即 Repo。 本 书 编译 章节 
对 此 已 经 有 过 介绍 ， ee 


24.2 ” Git 的 安装 


一 款 杰出 开源 工具 的 先天 特质 ， 很 大 程度 上 取决 于 其 创始 者 的 背景 
与 个 性 一 一 就 好 比 一 个 新 生 儿 流 消 的 血液 中 ， 与 生 俱 来 便 继承 了 其 父母 
辈 们 的 优良 与 糟粕 基因 一 样 。 开 源 项 目 并 不 是 为 赢利 而 生 的 ， 很 多 情况 
下 是 业余 爱好 者 或 技术 狂热 者 的 杰作 ， 因 此 更 大 程度 上 可 以 摆脱 商业 的 
束缚 ， 影 射出 技术 者 本 身 的 专业 素养 与 思维 习惯 。 


Git 和 Linux“ 系 出 同门 ”， 都 出 自 于 Linus Benedict Torvalds 之 
手 。 英 文 但 语 中 ，“git” 这 个 单词 代表 了 “无 用 的 人 ”。 这 位 出 生 于 
谷 兰 的 技术 领袖 对 Git 的 解释 是 : 


“I'm an egotistical bastard, and I name all my projects after mys 


这 是 Linus 的 一 种 自嘲 ， 不 过 也 隐约 体现 出 了 Git 所 想 表 达 的 含义 
简单 ， 傻 瓜 式 的 管理 方式 。 


由 于 Git 起 初 是 用 于 取代 Bitkeeper (Bitkeeper 是 Linux 早 期 采用 的 
版 本 控制 系统 ， 直 到 2005 年 才 和 Linux 社 区 脱离 关系 。 这 其 中 的 恩 恩怨 
她 直接 触发 了 Linus 对 Git 的 开发 ) 来 维护 和 管理 Linux Kerne1 的 ， 因 此 
其 很 多 特性 都 具有 Linux 的 影子 ， 而 对 Windows 等 其 他 操作 系统 的 支持 不 
太 好 。 后 来 得 蔓 于 Git 的 广泛 应 用 ， 一 些 类 似 于 msysgit 的 工具 也 开始 流 
行 起 来 ， 以 保证 6it 在 Windows 环 境 下 能 正常 运行 。 





24.2.1 Linux 环 境 下 安装 Git 


和 大 部 分 其 他 工具 一 样 ，Linux 环 境 中 的 Git 安 装 分 为 两 种 方式 ， 即 
源 代码 编译 安装 和 “Package 包 ”直接 安装 。 


1. 源 代码 编译 安装 Gift 

这 种 方法 相对 于 安装 包 要 麻烦 一 些 ， 而 且 容 易 出 错 。 如 果 读 者 只 是 
想 使 用 Git 这 个 工具 ， 并 不 打算 研究 其 源码 实现 ， 那 么 建议 采用 下 一 小 
市 的 方式 进行 便捷 安装 。 


如 果 选 择 从 源 代码 安装 ， 首 先 要 从 官网 上 下 载 G6it 源 码 及 它 的 依赖 
包 。 如 下 所 示 : 


e Git 源 代码 . http://git-scm.com/download; 

e Curl.http://curl.linux-mirror.org/ ; 

e Zlib.http://www.zlib.net/ ; 

e Openssl. http://www.openssl.org/ ; 

e Expat. http://expat.sourceforge.net/ ; 

e Libiconv. http://www.gnu.org/software/libiconv/ o 


假如 操作 系统 中 有 yum (比如 Fedora) 或 者 apt-get (Debian, 
Ubuntu 环境 中 ) 工具 ， 那 么 还 可 以 选择 以 下 方式 来 安装 依赖 包 : 


$ yum install curl-devel expat-devel gettext-devel openssl-devel 
$ apt-get install libcurl4-gnutls-dev libexpati-devgettext libz-d 


Git 源 码 下 载 完 成 后 ， 我 们 就 可 以 进行 编译 和 安装 了 。 根 据 官方 的 
建议 ， 这 个 过 程 如 下 : 


$ tar -zxf git-1.7.2.2.tar.gz 

$ cd git-1.7.2.2 

$ make prefix=/usr/local all 

$ sudo make prefix=/usr/local install 


这 样 我 们 融 完 成 Git 的 源 代 码 安 装 了 。 如 果 需 要 的 话 ， 还 可 以 通过 
Git 来 管理 Git 源 码 。 如 下 : 


$ git clone git://git.kernel.org/pub/scm/git/git.git 
2. 直接 安装 Git 

这 种 方式 比较 方便 ， 适 用 于 一 般 的 Git 使 用 者 。 

对 于 Linux 用 户 安装 有 yum 工 具 的 系统 ) : 


$ yum install git-core 


对 于 Linux 用 户 〈 安 装 有 apt-get 工 具 的 系统 ) : 


$ apt-get install git-core 


对 于 Mac 用 户 ， 又 可 细 分 为 以 下 两 种 方法 。 


。 AVN KR AH. TRAA E: 
http://code.google.com/p/git-osx-installer 
o 通过 MacPorts 安 装 。 指 今 如 下 : 
$ sudo port install git-core +svn +doc +bash_completion +gitweb 
24.2.2 Windows 环 境 下 安装 Git 
Windows 环 境 下 安装 Git 也 有 两 种 方式 。 
其 一 是 基于 Cygwin (http://www. cygwin. com/) o 
其 二 是 直接 下 载 安装 msysGit。 


其 中 msysGit 和 普通 的 Windows 应 用 程序 的 安装 并 没有 区 别 。 其 提供 
的 以 “exe” 为 后 缀 名 的 安装 包 下 载 地 址 是 : 


http://code.google.com/p/msysgit/downloads/list 


安装 珊 面 如 图 24-1 所 示 。 


Git Setup = 口 | x| 
Welcome to the Git Setup Wizard 


This will install Git version 1.7.11-preview20120620 on your 
computer, 


It is recommended that you close all other applications before 
continuing, 


Click Next to continue, or Cancel to exit Setup. 








Cancel | 





全 图 24-1 安装 界面 


它 有 两 个 工作 珊 面 可 供 不 同 使 用 习惯 的 用 户 挑选 ， 对 比 图 如 图 24-2 
所 示 。 


welcome to Git (version 1.7.11-preview20120620) 


Run ‘git help git' to display the help index. 


Run ‘git help <command>' to display help for specific commands. 





Bash j m 


i -iol xi 
版 本 库 repository) 帮助 





GUI 界面 全 图 24-2 对比 图 


24.3 6Git 的 使 用 
24. 3.1 基础 配置 
Git 要 求 的 配置 并 不 多 ， 使 用 也 相对 简单 。 下 面 我 们 进行 简单 介 


zA 
1. git config 


“git config” 为 用 户 配 置 Git 提 供 了 统一 的 接口 。 针 对 不 同 级 别 
的 对 象 〈 系 统 级 、 用 户 级 和 项 目 级 ) ，Git 都 可 以 分 别 进行 配置 。 这 几 
个 级 别 的 配置 将 根据 优先 级 依次 履 盖 ， 有 点 类 似 于 C++ 中 的 继承 关系 ， 
即 一 方面 “ 子 类 ”继承 了 “ 父 类 ”的 大 多 数 属性 ， 另 一 方面 “ 子 类 ”又 
可 以 重 写 “ 父 类 ”的 某 些 特性 。 


各 级 别 的 配置 文件 分 别 存储 在 。 


e /ctc/gitconfig. 系统 级 配置 ， 对 所 有 用 户 和 项 目 有 效 。 我 们 在 使 用 git 
config 时 如 果 传 入 --system 选 项 ， 就 可 以 配置 系统 级 别 文件 。 

。 一 /.gitconfig. 用 户 级 配置 ， 对 当前 用 户 有 效 。 我 们 在 使 用 git config 
时 如 果 传 入 --global 选 项 ， 就 可 以 对 用 户 级 配置 进行 修改 。 

e .git/config. 项 目 级 配置 ， 只 对 这 个 项 目 有 效 ， 因 此 配置 文件 放置 于 
项 目的 git 目 录 中 。 


根据 上 面 的 分 析 ， 我 们 知道 . git/config 中 的 信息 将 履 羡 
~/.gitconfig, MBA 14% m/etc/gitconfigfAYALS. 


2. 个 人 信息 


Git 要 求 每 个 用 户 都 提供 个 人 信息 ， 这 样 就 可 以 鉴别 出 代码 提交 者 
的 身份 。 具 体内 容 包 括 用 户 名 和 邮箱 地 址 。 比 如 : 


$ git config --global user.name "Xuesen Lin" 
$ git config --global user.email xslin@ThinkingInAndroid.com 


用 户 可 以 根据 需求 来 加 上 --global 等 选项 。 


编辑 器 选择 


Git 允 许 用 户 自 由 选择 合适 的 编辑 器 。 当 它 需 要 用 户 输 入 信息 时 ， 
会 自动 调用 事先 设置 好 的 编辑 器 类 型 。 比 如 你 习惯 使 用 emacs 进 行文 字 
编辑 ， 那 么 可 以 用 以 下 命令 进行 设置 ， 


$ git config --global core.editor emacs 
4. 差异 比较 工具 选择 


“差异 比较 ”在 Git 中 是 个 常用 的 操作 ， 而 且 用 户 同样 可 以 定制 自 
己 喜 欢 的 工具 。 比 如 以 下 命令 会 将 其 设置 为 vimdiff: 


$ git config --global merge.tool vimdiff 


根据 官方 的 说 明 ，Git 除 了 可 以 支持 kdiff3，tkdiff，meld， 
xxdiff，emerge，vimdiff，gvimdiff，ecmerge 和 opendiff 等 差异 分 析 
工具 外 ， 还 能 匹配 用 户 自己 开发 的 类 似 工 具 。 读 者 可 以 参阅 官方 文档 来 
了 解 详 情 。 


5. 配置 信息 列表 


当 完成 配置 后 ， 用 户 可 用 以 下 命令 来 查看 目前 已 经 设置 好 的 各 项 
值 : 


$ git config --list 

user .name=Xuesen Lin 

user .email=xslin@ThinkingInAndroid.com 
color.status=auto 

color .branch=auto 
color.interactive=auto 

color .diff=auto 


24.3.2 HECE 


对 于 SVN，CVS 等 集中 式 的 版 本 控制 系统 ， 整 个 项 目 只 有 一 个 仓库 
(repository) 。 这 样 的 集中 式 管 理 有 利于 项 目 文件 的 统一 维护 ， 不 过 
缺点 也 显而易见 ， 即 用 户 必须 连 上 服务 器 才能 开始 提交 。 


Git 属 于 分 布 式 的 版 本 管理 系统 ， 每 个 开发 者 都 可 以 单独 拥有 完整 


的 本 地 仓库 。 这 就 意味 着 提交 代码 的 动作 在 很 大 程度 上 可 以 不 依赖 于 服 
务 器 一 一 开发 者 先 离线 提交 到 本 地 仓库 中 ， 最 后 再 统一 push 到 服务 器 
上 。 因 为 这 一 特点 ，Git 的 提交 动作 很 快 ， 几 乎 瞬间 就 能 完成 。 当 然 ， 
不 论 什么 系统 都 有 其 最 佳 的 适用 场合 ， 并 不 存在 绝对 的 优 劣 之 分 ， 读 者 
要 根据 自己 的 实际 项 目 需求 来 决定 采用 何 种 系统 。 


E E 
车 。 


1. 本 地 新 建仓 库 
我 们 来 举 个 例子 进行 说 明 。 
假设 有 一 个 简单 的 工程 项 目 ， 包 括 的 文件 及 目录 结构 如 下 所 示 。 


af 

|-- src 
|----- main.c 
|----- utility.c 
|----- utility.h 
|----- Makefile 

|-- bin 

|-- Makefile 


|-- Readme.txt 


如 果 我 们 要 在 本 地 为 这 个 项 目 建立 一 个 仓库 ， 可 以 在 其 根 目录 下 执 
行 以 下 命令 。 


$ git init 
得 到 的 Git 返 回信 息 为 : 


Initialized empty Git repository in /home/android/Work/ThinkingInAndroid/GitTest 
/.git/ 


Initialized empty Git repository in /home/android/Work/ThinkingInAndroid/GitTest 
/.git/ 





说 明 我 们 已 经 成 功 创建 了 一 个 本 地 仓库 。 这 时 会 发 现在 根 目录 下 多 
了 一 个 . git 目 录 ， 其 文件 结构 及 作用 如 下 : 


-- branches # 新 版 本 不 再 适用 ， 一 般 是 空 的 

-- hooks #hooks 脚 本 文件 

info # 指 定 需 要 忽略 的 文件 

objects # 存 储 Git 的 4 个 重要 的 数据 对 象 ， 后 面 小 节 有 详细 解释 
refs # 分 支 指 癌 的 提交 

config # 设 置 文件 ， TALS Mes eh REL 
description # 一 些 项 目的 描述 信息 

HEAD # 指 出 当前 在 哪个 分 支 





























这 些 文 件 都 是 6Git 进 行 版 本 已 理 控制 所 需 的 信息 ， 后 面 的 原理 小 生 
中 我 们 还 会 进一步 分 析 。 


2. 克隆 已 有 仓库 
因为 是 克隆 ， 相 当 于 把 一 个 已 经 存在 的 项 目镜 像 了 一 遍 。 


比如 我 们 在 本 书 的 基础 篇 中 曾 讲解 过 如 何 下 载 Android 系 统 的 源 
马 。 其 中 克隆 kernel1/ycommon 的 命令 如 下 : 


git clone git://android.git.kernel.org/kernel/common. git 


克隆 一 个 git 项 目的 通用 格式 为 : 


git clone [--template=<template_directory>] 

[-1] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] 

[-o <name>] [-b <name>] [-u <upload-pack>] [--reference <reposito 
[--separate-git-dir <git dir>] 

[--depth <depth>] [--[no-]single-branch] 
[--recursive|--recurse-submodules] [--] <repository> 
[<directory>] 


Git 支 持 多 种 数据 传输 协议 ， 上 面 的 范例 中 就 用 到 了 其 中 的 git:// 
协议 。 更 多 协议 “如 SSH，HTTP/S 等 ) 的 详细 解释 ， 读 者 可 以 参阅 官方 
文档 进行 了 解 。 对 于 一 般 的 用 户 来 说 ， 只 要 知道 如 何 使 用 这 些 协议 即 
可 。 


执行 了 克隆 命令 后 ， 通 常情 况 下 可 以 得 到 类 似 下 面 的 提示 信息 ( 它 
给 出 了 所 有 对 象 的 个 数 、 下 载 进度 以 及 项 目 文件 的 解析 进度 等 )。 


Cloning into ’input’... 
remote: Counting objects: 2437563. done. 
remote: Compressing objects: 166% (3'73783/373783>. done. 


remote: Total 2437563 《delta 2040660). reused 2435598 (delta 2839738) 
Receiving objects: 106% (243'7563/2437563>. 491.78 MiB | 315 KiB/s. done. 
Resolving deltas: 100z (26046666/2040666>. done. 
Checking out files: 100z (38572738572). done. 





24.3.3 文件 状态 


Git 管 理 下 的 文件 状态 如 图 24-3 所 示 。 


File Status Lifecycle 


untracked unmodified 


he file 


add the file 
má stage the file 
remove the file Er 





AA 24-3) ”Git 管理 下 的 文件 状态 
( 注 : 引用 自 http://git-scm.com/book。) 


在 Git 版 本 管理 系统 中 ， 每 个 文件 都 有 其 特定 的 状态 。 我 们 分 别 来 
解释 这 些 状态 的 含义 。 


e 未 跟踪 状态 (untracked) 
说 明 这 个 文件 还 没有 纳入 Git 的 管理 范畴 。 除 此 之 外 的 其 他 3 种 状态 
都 可 以 划 归 为 “已 跟 踊 状态 ”。 显 然 ， 对 于 一 个 刚刚 克隆 完成 的 项 目 ， 
它 的 所 有 文件 都 处 于 已 跟 踊 状态 。 
。 未 修改 状态 (unmodified) 


ri 这 个 文件 已 经 在 Git 的 管理 下 ， 而 且 相 对 于 上 一 次 提交 没有 任 
ay Tr, 


e 已 修改 状态 (modified) 


A 说 明 这 个 文件 相对 于 上 一 次 提交 有 了 新 的 变化 ， 而 且 它 还 没有 被 暂 
子 。 


。 已 暂 存 状态 (staged) 


只 有 当 一 个 文件 被 stage 后 ， 它 才能 在 下 一 次 的 commit 动 作 中 被 提 
区。 提交 过 后 ， 它 又 将 变 成 unmodified 状 态 。 


明白 了 这 几 个 状态 的 含义 后 ， 我 们 再 来 看 看 如 何 查询 某 个 文件 的 当 
前 状态 。 只 要 执行 以 下 命令 即 可 。 


git status [<options>...] [--] [<pathspec>...] 


ees 我 们 前 一 小 节 新 建 的 Git 范 例 项 目 中 ， 执 行 查询 命令 后 得 到 的 
AR. 


On branch master 


Initial commit 


# 
= 
# 
# 
# Untracked files: 

# (use "git add <file>..." to include in what will be committed) 
# 

# 

# 

# 

# 





nothing added to commit but untracked files present (use "git add" to track) 


可 以 看 到 ， 所 有 的 文件 /目录 都 处 于 未 跟踪 状态 。 
我 们 可 以 通过 如 下 命令 把 一 个 文件 /目录 加 入 Git 的 管理 中 : 


git add [-n] [-v] [--force | -fj [--interactive | -i] [--patch | 
[--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N] 
[--refresh] [--ignore-errors] [--ignore-missing] [--] 
[<filepattern>...] 


例如 执行 如 下 命令 : 


git add Makefile 


此 时 工程 文件 的 状态 发 生 了 一 定 变化 ， 如 下 所 示 。 


On branch master 
Initial commit 


Changes to be committed: 
(use "git rm --cached <file>..." to unstage) 


Untracked files: 
(use "git add <file>..." to include in what will be committed) 


# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 





FAIL Ay 40, Makefi le 这 个 文件 已 经 从 Untracked 状 态 转型 成 功 。 


对 于 目录 而 言 ，git add 则 会 将 其 所 包含 的 所 有 文件 / 子 目录 都 加 入 
Git。 


比如 执行 : 
git add src 
新 的 状态 如 下 所 示 。 
On branch master 


Initial commit 


Changes to be committed: 
(use "git rm --cached <file>..." to unstage) 


Untracked files: 
(use "git add <file>..." to include in what will be committed) 


# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 





如 果 要 删除 已 经 add 的 文件 ， 可 以 使 用 : 


git rm [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [-- 


在 进行 这 一 步 操作 时 ， 要 格外 小 心 一 一 如 果 你 只 是 想 解 除 文件 与 
Git 的 管理 关系 ， 那 么 要 加 上 --cached 选 项 ， 否 则 会 把 源 文 件 删除 掉 。 
关于 更 多 注意 事项 和 使 用 方法 ， 可 以 使 用 git 帮 助 进行 了 解 : 
git help [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND] 


24.3.4 忽略 某 些 文件 


在 实际 的 项 目 开发 过 程 中 ， 往 往 有 很 多 中 间 文 件 ， 如 编译 出 来 
的 .o、log 跟 踩 文 件 等 。 一 方面 ， 这 些 文件 并 不 需要 进入 版 本 树 中 ; A 


一 方面 ， 如 果 不 把 它们 add 进 Git， 那 么 每 次 执行 git status 时 又 都 会 出 
现 untracked 文 件 提 示 ， 这 显然 也 不 太 方 便 。 


为 了 避免 这 种 情况 ， 我 们 可 以 在 项 目 根 目录 下 创建 一 个 名 
为 “.gitignore” 的 文件 来 记录 那些 不 想 被 跟踪 的 文 
件 。“. gitignore” 文 件 的 书写 格式 如 下 : 


。 以 注释 符号 # 开 头 的 行 都 会 被 Git 忽 略 。 
。 遵 循 标准 的 glob 模 式 匹配 。 
比如 上 面 例子 中 的 bin 文 件 夹 处 于 untracked 状 态 ， 如 果 想 忽略 此 目 


人 可 以 通过 编辑 “. gitignore” 文 件 来 达到 目的 。 范 例 
Oh: 


#This line will be ignored 
bin/ 

再 次 执行 状态 查询 命令 ， 会 发 现 bin 目 录 已 经 不 再 被 追踪 显示 。 如 
下 所 示 。 











On branch master 
Initial commit 


Changes to be committed: 
(use "git rm --cached <file>..." to unstage) 


Untracked files: 
(use "git add <file>..." to include in what will be committed) 


# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 





24.3.5 提交 更 新 


“提交 更 新 ”是 把 项 目 中 被 修改 的 文件 保存 进 本 地 仓库 的 一 个 重要 
动作 。 不 过 要 特别 注意 ， 只 有 那些 被 staged 的 文件 才 会 被 提交 


提交 命令 很 简单 ， 格 式 如 下 : 


git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [- 
[-F <file> | -m <msg>] [--reset-author] [--allow-empty ] 
[--allow-empty-message] [--no-verify] [-e] [--author=<author>] 
[--date=<date>] [--cleanup=<mode>] [--status | --no-status] 

[-i | -o] [--] [<file>...] 


执行 命令 后 ，Git 会 自动 调用 文本 编辑 器 配置 小 性 里 讲解 过 如 何 
有 置 默认 的 编辑 器 类 型 ) 来 让 用 户 描述 本 次 的 提交 操作 〈 比 如 为 什么 提 
有 哪些 更 改 等 ) 。 例 子 如 下 所 示 。 


The first commit 
# Please enter the commit message for your changes. Lines starting 
# with '#' will be ignored, and an empty message aborts the commit. 


# 
# Committer: Xuesen Lin <android@android-VirtualBox. (none)> 
# 





完成 操作 后 ，Git 会 提示 最 终 的 提交 结果 。 如 下 所 示 。 


root-commit) 6d commit 
Committer: Xuesen Lin <android@android-VirtualBox. (none)> 
Your name and email address were configured automatically based 
on your username and hostname. Please check that they are accurate. 
You can suppress this message by setting them explicitly: 


git config --global user.name "Your Name" 
git config --global user.email youGexample.com 


After doing this, you may fix the identity used for this commit with: 
git commit --amend --reset-author 


7 files changed, 30 insertions(+), © deletions(-) 
create mode 100755 Makefile 

create mode 100755 src/Makefile 

create mode 100755 src/main.c 

create mode 100644 src/main.o 

create mode 100755 src/utility.c 

create mode 100755 src/utility.h 

create mode 100644 src/utility.o 





24.3.6 ”其 他 命令 


Git 支 持 的 命令 相当 丰富 ， 几 乎 覆盖 了 版 本 管理 和 查询 的 方 方 面 
面 。 下 一 小 节 的 原理 分 析 中 我 们 还 全 根据 场景 需要 再 对 其 他 常用 命令 进 
行 讲解 。 另 外 ， 建 议 读 者 通过 “man git” RA “git - help” 来 获取 
更 多 信息 〈 特 别 是 一 些 高 级 命令 的 使 用 方法 ) 。 


24.4 6Git 原 理 简 析 

无 论 多 么 复杂 的 系统 ， 总 是 基于 某 一 个 (或 几 个 ) 核心 原理 扩展 开 
的 。 这 个 基石 就 像 我 们 散文 写作 的 中 心思 想 一 样 ， 可 以 有 效 地 保证 即使 
文章 的 “ 形 ” 再 散 ， 都 不 会 影响 到 “ 神 聚 ”。 本 书 基 础 篇 里 读者 曾 系统 
地 学 习 了 Android 的 编译 系统 它 乍 看 起 来 相当 庞大 可 怕 ， 但 只 要 抽 
丝 剥 草 ， 就 会 发 现 其 实 它 所 基于 的 make 依 赖 原则 相当 简明 易 懂 。 


版 本 管理 系统 也 类 似 。 因 此 ， 首 先 我 们 要 理解 它 所 要 做 的 核心 任务 


是 什么 。 
很 显然 ， 就 是 “版 本 的 管理 ”。 或 者 更 具体 地 讲 ， 就 是 : 
针对 每 个 项 目 文件 各 个 修改 版 本 的 统一 有 序 的 管理 。 
下 面 我 们 画 一 个 抽象 图 来 帮助 读者 理解 这 一 “中 心思 想 ”。 
假设 有 一 个 项 目 工程 ， 其 文件 关系 如 下 。 





A 
| 

ee D 
EE: 

jesis E 

jesis F 


那么 经 过 多 次 提交 操作 后 ， 版 本 管理 系统 中 的 抽象 图 可 能 如 图 24-4 








全 图 24-4 版 本 管理 系统 的 抽象 图 


下 面 来 解释 下 这 张 图 的 含义 。 

。 首先 它 是 一 张 三 维 立体 图 ， 其 x、y 坐 标 系 组 成 的 平面 代表 了 项 目 文 
件 的 构成 以 及 它们 之 间 的 关系 。 比 如 A 包含 了 B 和 C， 而 C 又 进一步 
包含 了 E 和 F。z 坐 标 给 出 了 每 个 文件 的 版 本 修改 历史 ， 其 中 括号 中 








的 v 表 示 vetsion， 后 面 的 数字 随 每 次 修改 记录 而 递增 。 
要 特别 强调 一 下 ， 这 是 一 张 茶 一 特定 时 刻下 的 版 本 管理 图 。 换 句 话 
说 ， 随 着 时 间 的 推移 ， 管 理 图 是 在 不 断 变化 的 。 比 如 源 文件 的 修 
改 、 新 增 或 者 删除 ， 都 会 导致 整个 系统 图 的 更 新 。 

在 实际 版 本 管理 系统 的 实现 中 ， 每 一 个 节点 往往 代表 了 一 个 具体 的 
文件 或 者 目录 。 比 如 在 这 个 例子 中 ，A、B、C 3 个 节点 显然 是 目 
录 ， 而 其 他 节点 可 能 是 目录 或 者 文件 。 

对 于 同一 个 市 点 的 不 同 版 本 ， 有 的 版 本 管理 系统 只 会 记录 它们 之 间 
的 差异 部 分 ， 而 有 的 系统 则 会 完整 记录 文件 的 每 一 个 版 本 。 举 个 例 
子 ，F 节 点 目前 已 经 有 4 个 版 本 。 如 果 只 记录 每 个 版 本 间 的 差异 ， 那 
么 我 们 如 果 想 取得 F 的 v0.2 版 本 文件 ， 则 需要 和 v0.1 文 件 进行 差异 比 
较 ， 再 还 原 出 整个 源 文件 。 而 如 果 文 件 的 每 个 版 本 都 有 单独 的 记 
录 ， 那 么 可 想 而 知 提取 指定 版 本 的 文件 内 容 就 会 快 很 多 一 一 缺 点 就 
是 会 占据 一 定 的 存储 空间 ， 即 典型 的 “以 空间 换 时 间 ” 的 做 法 。 


明日 了 版 本 省 理 系 统 的 基础 知识 后 ， 我 们 接 下 来 对 照 6it 来 看 看 它 


是 怎么 做 的 。 
24.4.1 ”分布 式 版 本 系统 的 特点 


我 们 一 直 在 强调 Git 是 一 种 分 布 式 的 版 本 管理 系统 (DVCS) 。 与 之 
相对 的 ， 就 是 集中 式 的 管理 系统 (CVCS) ， 如 图 24-5 所 示 。 那 么 ， 这 两 
种 机 制 间 有 什么 本 质 的 区 别 呢 ? 通过 对 前 几 小 节 内 容 的 了 解 ， 相 信 读 者 
已 经 有 了 初步 的 概念 。 


如 图 24-5 所 示 ， 集 中 式 的 版 本 控制 系统 需要 一 人 台 服 务 器 的 支持 才能 
完成 提交 、 合 并 等 重要 操作 。 这 就 意味 着 开发 者 必须 与 服务 器 取得 连接 
才能 正常 工作 。 如 果 服 务 器 发 生 故 障 ， 很 可 能 会 导致 整个 项 目 开发 进展 


ray Ht 
停滞 o 


要 特别 指出 的 是 ，Git 虽 然 是 分 布 式 的 管理 系统 ， 但 并 不 意味 着 它 
不 能 以 集中 式 的 控制 方式 工作 ; 相反 ， 图 24-5 所 示 的 工作 流 也 是 Git 的 
一 种 常用 形式 。 正 如 我 们 一 直 在 强调 的 ， 问 题 不 在 于 选择 哪个 工具 一 一 
这 不 是 目的 ， 真 正 的 目的 是 根据 实际 项 目 需求 来 选择 最 合适 自己 的 工 
A, 


-~ 








除了 集中 式 的 管理 外 ，Git 的 工作 流 形式 还 可 以 有 很 多 种 。 因 为 每 
个 开发 者 都 并 非 纯 粹 的 “消费 者 ”， 他 们 除了 取得 远程 仓库 上 已 有 的 代 
码 外 ， 自 己 也 可 以 成 为 “生产 者 ” 一 一 通过 将 自己 设 为 共享 仓库 来 让 
其 他 人 获取 到 他 们 编写 的 代码 。 


接 下 来 我 们 引用 Git 官 方 文档 上 的 一 个 例子 来 分 析 其 他 两 种 比较 常 
用 的 Git 工 作 流 方式 。 


第 一 种 方式 通常 被 运用 于 像 GitHub (https://github. com/) 这 样 
的 网 站 ， 称 为 “管理 员工 作 流 ” (lntegration-Manager Workflow) 。 





全 图 24-5 集中 式 的 版 本 管理 系统 
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全 图 24-6 ”集成 管理 员工 作 流 
注 : 引用 自 http://git-scm.com/book。 


其 示意 图 如 图 24-6 所 示 。 

集成 管理 员 模 式 的 流程 一 般 是 : 

管理 员 维 护 公 共 主 仓库 ; 

开发 者 将 公共 仓库 的 项 目 文件 克隆 到 本 地 ，; 


开发 者 根据 需求 进行 项 目 研发 ; 
开发 者 将 项 目 修改 推送 到 他 们 自己 的 公共 仓库 中 ; 




















开发 者 与 管理 员 取 得 联系 ， 要 求 管 理 员 拉 取 修 改 文件 ; 
管理 员 从 开发 者 的 公共 仓库 获取 到 最 新 修改 ; 

管理 员 做 本 地 合并 并 验证 ; 

管理 员 将 验证 后 的 修改 推送 到 主 仓库 中 。 


另 一 种 方式 称 为 “司令 与 副官 工作 流 ” (Dictator and 


Lieutenants Workflow) 。 顾 名 思 义 ， 这 是 一 种 多 层级 的 工作 方式 。 就 
好 比 一 个 军队 中 有 司令 、 副 官 、 军 长 、 师 长 等 管理 员 ， 权 力 逐 层 下 放 ， 
分 而 治之 ， 如 图 24-7 所 示 。 


具体 流程 是 : 


只 有 司令 员 才 可 以 向 公共 主 仓 库 推送 修改 ; 
普通 开发 者 通过 公共 主 仓库 获取 到 项 目 文件 ; 
普通 开发 者 根据 需求 进行 项 目 研发 ; 

副官 们 将 开发 者 的 修改 合并 入 他 们 的 分 支 中 ; 
司令 员 将 副官 们 的 分 支 合 并 入 他 的 主 分 支 中 ; 
司令 员 将 最 终结 果 推 送 至 公共 主 仓库 中 。 
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全 图 24-7 司令 与 副官 工作 流 
注 : 引用 自 http://git-scm.com/book。 


这 种 形式 的 开发 模型 比 前 两 种 都 要 烦琐 些 ， 一 般 只 会 被 应 用 于 超大 
型 项 目的 管理 中 。 比 如 Linux 内 核 的 开发 就 采用 了 类 似 “司令 与 副官 工 
作 流 ” 的 方法 。 对 于 普通 项 目的 研发 ， 并 不 见得 适用 。 


24.4.2 ”安全 散 列 算法 一 一 SHA-1 
在 进入 Git 的 分 析 前 ， 读 者 还 有 一 个 基础 知识 需要 补充 ， 即 SHA-1 。 


SHA (Secure Hash Algorithm) 是 由 美国 国家 标准 与 技术 研究 院 
(National Institute of Standards and Technology) 发 布 的 一 系列 
安全 散 列 算法 。 其 初始 版 本 SHA-0 于 1993 年 诞生 于 美国 国家 安全 局 
(National Security Agency) 。 但 是 第 一 个 版 本 很 快 就 因 某 些 未 曾 公 
开 的 缺陷 而 被 撤销 ， 随 后 便 被 SHA-1 取 代 。 


SHA-1 到 目前 为 止 都 还 被 认为 是 安全 可 靠 的 。 它 可 以 从 小 于 2 位 的 
言 息 中 产生 一 串 160 位 的 摘要 ， 因 此 通常 被 用 于 做 数据 的 完整 性 校 验 。 
有 兴趣 的 读者 可 以 自行 研究 其 算法 原理 ， 而 学 习 Git 只 需要 知道 它 的 几 
个 理论 特性 即 可 。 


e TT hk 


即 我 们 没有 办 法 从 160 位 的 摘要 中 还 原 出 原始 的 数据 。 可 以 想象 一 
下 ， 如 果 我 们 可 以 从 结果 推导 出 初始 值 ， 甚 至 于 近似 值 ， 那 么 基于 这 种 
散 列 的 加 密 过 程 显 然 是 没有 任何 意义 的 。 


。 无 碰撞 性 


碰撞 的 意思 是 两 个 不 同 的 原始 数据 ， 产 生 同 样 的 摘要 结果 。 实 际 
上 ， 散 列 的 碰撞 是 无 法 避免 的 。 因 为 散 列 是 从 A->B 的 变换 过 程 ， 而 且 B 
的 大 小 只 有 160 位 一 一 那么 从 数学 概率 的 角度 来 说 ， 一 定 存 在 碰撞 的 可 
能 。 所 以 ， 我 们 只 能 保证 理论 上 是 不 会 发 生 碰 撞 的 。 








。 摘要 长 度 不 变 


”不 论 原始 数据 多 长 当然 必须 小 于 2%“ 位 ) ， 其 输出 结果 一 定 是 160 


位 


在 Git 的 设计 中 ，SHA-1 被 广泛 用 于 为 某 个 对 象 〈 下 一 小 节 中 有 详细 
讲解 ) 产生 唯一 的 摘要 值 。 因 为 这 个 值 是 唯一 的 ， 这 样 在 理论 上 融 可 以 
把 N 个 不 同 的 对 象 彻底 区 分 开 来 。 这 和 我 们 一 般 情况 下 使 用 文件 名 来 区 
别 不 同文 件 对 象 的 想法 有 很 大 不 同 。Git 里 的 对 象 文件 名 并 不 是 真正 项 
目 中 的 文件 名 ， 而 是 这 个 对 象 内 容 的 SHA-1 散 列 值 一 一 而 其 真正 的 文件 
名 存储 在 指向 它 的 tree 对 象 中 。 


我 们 在 接 下 来 的 小 节 中 具体 分 析 这 些 对 象 。 
24.4.3 4 个 重要 对 象 

Git 里 有 4 个 重要 的 对 象 (ob ject) 支撑 起 整个 版 本 管理 系统 ， 即 
blob、tree、commit 以 及 tag。 刚 开始 接触 Git 的 读者 ， 可 能 对 这 些 对 象 


没有 太 多 的 概念 。 为 了 直观 起 见 ， 我 们 仍然 引用 http://git-scm. com 中 
提 到 的 一 个 例子 来 进行 具体 说 明 。 


这 个 例子 针对 的 是 这 样 一 个 项 目 : 
|-- README 
|-- LICENCE 


|-- test.rb 


经 过 commit 动 作 后 ， 几 个 对 象 间 的 关系 如 图 24-8 所 示 。 
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AA248 ”Git 中 的 对 象 关系 实例 
QÈ: 引用 自 http://git-scm.com。) 


接 下 来 将 针对 这 个 范例 来 分 析 各 个 对 象 。 
1. Blob 对 象 


在 Git 中 ，Blob 对 象 用 于 存储 文件 内 容 。 比 如 这 个 范例 中 有 3 个 blob 
对 象 ， 分 别 用 于 储存 README，LI1CENCE 以 及 test. rb3 个 文件 信息 。 


特别 提示 : Blob 的 文件 名 是 如 何 获得 的 呢 ? 


首先 对 项 目 文件 的 内 容 进 行 SHA-1 运 算 以 得 到 160 位 数据 〈 以 4 位 来 
表示 一 个 字符 。 共 有 40 个 字符 ， 范 围 是 O- 9 、 ‘a - P) 
后 ， 再 将 这 160 位 数据 值 进行 相关 校 验 和 运算 ， 最 后 仍然 得 到 160 位 数 
值 。 取 前 两 个 字符 建立 子 目 录 ， 剩 下 的 字符 才 作 为 blob 文 件 名 。 因 此 如 
果 细 心 观察 ， 就 会 发 现实 际 上 blob 文 件 名 只 有 38 个 字符 。 


与 很 多 其 他 的 版 本 控制 系统 相 比 ，Git 对 同一 项 目 文件 不 同 版 本 的 
内 容 存 储 有 独到 之 处 。 


通常 情况 下 ， 一 个 版 本 控制 系统 会 对 被 修改 的 项 目 文件 做 版 本 差异 
运算 ， 然 后 只 保存 这 一 差异 值 。 比 如 项 目 文件 A， 上 一 个 版 本 是 v0. 1。 
那么 对 A 经 过 修改 后 再 提交 ， 它 的 新 版 本 是 v0. 2。 
我 们 通过 运算 得 到 两 版 本 间 的 差异 为 A， 即 : 
人 = diff(Ay01， AYO) 
最 终 被 保存 到 系统 中 的 就 是 这 个 版 本 差异 人 。 也 就 是 说 ， 如 果 想 还 


原 出 文件 A 的 v0. 2 版 本 内 容 ， 那 么 需要 再 次 对 两 个 版 本 文件 进行 差 值 运 
算 ， 如 图 24-9 所 示 。 
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全 图 24-9 ”普通 VCS 对 不 同 版 本 文件 的 存储 管理 


Git 的 做 法 则 有 很 大 不 同 。 它 保存 的 并 不 是 版 本 间 的 差异 ， 而 是 整 
个 修改 后 的 文件 内 容 〈 注 意 : 其 实 不 是 单纯 地 保存 内 容 ， 还 需要 进行 
SHA-1 运 算 等 操作 ) ， 如 图 24-10 所 示 。 
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全 图 24-10 Git 对 不 同 版 本 文件 的 存储 管理 


显然 ，Git 所 采用 的 方式 将 增加 系统 对 存储 空间 的 要 求 。 不 过 在 当 
今 的 1T 世 界 里 ， 磁 盘 等 存储 设备 容量 越 来 越 大 ， 价 格 也 越 来 越 低 ， 因此 
这 种 空间 换 时 间 的 方法 还 是 有 其 可 取 之 处 的 。 特 别 是 由 此 带 来 的 Git 分 
文 管理 的 快速 与 便捷 ， 都 是 其 他 版 本 管理 系统 所 无 法 比拟 的 。 在 接 下 来 
的 小 节 中 ， 我 们 还 会 谈 到 由 此 市 来 的 Git 在 分 支管 理 上 的 优势 。 


对 于 一 个 blob 对 象 ， 记 录 它 的 全 局 标签 是 SHA-1 串 值 。 因 此 我 们 可 
以 利用 Git 提 供 的 工具 来 快速 显示 一 个 文件 的 内 容 。 比 如 前 面 例子 中 
的 “utility.c” 文 件 ， 其 唯一 标志 值 为 “0acdfa4e476d05 
01f84b1cd9f48f90d088bfe247”， 我 们 可 以 通过 以 下 命令 来 得 到 文件 内 
容 。 如 下 所 示 : 


6d6561f84blcd9f48f99d988bfe247 
#include “utility.h" 


int getNumber() 
{ 


return 2; 





} 


另外 ， 我 们 也 可 以 使 用 图 形 化 的 工具 来 帮助 理解 各 个 版 本 间 的 关系 
和 变化 。 比 如 ，gitk 就 是 一 个 很 不 错 的 分 析 工 具 。 它 的 主 界面 如 图 24- 
11 所 示 ， 有 兴趣 的 读者 可 以 自行 参阅 其 官方 资料 。 


2. Trees} & 

前 面 所 展示 的 例子 中 ，tree 对 象 的 内 容 如 图 24-12 所 示 。 

可 以 看 到 ，tree 对 象 “92ec2…” 包 含 了 3 个 blob 对 象 ， 即 此 项 目的 
几 个 源 文件 。 通 过 记录 这 3 个 文件 的 唯一 标志 值 tree 可 以 非常 方便 地 


指向 它们 。Tree 对 象 有 点 类 似 于 目录 的 概念 ， 因 此 它 不 仅 可 以 指向 
blob， 还 可 以 指向 tree 对 象 ， 就 好 像 一 个 目录 下 也 可 以 有 子 自 录 一 样 。 


gitk: input 
File Edit View Help 


PATCH] ppe32: add sound support for Mac Mini 
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PATCH] ppc32: Fix a sleep issues on some laptops 

PATCH] macintoshladbhid.c: adh buttons support for aluminium PowerBook G4 
PATCH] ppc32: Fix IDE related crash on wakeup 

PATCH] ppc32: add rte hooks in PPC7D platform file 

PATCH) ppe32: fix for misreported SDRAM size on Radstone PPC7D platform 
PATCH] ppc32: refactor FPU exception handling 

PATCH) ppe32: Fix errata for some G3 CPUs 

PATCH] SELinux: add finer grained permissions to Netlink audit processing 
PATCH] SELinux: cleanup ipe_has_perm 





PATCH] mpage_vritenagest) page locking fix 
PATCH) add kmalloc_node, inline cleanup 

PATCH) sync_page() smp_mb comment 

PATCH] RLIMIT_MEMLOCK checking fix 

PATCH] count bounce buffer pages in vmstat 
PATCH] doc: Locking update 

PATCH] mm: use _ GFP_NOMEMALLOC 

PATCH] mempool: simplify alloc 

PATCH] mempool: NOMEMALLOC and NORETRY 
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PATCH] mm: rmap.c cleanup 


PATCH] RLIMIT_AS checking fix 
[PATCH] monorie fila hufforor writa fivac 














Benjamin Herenschid henh ken 20 


Benjamin Herrenschmidt shenh@kerne 20 
Dan Malek sdan@embeddededge.com 20 
Paul Mackerras «paulus@samba.org> 20 
Benjamin Hertenschmidt shenh@kerne 20 


Andreas Jaggi sandreas jaggi@waterw 20 


Benjamin Herrenschmidt shenh@kerne 20 
Chris Elston <chris.elston@radstone.ce 20 
Chris Elston schris.elston@radstone.ee 20 
Paul Mackerras spaulus@sambaorg> 20 
Benjamin Herrenschmidt shenh@kemne 20 
James Moris <jmoris@redhatcom> — 20 




















= 


Kita Dani 


= 


W 


D> 


hris Wrigh 


至 


kita Dani 
ck Piggin 
ck Piggin 
ck Piggin 
ck Piggin 
Kita Dani 












MEZAWA Hiroyu 
Ov sriki 
sniickpi 
snickpi 
nicki 
snickpi 














ta@clusterts.com> 20 


swli@holomorphy.c 20 


t schrisw@osdl org> 20 
ki skamezawahiroyy 200 


ta@eclusterts.com> 20 
ggin@yahoo.com.au 20 


gin@yahoo.com.au 20 
gin@yahoo.comau 20 





oveniki 





ta@elusterfs.com> 20 





ggin@yahoo.com.au 200 





akpm@osdl.org <akpm@asdlory> 20 


alnméined| nrn eaknmAnedLnrs 








0 


l 


l 








Fe 
5. 
5- 
5. 
5- 
5- 
5. 
5- 
5- 
5. 
5- 
5- 
f. 


$- 
5. 
a 
a 
5. 
$- 
a 
5 
a 
a 
Fe 
5. 
a 


5. 
5- 
5- 
5- 
5. 
5- 
5- 
5. 
5. 
5. 
5. 
5. 
f. 











01 23:58:43 


23:58:43 


01 23:58:42 


23:58:42 
23:58:42 


01 23:58:41 


2358:41 
2358:41 
23:58:40 
23:58:40 
23:58:40 
23:58:40 
23:58:39 


Stephen Smalley a 20 


ov «niki 
anfred Spraul «manfed@dhl.g-ag.de 20 
illiam Lee Irwin | 





23:56:39 
23:56:38 


01 23:58:38 


23:56:38 


01 23:58:37 


23:58.37 
23:58:37 


01 23:58:37 


23:58:36 
23:58:36 
23:58:36 
23:58:36 


NANANA VPRO A, 


| 


y 
站 


SHAM ID: [ierasanscnteometaseenssas le Sat 《| Sf 296951 | 299585 | 
Find next | prey | emit [mining | [ne vat fais "| 


| 


G Dife C Old version C Mew version Lines of context! 3 4 P Igore space chan 
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[PATCH] drop _butters() oops fix 


In rare situations, drop buffers|) can be called for a page which has buf 
but no ->napping (it was truncated, but the buffers were left behind bece 
ext3 was still fiddling with then), 


But if there was an I/O error in a buffer head, drop buffers{) will try t 
at the address space and will oops. 


Signed-off-by: Andrew Morton <akpuhosdl, oxg> 
Sied-off-by: Linus Torvalds <torvaldallosdl. oxg> 


/* cell.c: APS cell and server record management 
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t Copyright (C) 2002 Red Hat, Inc, All Rights Reserved, 
t Written by David Howells (dhowellsfredhat, com) i 
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全 图 24-11 gi 人 的 一 般 用 户 界面 
通过 6Git 的 如 下 命令 ， 我 们 能 获知 一 个 对 象 的 类 型 。 
git cat-file -t <OBJECT> 


例子 如 下 所 示 : 


android@android-VirtualBox:~/Work/ThinkingInAndroid/GitTest$ git cat-file -t Oac 
dfa4e476d0501f84b1cd9f48f90d088bfe247 





blob 


Tree 对 象 将 众多 的 blob 和 和 tree 组织 起 来 ， 形 成 一 棵 无 环 树 结构 ， 这 
是 后 面 我 们 将 提 到 的 commit 对 象 的 基础 。 


另外 ， 通 过 如 下 命令 可 以 打印 对 象 的 内 容 : 
git cat-file -p <OBJECT> 
范例 如 下 所 示 : 


s@ubuntu:~/gittest$ git cat-file -p feeScc 
tree e625d6b666b55cce10185fb2ccOebc919F91787b 
author lxs <Lxs@xxx.com> 1471705562 -0700 


committer lxs <Lxs@xxx.com> 1471705562 -0700 


This is the first commit 





3. Committ & 


Commit 对 象 ， 从 名 称 就 可 以 猜 到 它 是 记录 每 次 提交 相关 信息 的 一 个 
对 象 。 我 们 仍然 结合 前 面 小 市 的 例子 来 为 读者 进行 讲解 ， 如 图 24-13 所 
/小 。 


92ec2.. 


tree size 


5b1d3 | README 
911e7 | LICENSE 





98ca9... 


initiol commit of my project 





它 包 括 如 下 信息 : 


。Tree 对 象 。 这 是 本 次 提交 所 涉及 的 所 有 文件 的 集合 。 和 和 前面 看 到 的 

情况 一 样 ，commit 指 向 tree 对 象 的 唯一 标志 符 。 

。 作者 (author) 。 本 次 修改 者 的 名 字 。 

e 提交 者 (commiter) 。 本 次 提交 者 的 名 字 ， 它 可 以 和 作者 不 同 。 比 
如 在 管理 员 模 式 中 ， 开 发 者 做 了 修改 工作 ， 但 管理 员 才 是 最 终 的 提 
交 者 。 

。 备注 (comment) 。 对 于 本 次 提交 的 说 明 备 注 ， 这 将 有 利于 我 们 追 
踪 每 次 版 本 的 内 容 变化 。 

















对 于 非 初 次 提交 ， 它 可 能 还 会 有 “parent” 说 明 一 一 这 个 栏 位 将 指 
向 上 一 次 的 提交 对 象 。 比 如 图 24-14 展 示 的 是 3 次 提交 后 的 commit 对 象 关 


J~、oOo 


98ca9.. Je， f30ab. 


initfel comit of my 
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protect to odd new formets to the 


central 


Snapshot A Snapshot B Snapshot C 


全 图 24-14 ”多 次 提交 后 的 commit 对 象 关 系 图 
( 注 : 引用 自 http://git-scm.com/book。) 


由 于 “parent” 的 存在 ， 我 们 可 以 很 方便 地 追溯 到 任意 版 本 的 历史 
记录 ， 并 推算 出 每 个 版 本 发 生 了 哪些 修改 。 而 这 种 推算 的 性 价 比 很 高 ， 
因为 我 们 实际 只 是 创建 了 一 个 个 的 commit 对 象 ， 占 据 了 非常 有 限 的 存储 

空间 。 这 种 链 式 结构 的 commit 关 系 图 也 是 Git 中 分 支管 理 的 基础 之 一 ， 
它 为 分 支管 理 的 快速 性 提供 了 本 质保 障 。 


我 们 可 以 通过 以 下 命令 来 查看 一 个 commit 对 象 : 


gitshow -s --pretty=raw <OBJECT> 


overflow under cectalon 





结果 显示 如 下 : 


android@android-VirtualBox:~/Work/ThinkingInAndroid/GitTest$ git show -s --prett 
y=raw d889964aaaf cef3ce56fd31007c70174cb62e79d 


commit d88 


c70174cb62e7 79d 


fcef3ce56fd31007 


tree 5d8fcf8d3895496eb70febaaaS0a234040f lec7b 
parent Odf9ec62189dc8dd63e8ae655673ef c98396a2c8 
author Xuesen Lin <android@android-VirtualBox. (none)> 1340938774 +0800 
committer Xuesen Lin <android@android-VirtualBox. (none)> 1340938774 +0800 


second commit 


值得 一 提 的 是 ， 通 过 每 次 
个 项 目的 全 部 文件 的 最 新 状态 。 


commit 所 指向 的 tree， 
这 样 做 的 好 处 是 非常 明显 的 ， 即 不 用 融 





事实 上 都 能 得 到 整 


历 提 交 树 ; 就 可 以 还 原 出 工程 状态 。 如 下 是 我 们 在 Android N 版 本 中 针对 
art 虚 拟 机 子 项 目 执行 “git cat-file -p [最 后 一 次 commit 所 对 应 的 


tree 对 象 ] 


blob 
blob 
blob 
blob 
blob 
tree 
tree 
tree 
tree 
tree 
tree 
tree 
tree 
tree 
tree 
tree 
tree 
tree 


”命令 


斤 得 到 的 结果 范例 : 


命令 所 


c4cf98b37c0e25fb0626d53dec10b157b76d662e 
3467f1d0623c219d00b40c4459b51b4196047c82 
341df784001c0c231c38a98068b930434bf5e235 
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 
d27f6a671456e9306054955acbifba006c9b1ibad 
8e7bef719166e764d0dc56db899770fb43285f41 
b5107b82e7a74225d4d2dc153ad0a29998d47050 
81d9b8747e46dd9090cdeS5ea661lecbee3efd3e91 
f1853f69a2ea0a78109d47c16e52841e04a2ee45 
840eb7e7F4044b65d5cb58c68dafa682ad1a2c0a 
95f2df3ea034dc874d42b71936182695fFF571dd9 
193f1eb445cObe22e7640ae33b5cf73880beb603 
06b8a2f10a772a0cccc816bf27d0460858de280e 
5b58a7bd1c94c5ee7bd85e6a4616ae01da9a3f3b 
8235cca340a59548587fbd5fb9c4044df64dc0ec 
92b7e5463186a11354b6b84ab43a009bb999ecc2 
7224495c1c89b3e7bbdb635733d9cfc2b62f0454 
a44699f198fece860db285541e5f8F559c97becd 


4. Tag 对 象 


标签 对 象 为 元 长 的 SHA-1 字 符 串 提供 了 便捷 的 记忆 方法 。 


.gitignore 
Android.mk 
CleanSpec.mk 
MODULE LICENSE APACHE2 
NOTICE 

build 
cmdline 
compiler 
dalvikvm 
dex2oat 
disassembler 
imgdiag 
oatdump 
patchoat 
runtime 
Sigchainlib 
test 

tools 





就 好 比 我 


们 一 般 不 会 去 记 住 某 个 网 站 的 1P 地 址 一 样 一 一 因为 只 要 知道 网 站 域名 ， 
自然 有 DNS 去 做 解析 工作 。 


一 个 tag 对 象 通 常 包括 如 下 信息 。 


Object (RAZ) 。 这 是 由 SHA-1 计 算出 来 的 。 

Type (RA) 。 对 象 的 类 型 。 

Tag (tag 名 称 ) 。 我 们 创建 tag 对 象 时 提供 的 名 称 。 

Tagger (tag 创 建 者 ) 。 创 建 本 条 tag 对 象 的 人 。 

Message (信息 ) 。 描 述 这 条 tag 的 相关 信息 。 

Signature (签名 ) 。 如 果 创 建 tag 时 选择 了 签名 ， 这 条 标签 就 附 有 签 
名 信息 。 


创建 、 列 出 、 删 除 和 验证 一 条 tag 可 以 用 如 下 命令 。 


git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] 
<tagname> [<commit> | <object>] 

git tag -d <tagname>... 

git tag [-n[<num>]] -1 [--contains <commit>] [--points-at <object 
[--column[=<options>] | --no-column] [<pattern>...] 
[<pattern>...] 

git tag -v <tagname>... 


读者 可 以 通过 git - help 命 令 来 获取 详情 。 


事实 上 ， 对 tag 的 操作 会 体现 在 . git 管 理 目 录 下 的 refs/tags 中 。 每 
个 tag 对 象 会 形成 一 个 独立 的 文件 ， 这 样 可 以 方便 管理 、 查 找 和 引用 。 


24.4.4 三 个 区 域 


在 前 面 小 节 中 ， 我 们 提 到 过 Git 中 的 所 有 文件 都 有 4 种 状态 。 那 么 ， 
这 几 种 不 同 状态 下 的 文件 都 分 别 是 如 何 存储 的 呢 ? 

在 Git 的 管理 中 ， 总 共 维护 了 3 个 特殊 区 域 来 做 存储 工作 。 它 们 分 别 
是 : 工作 目录 Working Directory) 、 暂 存 区 (Staging area) 以 及 
仓库 (Repository) 。 


其 关系 如 图 24-15 所 示 。 


G itadd 


TE DK bl Checkout 


G itcommit 





要 正确 理解 这 3 个 区 域 ， 可 以 先 看 看 . git 路 径 中 的 各 管理 文件 和 目 


录 结 构 。 官 方 文 档 并 没有 严格 给 出 这 3 个 区 域 的 划分 。 因 此 从 物理 存储 
的 角度 来 看 ， 它 们 并 非 我 们 设想 的 3 个 独立 的 存储 区 域 。 针 对 Git 的 管理 
特点 ， 可 以 这 样 理解 它们 的 关系 : 





工作 目录 是 项 目 文件 所 在 的 地 方 。 一 般 情况 下 ， 它 与 .sit 目 录 是 同 级 
入 。 这 里 存放 着 开发 者 可 以 直接 修改 的 众多 项 目 文 件 ， 因 此 称 之 为 
工作 目录 。 

暂 存 区 域 (Staging Area) 其 实 是 一 个 文件 。 对 照 Git 的 实现 思想 ， 暂 
存 区 域 应 当 是 .git 目 录 下 的 index 文 件 。 这 里 记录 着 下 一 次 需要 提交 
的 文件 信息 。 开 发 者 可 以 通过 git add 将 新 的 文件 或 者 已 修改 的 文件 
加 入 这 一 区 域 中 。 对 于 那些 未 staged 的 项 目 文件 ， 即 便 已 经 修改 ， 
也 不 会 在 下 一 次 的 提交 中 被 更 新 到 仓库 中 。 因 为 有 中 间 的 暂 存 区 
域 ， 开 发 者 可 以 决定 哪些 文件 是 需要 被 提交 到 仓库 中 的 、 哪 些 则 是 
没有 必要 的 ; 而 且 如 果 发 现 有 问题 ， 也 能 很 方便 地 撤销 操作 。 
仓库 (Repository) 。 这 通常 是 指 本 地 仓库 ， 即 .git/objects 目 录 下 的 
各 对 象 文件 。 这 里 存储 了 所 有 版 本 项 目 文件 的 内 容 。 对 于 一 个 大 型 
项 目 来 说 ， 这 些 文件 的 数量 可 以 轻易 达到 百 万 以 上 的 级 别 ， 因 此 需 
要 压缩 和 打包 和 手段。 如 果 你 用 git clone 从 远程 仓库 创建 过 项 目 ， 应 
该 会 发 现 克隆 下 来 的 objects 目 录 下 没有 任何 对 象 存 在 ， 而 在 /info 
和 /pack 目 录 下 则 有 几 个 比较 大 的 文件 。 这 就 是 Git 对 松散 对 象 实行 
的 打包 管理 。 


我 们 可 以 通过 以 下 命令 来 做 到 这 点 : 





git gc [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-p 


比如 对 于 一 个 在 本 地 创建 的 Git 项 目 ， 经 过 多 次 操作 后 ，objects 目 


录 下 的 文件 情况 如 下 所 示 。 


> info Oitems folder 


v pack Oitems folder 
(Empty) 
> FE 1item folder 
> re 1item folder 
> FEY 1item folder 
> [Ez 1item folder 
> "E 1item folder 
> "E 1item folder 
> jg 28 1item Folder 
> "E 1item folder 
> FEY 1item folder 
> B 1item folder 
> jg Od 1item folder 


一 一 en 


可 以 清楚 地 看 到 ，/info 和 /pack 在 起 始 时 是 空 的 ， 不 包含 任何 对 
象 。 我 们 接 下 来 执行 gc 命令 ， 如 下 所 示 。 
Box:~/Work/ThinkingInAndroid/GitTest$ git gc 


ounting objects: 13, done. 
ompressing objects: 100% (11/11), done. 


Writing objects: 100% (13/13), done. 
otal 13 (delta 0), reused 0 (delta 0) 





之 后 可 以 得 到 新 的 结果 如 下 所 示 。 


"E info 1item folder 
packs 54 bytes plaintext document 
v ja pack 2items folder 
g|| pack-52dF365175736ca94cea2efa0e43802e6F32e386.idx 1.4KB unknown 
a pack-52df365175736ca94cea2efa0e43802e6F32e386.pack 1.8KB Pack200 Java archive 
> jm E 1item folder 


> es item folder 


此 时 松散 的 ob ject 对 象 已 经 得 到 最 大 程度 的 打包 和 压缩 处 理 ， 取 而 
代 之 的 是 几 个 新 文件 。 这 种 打包 方式 对 于 我 们 节省 存储 空间 、 提 高 处 理 
效率 以 及 推送 文件 到 远程 仓库 ， 都 是 大 有 帮助 的 。 


24.4.5 ”分支 的 概念 与 实例 


分 支 (branch) 管理 是 Git 的 一 大 特色 一 一 它 所 提供 的 快速 与 便捷 
的 分 支 操 作 是 开发 者 选择 Git 的 主要 原因 之 一 。 


1. ART 


如 果 查 阅 Git 资 料 ， 就 会 发 现 分 支 这 个 词 被 频繁 地 提 及 。 那 么 ， 什 
么 是 分 支 呢 ? 从 字面 来 理解 ， 它 应 该 是 类 似 于 江河 分 流 的 概念 ， 即 从 主 
干 上 分 叉 开 来 而 形成 的 小 体系 〈 在 水 文学 中 ， 支 流 是 指 汇 入 另 一 主干 水 
体 的 河流 ， 而 分 流 则 是 相反 的 ) 。 人 们 为 了 防止 某 些 水 系 的 规模 太 大 造 
成 洪水 ， 或 者 为 了 农业 ， 经 常会 进行 人 工分 流 的 动作 。 


在 版 本 控制 系统 中 ，branch 代 表 了 这 一 代码 分 支 的 源头 是 主干 
(master) ; 而 且 在 初始 状态 时 ， 它 和 主干 的 内 容 是 一 模 一 样 的 。 而 后 
随 着 开发 的 推进 ， 分 支 逐 渐 有 了 自己 独立 的 进度 空间 ， 和 主体 间 便 互 不 
干扰 了 一 一 直到 另 一 时 刻 ， 基 于 项 目的 需求 ， 我 们 可 以 再 将 这 一 分 支 合 
并 入 主干 。 创 建 分 支 的 一 个 常见 情景 是 : 为 项 目 开 发 一 个 新 的 功能 
(feature) 。 因 为 每 一 个 新 的 功能 开发 都 有 一 段 或 长 或 短 的 稳定 期 ， 
直接 在 主 枝 上 操作 难免 会 影响 到 整个 项 目的 稳定 性 ， 在 这 种 情况 下 我 们 
会 选择 创建 一 个 分 支 来 承载 新 功能 的 开发 。 


对 于 市 面 上 的 很 多 版 本 控制 系统 ， 新 建 分 支 意 味 着 整个 项 目 工 程 的 
复制 一 一 而 这 通常 是 烦琐 而 耗 时 的 。Git 基 于 自身 的 特点 ， 提 出 了 另 一 
种 高 效 的 实现 方式 。 

简 而 言 之， 就 是 : 

Git 中 的 分 支 ， 其 实 只 是 一 个 指针 。 

虽然 实际 过 程 会 稍微 复杂 一 些 ， 但 上 面 这 句 话 却 是 Git 分 支 的 核心 


理念 ， 因 此 请 读者 务必 牢 牢 记 住 。 后 面 我 们 再 针对 具体 实例 来 慢 慢 解 释 
这 种 说 法 的 缘由 。 


2. Git 中 的 分 支 指针 


前 面 小 节 我 们 曾 用 简 图 描述 过 一 个 简单 项 目 执行 了 3 次 提交 后 的 
commit 对 象 关 系 。 除 了 图 中 所 示 的 链接 外 ， 其 实 还 有 一 个 分 支 指针 没有 
标注 出 来 。 我 们 对 简 图 做 了 修改 ， 如 图 24-16 所 示 。 


我 们 说 分 支 是 一 个 指针 ， 更 进一步 讲 ， 它 是 指向 某 个 commit 对 象 的 
Bet; 而 且 在 默认 情况 下 ， 项 目 处 于 master 开 发 分 支 中 。 因 此 从 图 中 可 
以 看 到 ， 分 支 指向 了 “f30ab…” 这 个 commit 对 象 。 分 支 是 一 个 动态 变 
化 的 指针 ， 每 次 提交 后 都 会 指向 当前 分 支 的 最 后 一 个 commit 〈 注 意 是 针 
对 当前 分 支 的 提交 ， 其 他 分 支 的 commit 动 作 不 会 受 影响 ) 对 象 。 


” ”比如 在 3 次 提交 后 又 有 新 的 提交 ， 那 么 指针 就 会 变 成 如 图 24-17 所 
/小 。 
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全 图 24-16 ”默认 的 分 支 指针 示意 图 节 
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A 图 24-17 分 支 指针 随 提交 而 改变 
接 下 来 我 们 通过 实例 进一步 讲解 分 支 的 基本 操作 。 
3. 分 支管 理 的 基本 操作 
明白 了 分 支 指针 的 概念 后 ， 我 们 再 来 看 看 多 分 支 的 情况 。 
分 支 的 管理 包括 新 建 、 查 看 、 删 除 等 多 种 操作 ， 都 可 以 通过 以 下 命 


令 来 完成 


git branch [--color[=<when>] | --no-color] [-r | -a] 

[--list] [-v [--abbrev=<length> | --no-abbrev] ] 
[--column[=<options>] | --no-column] 

[(--merged --no-merged | --contains) [<commit>]] [<pattern>...] 


git branch [--set-upstream | --track | --no-track] [-1] [-f] <bra 
git branch (-m | -M) [<oldbranch>] <newbranch> 
git branch (-d | -D) [-r] <branchname>... 


git branch --edit-description [<branchname> ] 


比如 我 们 要 新 建 一 个 名 为 “branch_basic” 的 分 支 ， 可 以 使 用 : 


git branch branch_basic 


此 时 再 查看 分 支 情况 ， 可 以 看 到 已 经 创建 成 功 如 下 所 示 。 


ndroid@android-VirtualBox:~/Work/ThinkingInAndroid/GitTest$ git branch 
branch basic 





带 “#” 号 的 是 当前 的 工作 分 支 。 可 见 虽 然 我 们 成 功 创建 了 一 个 新 
的 分 支 ， 但 并 没有 切换 到 这 上 面 来 。Git 是 通过 . git 目 录 下 的 HEAD 文 件 
来 记录 当前 的 工作 分 支 的 。 一 般 情 况 下 ， 这 个 文件 的 格式 如 下 (表示 当 
前 在 master 分 支 中 ) : 


ref: refs/heads/master 


开发 者 需要 通过 以 下 命令 来 切换 分 支 : 
git checkout branch_basic 


此 时 就 切换 到 了 新 分 支 上 ， 如 下 所 示 。 


master 


而 且 分 支 关系 图 同时 发 生 了 变化 ， 如 图 24-18 所 示 。 


就 像 在 0 语言 中 我 们 会 给 指针 赋 子 一 个 初始 值 一 样 ，Git 的 新 建 分 支 
也 会 有 一 个 原始 指向 。 默 认 情 况 下 ， 新 的 分 支 的 指向 和 master 分 支 一 
样 。 


现在 我 们 对 项 目 文件 进行 修改 ， 并 完成 提交 动作 。 这 样 一 来 ， 分 支 
指针 也 会 发 生 相 应 的 变化 ， 如 图 24-19 所 示 。 





全 图 24-18 新 建 分 支 的 初始 值 





branch basic 
全 图 24-19 在 新 分 支 上 执行 提交 操作 后 


此 时 两 个 分 支 就 出 现 了 分 离 。 假 如 此 时 再 次 切换 回 到 主 分 支 ， 然 后 
做 一 些 修改 并 提交 ， 情 况 就 又 有 了 新 变化 ， 如 图 24-20 所 示 。 
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全 图 24-20 两 分 支 独立 开发 的 情 


随 着 开发 的 推进 ， 会 衍生 出 更 多 的 分 支 ， 由 此 产生 各 种 复杂 的 情 
况 。 不 过 由 于 Git 中 创建 分 支 的 高 效率 ， 它 鼓励 开发 者 新 建 分 支 。 当 然 
一 旦 项 目 开 发 进展 到 一 定 程度 ， 我 们 还 是 应 该 考虑 把 分 支 合并 到 主干 
上 ; 而 且 与 上 图 不 同 的 是 ， 我 们 一 般 不 会 让 master 分 支出 现在 分 又 上 ， 
而 是 新 建 男 一 分 支 来 完成 图 中 所 示 的 master 工 作 。 


A ET AAD y I. 


目前 业 表 有 很 多 版 本 分 支 的 管理 方式 ， 其 中 使 用 非常 广泛 的 一 种 就 
是 ETE. 分 支 开发 ”。 从 字面 意思 上 不 难 理解 ， 这 种 开发 模式 的 
核心 思想 是 将 变化 的 部 分 (包括 新 特性 ， 问 题 修复 等 ) 通过 拉 出 分 支 的 
方式 进行 独立 开发 ， 来 达到 保持 主干 稳定 的 目的 。 这 样 一 来 在 发 布 新 版 
本 的 时 候 ， 管 理 员 只 需要 从 主干 上 取代 码 融 可 以 了 ; 而 新 开发 的 特性 或 
者 修复 的 问题 亦 可 以 在 验证 后 合并 到 主 分 文 。 同 理 ，“ 主 干 开 发 ， 分 支 


发 布 ”的 特性 也 是 类 似 的 。 总 的 来 说 它们 各 有 优 缺 点 ， 需 要 根据 不 同 的 
项 目 诉求 来 做 正确 的 取舍 。 


不 论 情况 多 么 复杂 ， 版 本 管理 系统 所 要 做 的 核心 工作 仍然 是 我 们 在 
本 章 开 头 所 提出 的 抽象 图 。 读 者 可 以 根据 这 几 个 小 节 的 讲解 ， 来 仔细 思 
考 一 下 Git 是 如 何 完 成 这 些 核 心 工作 的 。 


Git 提 供 的 很 多 其 他 命令 在 本 章 中 并 没有 涉及 。 另 外 ， 它 的 服务 器 
部 署 我 们 也 没有 去 探究 。 不 过 我 们 所 讨论 的 这 些 命令 ， 都 是 开发 者 在 实 
际 工程 项 目 中 经 常会 用 到 的 。 特 别 是 本 章 在 对 Git 分 析 过 程 中 给 出 的 计 
如 “版 本 管理 抽象 图 ”“ 分 支 是 指针 ”等 概念 ， 都 是 这 个 系统 最 基础 也 
最 核心 的 设计 理念 。“ 万 变 不 离 其 宗 ”， 相 信 读 者 在 阅读 了 本 章 内 容 以 
后 再 去 使 用 或 者 深入 解析 Git， 束 会 发 现 它 已 经 变 得 不 再 难 懂 了 。 


| 
系统 调试 辅助 工具 


本 章 将 向 读者 讲解 Android 系 统 调试 需要 用 到 的 几 个 核心 工具 ， 即 
Emulator 、Android 和 ADB。 





25.1 万 能 模拟 器 Emulator 

Android 系 统 中 自 帝 的 Emulator 几 乎 能 模拟 “手持 设备 ”的 所 有 硬 
件 和 软件 特性 〈 除 了 用 户 不 能 拨打 实际 电话 外 ) 一 一 不 论 对 应 用 程序 开 
发 还 是 系统 移植 ， 这 都 是 非常 实用 的 。 尤 其 是 对 前 者 ， 模 拟 器 提供 的 定 
制 功能 让 用 户 可 以 轻松 创建 出 各 种 硬件 配置 的 “设备 ”， 这 无 疑 为 我 们 
验证 产品 的 兼容 性 和 可 靠 性 节约 了 大 量 的 时 间 。 


Android 的 模拟 器 是 基于 QEMU 的 。 后 者 也 是 一 个 开源 项 目 ， 由 法 国 
计算 机 程序 员 Fabr ice Bellard 编 写 。 这 位 实现 最 快 圆 周 率 算 法 的 作者 
男 一 知名 开源 项 目 是 Ffmpeg， 感 兴趣 的 读者 可 以 了 解 一 下 。 


秉承 本 书 的 一 贯 “ 作 用 ”， 我 们 将 先 对 QEMU 进 行 一 定 程度 的 解析 
从 中 让 读者 明白 QEMU“ 已 经 做 了 哪些 ”， 然 后 再 来 看 看 
Android“ 选 择 了 哪些 ”“ 废 弃 了 哪些 ”以 及 “ 改 恨 了 哪些 ”。 这 样 即 
便 脱 离 了 Android 的 环境 “如 读者 想 将 模拟 器 运用 于 其 他 非 Android 项 目 
中 ) ， 也 都 不 会 再 党 得 无 从 下 手 了 。 


接 下 来 将 分 为 两 个 方向 展开 一 一 首先 ， 我 们 会 介绍 QEMU 这 个 模拟 
器 ， 让 读者 对 它 有 个 感性 的 认识 ; 然后 我 们 会 讲解 Android 模 拟 器 从 
QEMU 中 继承 和 扩展 出 的 一 些 重要 特性 。 





25. 1.1 QEMU 
1. 虚拟 化 技术 
要 想 了 解 QUEMU， 就 需要 先 补充 虚拟 化 技术 的 一 些 背景 知识 。 


EHW (virtualization) 是 对 某 种 事物 的 虚拟 实现 一 一 这 些 事物 
并 不 是 真实 存在 的 ， 而 是 通过 特定 手段 创建 出 来 的 。 比 如 目前 我 们 已 经 
可 以 虚拟 出 操作 系统 、 存 储 设备 等 。 虚 拟 化 技术 是 实现 “ 云 计 算 ” 的 基 
A Ln oe 
讲解 重心 。 


提供 虚拟 化 技术 的 软件 在 发 展 早期 被 称 为 “控制 程序 ”， 后 来 则 慢 
慢 变 为 “Hypervisor” 或 者 VMM (Virtual Machine Monitor) 。 从 字面 
就 能 看 出 来 ， 它 是 运行 于 其 上 程序 (Guest Software) 的 控制 和 监督 


#4; 而 且 Guest Software 并 不 只 局 限于 某 种 程序 ， 某 些 情况 下 它 甚至 是 
指 整个 操作 系统 。 如 在 工程 项 目 中 ， 我 们 经 常 需 要 在 虚拟 机 上 运行 
Windows 或 者 Linux 操 作 系 统 ， 如 图 25-1 所 示 。 





HEA 


全 图 25-1 虚拟 机 


根据 VMM 的 功能 描述 ， 我 们 可 以 很 自然 地 联想 到 : 它 的 运行 环境 是 
什么 样 的 呢 ? 


。 对 于 直接 在 底层 硬件 上 执行 的 VMM， 我 们 称 为 Native 或 者 Bare Metal 


型 。 


这 种 方式 不 需要 底层 操作 系统 的 支持 ， 因 为 VMM 本 身 就 是 宿主 。 目 
前 这 类 虚拟 机 中 比较 有 名 的 有 : Oracle VM Server for SPARC, 
KVM (Kernel Virtual Machine) 、VMWare EXS/ESXi 以 及 Microsoft 
Hyper=-V 等 。 


。 同样 ， 如 果 是 安装 于 其 他 操作 系统 之 上 的 VMM， 就 被 称 为 hosted 类 
型 。 它 的 割 主 操作 系统 通常 只 是 普通 的 操作 系统 。 比 如 我 们 在 
Windows 操 作 环 境 中 安装 的 VirtualBox 就 属于 这 种 方式 。 其 他 比较 受 
欢迎 的 此 类 VMM 有 : VMWare Workstation、Bhyve 等 。 


除了 自身 的 运行 环境 外 ，VMM 为 Guest 0S 提 供 的 支撑 方法 也 有 多 种 
分 类 ， 以 下 列 出 其 中 比较 核心 的 几 种 。 


e 全 虚拟 化 (Full virtualization) 


全 虚拟 化 可 以 让 运行 于 其 上 的 客户 操作 系统 不 用 做 任何 修改 。 可 想 
而 知 ， 这 融 要 求 VYMM 提 供 完 整 的 硬件 模拟 ， 包 括 处理 器 、 物 理 内 存 、 各 
种 外 设 、 时 钟 等 。 这 种 技术 的 难点 是 如 何 实现 客户 操作 系统 特权 指令 的 
执行 。 因 为 在 VMM 的 控制 下 ， 可 能 会 有 不 止 一 个 客户 操作 系统 存在 。 它 
们 都 被 禁止 改变 对 万 的 状态 ， 或 者 去 算 改 VMM 的 运行 值 。 对 于 这 一 问 
题 ， 不 同 的 VMM 开 发 商 有 各 自 的 实现 一 一 同时 这 也 是 影响 VMM 执 行 效率 的 
重要 因素 之 一 。 


这 种 虚拟 技术 的 优点 是 不 需要 更 改 Guest 0S， 因 此 得 到 了 广泛 的 应 
用 。 我 们 所 熟悉 的 ， 如 0racle VM, Virtual PC, Vmware 
Workstation, KVM, QEMU, Paralles Workstation 等 都 采用 了 这 种 技 
术 。 





o 半 虚 拟 化 (Partial virtualization) 


又 翻译 为 “部 分 虚拟 化 ”， 是 和 “全 虚拟 化 ”类 似 的 一 种 技术 。 
们 都 为 Quest 0S 提 供 了 硬件 的 模拟 ， 只 不 \ 过 半 虚 拟 化 技术 需 要 让 us 
0S 根 据 自 己 提供 的 接口 做 部 分 修改 ， 以 符合 诸如 特权 指令 运行 的 要 求 。 


这 种 方式 的 优点 在 于 整体 运行 速度 比 全 虚拟 化 要 快 ， 而 且 架 构 也 精 
简 些 ; 缺点 也 很 明显 ， 即 需要 Guest 0S 做 相应 修改 。 这 类 VMM 的 代表 有 
Xen 以 及 Microsoft Hyper-V=. 


o 硬件 辅助 虚拟 化 (Hardware-assisted virtualization) 


准确 地 说 ， 这 种 技术 是 用 于 协助 上 面 两 种 方式 来 完成 优化 的 。 硬 件 
辅助 的 意思 是 ， 借 助 于 专门 针对 虚拟 化 技术 而 提供 的 硬件 支持 来 大 幅 改 
善 上 述 方法 中 的 不 足 ， 以 使 VMM 的 运行 速度 更 加 接近 于 实际 物理 机 。 当 
前 众多 主流 的 虚拟 机 产品 都 支持 硬件 辅助 ， 如 Virtual Box、Vmware 
Workstation, Microsoft Virtual PC、KVM 和 Xen 等 。 


明和 月 了 虚拟 化 技术 的 分 类 、 功 能 及 工作 方式 后 ， 我 们 再 切入 QEMU 应 
TABLA REI BAS T o 


2. QEMU 简介 
读者 之 前 如 果 没 有 接触 过 QEMU， 那 么 最 好 先 去 阅读 以 下 几 篇 文章 。 


e “QEMU, a Fast and Portable Dynamic Translator” , Fabrice Bellard, 
http://static.usenix. 
otg/publications/library/ proceedings /usenix05/tech/freenix/full_papers/’ 


这 是 QEMU 作 者 写 的 一 篇 论文 ， 具 有 绝对 的 权威 性 。 


e “QEMU Emulator User Documentation” , 
http://qemu.weilnetz.de/qemu-doc.html 


这 篇 文章 是 QEMU 使 用 指南 ， 可 以 作为 入 门 文档 。 


。 对 于 开发 者 而 言 ， 如 果 想 学 习 QEMU 内 部 实现 原理 或 者 希望 修改 
QEMU 源 码 ， 可 以 参阅 官方 推荐 的 指南 。 





总 的 来 说 ，QEMU 有 两 种 工作 模式 。 
全 系统 模式 
在 这 种 方式 下 ，QEMU 可 以 模拟 出 一 个 完整 的 系统 ， 包 括 若干 个 处 理 


器 和 外 围 设备 。 


。 用 户 模 式 


序 


o 


在 这 种 方式 下 ，QEMU 可 以 在 一 个 CPU 上 运行 针对 另 一 CPU 所 编译 的 程 


在 全 系统 模式 下 ，QEMU 支 持 以 下 硬件 设备 : 

PC (x86 or x86 64 processor) 

ISA PC (old style PC without PCI bus) 

PREP (PowerPC processor) 

G3 Beige PowerMac (PowerPC processor) 

Mac99 PowerMac (PowerPC processor, in progress) 
Sun4m/Sun4c/Sun4d (32-bit Sparc processor) 
Sun4u/Sun4v (64-bit Sparc processor, in progress) 
Malta board (32-bit and 64-bit MIPS processors) 
MIPS Magnum (64-bit MIPS processor) 

ARM Integrator/CP (ARM) 

在 用 户 模式 下 ， 支 持 的 硬件 设备 为 : 

x86 (32 and 64 bit) 


PowerPC (32 and 64 bit) 


ARM, MIPS (32 bit only) 
Sparc (32 and 64 bit) 
Alpha, ColdFire (m68k) 
CRISv32#IMicroBlaze CPU 
3，QEMU 的 安装 与 编译 


在 使 用 QEMU 前 ， 我 们 需要 先 安装 它 。 和 大 部 分 软件 一 样 ， 它 既 可 以 
直接 使 用 安装 包 的 形式 来 安装 ， 也 可 以 通过 源码 编译 后 再 进行 安装 。 


如 果 是 选择 前 者 ， 可 以 在 系统 中 使 用 以 下 命令 。 
Debi an/Ubuntu: 
$ sudo apt-get install qemu 
Red Hat/ Fedora: 
$ yum install qemu 
Gentoo: 
$ emerge qemu 
如 果 和 希望 通过 源码 编译 来 安装 ， 下 载 地 址 是 : 
$ git clone git://git.qemu.org/qemu.git 
编译 过 程 很 简单 ， 可 以 选择 在 Li nux 或 者 Windows 下 完成 操作 ， 甚 至 
也 可 以 在 Linux 下 编译 Wi ndows 版 本 的 QEMU。 我 们 推荐 在 Linux 下 编译 生 
成 可 执行 程序 。 方 法 如 下 : 
# 下 载 后 ， 先 解压 REMU 源 码 包 
$ ./configure 
$ make 


$ make install # 就 这 么 简单 


4. QEMU 的 常用 功能 


下 面 分 几 个 类 别 来 讲解 QUEMU 的 常用 功能 
(1) 标准 选项 如 表 25-1 所 示 。 


ww EN 








Peson otc TAJER h 


-machine 选择 被 模拟 的 机 器 。 可 以 使 用 - 
[type=]name[,prop=value[,.…]]limachine? 来 获知 可 使 用 的 机 器 列表 


选择 CPU 模式 。 同 样 可 以 使 用 - 
cpu? 来 获得 可 用 的 选项 列表 


ampal eores=cores] 设置 模拟 的 CPU 数目 。 不 同 硬件 设 
备 支持 的 最 大 CPU 数量 是 不 同 的 。 


[,threads=threads|[,sockets= 和 
sockets][,maxcpus=maxcpus] a e i 


将 le 所 指 问 的 文件 作为 系统 的 相 
应 存储 天 设备 





新 建 一 个 设备 





-drive 
option[,option|,option[,...]]] 










以 file 指 定 的 文件 作为 板 上 的 
a 


-boot [order=drives | 
bonce urvas] [,menu=onloff] 设 定 启动 顺序 
[,splash= sp_name][,splash- 
time=sp_time] 


设置 虚拟 内 存 大 小 (MFI) o BR 


设置 键盘 语言 ， 如 位 表示 法 语 。 默 
认 情 况 下 是 en-us 


oe 显示 PT PT 


(2) USB 选 项 如 表 25-2 所 示 。 









-k language 





T252 a 





添加 USB 设 备 ， 如 鼠标 、 移 动 硬 盘 、 
-usbdevice devname 串口 设备 等 


ae 添加 设备 驱动 


driver[,prop[=value][,...]] 






(3) 文件 系统 选项 如 表 25-3 所 示 。 
表 25-3 ”文件 系统 选项 


选 项 


-fsdev fsdriver,id=id,path=path,[security_model=security_model] 
[,writeout=writeout][,readonly][,socket=socket|sock_fd=sock_fd] 


-virtfs 
fsdriver[,path=path],mount_tag=mount_tag[,security_mode\l=security_mode 
[,writeout=writeout][,readonly][,socket=socket|sock_fd=sock_fd] 


-Name name 


-uuid uuid 





(4) 显示 选项 如 表 25-4 所 示 。 


表 25-4 显示 选项 


将 QEMU 变 为 命令 行 样 


通过 右 Ctrl 键 来 获取 鼠标 


使 能 Spice 远 程 桌面 协议 





(5) 网 络 选项 如 表 25-5 所 示 。 


表 25-5 网络 选项 





选 项 


-net nic[,vlan=n][,macaddr=mac][,model=type] 创建 新 的 网 
[name=name][,addr=addr][,vectors=v] 络 接口 


-net user[,option][,option][,...] 


-net tap[,vlan=n][,name=name][,fd=h][,ifname=name] 


[,script=file] [,downscript=dfile][,helper=helper] 


-net bridge[,vlan=n][,name=name][,br=bridge] 
[,helper=helper] 





(6) 针对 Linux/Multiboot 如 表 25-6 所 示 。 


表 25-6 针对 Linux/Multiboot 





(7) 调试 选项 如 表 25-7 所 示 。 


表 25-7 调试 选项 


we 项 说 明 


为 模拟 器 指定 串口 设备 。 比 如 在 Windows 下 ， 可 以 
pon -serial COMn 来 指定 模拟 器 需要 使 用 宿主 机 的 某 
O 


serial dev 


T T 
© 
=) 
= 
O 
= 


1% E ONL Am onitor#% [5] EJ ENLA dev E 


将 QEMU 的 进程 PID 保 存 到 file 中 


以 单 步 调试 的 模式 运行 模拟 器 


Q 


eV 








系统 开始 时 不 要 启动 CPU， 只 有 当 输 入 “时 才 继 续 





等 待 gdb 的 连接 


-gdb tcp::1234 的 简写 
输出 log 文 件 到 /tmp/qemu.log 
将 上 面 的 log 保 存 到 logfile 路 径 中 


设置 BIOS、VGA BIOS 和 键盘 布局 文件 地 址 的 目录 


设置 BIOS 文 件 名 。 结 合 上 面 选项 找到 BIOS 文 件 


I I 1 I 1 I I 
JEE ET TEL: 
Nn F © ez ga = 
im, a ga jar D > 
= = = m D D 
& > = T = 
已 D 





-enable- ”使 能 KVM 的 全 虚拟 支持 。 这 个 选项 只 有 当 我 们 在 编 
kvm 译 时 打开 了 KVM 支 持 选项 才 有 效 


-Nno- 


shutdown 


ee ec wal, 


writeconfigl 将 系统 配置 文件 写 入 fle 中 
file 





以 上 几 个 列表 给 出 了 QEMU 最 常见 的 一 些 用 法 。 接 下 来 在 Android 模 
拟 器 的 学 习 过 程 中 ， 读 者 可 以 思考 : 


。Android 模 拟 器 继承 了 QEMU 的 哪些 “基因 ; 
。 如何 从 QEMU 入 手 来 为 Android 模 拟 器 添加 新 功能 。 


25.1.2 Android 工程 中 的 QEMU 


Android 项 目 中 的 QEMU 源 码 主 体 在 external/qemu 中 。 不 过 我 们 并 不 


分 析 它 的 源码 实现 ， 而 是 从 它 提 供 的 功能 和 特性 中 来 体会 Android 对 
QEMU 的 改进 。 


1. 命令 行 基本 用 法 
使 用 Android 模 拟 器 的 一 般 格式 为 : 

emulator -avd <avd_name> [-<option> [<value>]] ... [-<qemu args>] 
它 所 提供 的 选项 非常 丰富 ， 下 面 将 分 为 多 个 类 别 来 分 别 说 明 。 
(1) 使 用 AVD 如 表 25-8 所 示 。 


AVD 为 模拟 器 z 提 供 了 一 个 “虚拟 设备 ” 外观、 基本 的 硬件 配置 等 
都 是 可 以 调整 的 ， 可 以 参见 下 一 小 节 关 于 Android 工 具 的 讲解 ) 。 


表 25-8 使 用 AVD 








选 项 ~à 
[ara sanane hinges 个 AVD。 这 个 选项 是 必需 的 


(2) 磁盘 映像 文件 如 表 25-9 所 示 。 
表 25-9 磁盘 映像 文件 


设置 user-data 的 映像 文件 。 如 果 没 有 ， 系 统 会 寻找 名 
为 userdata-qemu 的 映像 文件 来 代替 








(3) 系统 相关 如 表 25-10 所 示 。 
表 25-10 系统 相关 


重 定向 兼容 NMEA 的 GPS 到 某 个 字符 设备 。 注 意 : 
设备 的 书写 必须 符合 QEMU 串 口 设 备 的 格式 。 可 以 
参见 前 面 QEMU 的 “-serial -dev” 选 项 


<device> 





Loi ls 时 关闭 JNI 检 查 | 


传递 参数 给 QEMU。 注 意 : 如 果 使 用 此 选项 ， 必 须 
保证 它 是 放 在 最 后 面 的 ， 因 为 其 后 的 所 有 选项 都 将 
被 认为 是 要 传递 给 QEMU 的 





jem» aa 
打开 GPU 图 形 加 速 


ear 格式 同上 面 -gps 的 
HI 





(4) UI 相关 如 表 25-11 所 示 。 


#225-11 Ul 相关 







nave ape [rain 默认 值 为 165 
| | 


| | 


EN 上 闭 模拟 器 的 启动 时 动画 | 
关闭 模拟 器 的 图 形 窗口 显示 


调整 显示 窗口 的 比率 。 有 效 值 为， 
-Scale <scale> 。 rai a AY 

e Auto。 表 示 让 模拟 器 自动 选择 最 佳 数值 
不 使 用 模拟 器 外 观 


使 用 指定 的 键盘 绑 定 。 即 主机 按键 与 模拟 器 
按键 的 对 应 关系 


-keyset <file> 
使 用 指定 的 overlay 图 像 


设置 onion 外 观 的 透明 度 ， 默 认 值 为 50 








-onion-rotation 


yt . nl f oo P 必须 H 、 、 或 
is 设置 onion 外 观 的 人 位置， 必须 是 0、1、2 或 3 





(5) 网 络 相 关 如 表 25-12 所 示 。 


表 25-12 ”网 络 相 关 








设置 DNS 服务 器 


设置 HTTP/HTTPS 代 理 
格式 为 : 


http://<server>:<port> 
http://<username>:<password>@<server>: 
<port> 


-netdelay <delay> | 设置 网 络 延 迟 值 ， 模 拟 比 较真 实 的 网 络 环境 
BE] -netspeed full -netdelay none 





-netspeed <speed> 


设置 网 络 速度 ， 默 认 值 为 full。 可 选 值 有 如 下 
几 种 : 

e gsm (GSM/CSD) 

Up: 14.4, down: 14.4 

e hscsd (HSCSD) 

Up: 14.4, down: 43.2 

e gprs (GPRS) 

Up: 40.0, down: 80.0 

e edge (EDGE/EGPRS ) 

Up: 118.4, down: 236.8 

eumts (UMTS/3G) 

Up: 128.0, down: 1920.0 

e hsdpa (HSDPA) 

Up: 348.0, down: 14400.0 

e full (no limit) 

Up: 0.0, down: 0.0 

è <num> 

自 定 义 上 传 和 下 载 值 都 为 num 


è <up>:<down> 


| 
(6) 调试 相关 如 表 25-13 所 示 。 
表 25-13 ”调试 相关 








使 能 logcat 得 出。 注意 : 为 了 不 影响 运行 效率 ， 部 分 
手机 厂商 对 logcat 进 行 了 过 滤 和 控制 ， 这 种 情况 下 开 
厂商 指定 的 设置 中 去 手动 打开 logcat 功 能 





能 root 权 限 的 终端 并 指定 字符 设备 来 与 之 通信 


码 退 踪 ， 并 写 入 指定 文件 





-trace 能 代 
<name> 
使 能 verbose 模 式 的 输出 ， 等 价 于 -debug-init 


(7) 帮助 信息 相关 如 表 25-14 所 示 。 
表 25-14 ”帮助 信息 相关 





| | 


显示 -debug <tags> 的 帮助 信息 


显示 模拟 器 硬盘 映像 文件 的 使 用 帮助 





显示 模拟 需 环 境 变量 帮助 


显示 当前 按键 的 绑 定 信息 ， 参 见 “-keyset 
<file>” 选 项 的 说 明 


显示 如 何 定义 新 的 按键 绑 定 


示 如 何 使 用 AVD 





25.1.3 模拟 器 控制 台 (Emulator Console) 


RAGE, Android 7th SARRA grag te jaa 
个 用 于 和 adb 进 行 通信 ， 另 uF 
拟 器 控制 台 的 端口 号 一 定 2 候 数 控制 台 为 自动 化 测试 近 供 了 强 车 力 的 
保障 ， 读 者 可 以 参考 本 书 中 讲解 测试 内 容 的 章节 来 了 解 更 多 信息 。 


连接 一 个 控制 台 的 语法 如 下 : 
telnet localhost &lt;console_port> 


如 果 不 清楚 console_port 的 具体 值 ， 可 以 先 用 adb devices 进 行 查 
询 。 


完成 连接 后 将 会 有 如 下 提示 。 














Android Console: type ’help’ for a list of commands 





后 我 们 就 可 以 向 模拟 器 发 送 命 令 了 。 通 用 格式 如 下 : 
命令 < 空格 > 子 命令 
例如 利用 sms 命 令 发 送 一 条 短信 给 模拟 器 ， 应 遵循 如 下 格式 : 


sms send 12345 content 
命令 子 命令 号 码 (参数) AK (参数 ) 


表 25-15 详 细 描 述 了 Emulator Console 中 的 常见 命令 ， 以 供 读 者 查 
阅 。 


3225-15 Emulator Console 中 的 重要 命令 一 览 表 





说 了 
显示 当前 控 
-| 
staus fH 
[= 


启动 模拟 器 
ey ee Ge 


[| | 


fr IER as 
拟 絮 处 于 挂 
从 生动 关闭 


测试 中 古 比 
BCS HH A 





件 ， 这 条 命 查询 菜 个 类 
ae 代码 数量 : 
测试 中 是 比 (405) 
较 常 用 的 BY BED 
EV_ABS 
codes <type> 其 余 类 型 





比如 EV_RE 

H: 

REL X 

REL Y 

发 送 组 成 <n 
< > Sy 









提供 GPS 修 
<longitude> 
进 制 表 示 


<longitude><latitude> [<altitude>] ll<latitude>: 


me 


1X 


发 送 一 个 NI 
的 句子 给 模 
ba 

持 “$GPGG/ 


模拟 一 个 来 
将 一 个 通话 
<phonenumber> 2 “active’— 
i 个 通话 处 于 


者 “held” 

挂 断 一 个 去 
<phonenumber> 态 改 为 “bus 
通话 处 于 “w 


Kphonenumber> ROK 


PXAEGPRS4 
态 ， 可 选 值 
è unregister 
可 用 网 络 
e home 一 一 
络 中 
è roaming 一 
data <state> è searching | 
网 络 


nmea <sentence> 








busy 








D D D 
E ~ E 
A D = 
om gw) 
一 一 oo 







将 状态 改 为 
提 是 当前 状 
为 “active” 马 


列 出 当前 所 
pone ie 


改变 GPRS 
可 选 值 为 : 
e unregister 
网 络 


e home 一 一 





hold <phonenumber> 


FE 


list 


voice <state> 


è roaming 一 
è searching | 
è denied — 
可 用 
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pea overheat|dead|overvoltage|failure> 设置 电池 的 
设置 剩余 电 
100) 


NONE 退出 控制 台 
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列 出 当前 所 
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可 以 dt “tcp > 
<protocol>:<host- <host-port>: 
port>:<guest-port> host 上 需要 ] 


删除 一 个 端 
同上 

模拟 SMS 来 
<senderPhoneNumber> <senderPhot 
<textmessage> 电信 号码 
<textmessag 


列 出 当前 所 
态 信息 ， 包 
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status 





get |ksensomame> REE ME 


<sensorname><value-a>[:<value-b> |]. 
bat 7 设置 某 个 传 
[:<value-c>]] 


pcae escale> TL 


25.1.4 实例 : 为 Android 模 拟 器 添加 串口 功能 


使 用 过 Android 模 拟 器 的 读者 应 该 会 发 现 ， 它 没有 提供 串口 功能 。 
这 对 于 应 用 开发 人 员 来 说 影响 不 大 ， 因 为 他 们 基本 上 不 会 有 类 似 需求 。 
但 是 对 于 系统 工程 人 员 来 说 ， 串 口 的 使 用 还 是 比较 广泛 的 。 比 如 不 少 
Android 产 品 要 求 通过 串口 去 控制 蓝牙 、GPS 模 块 ; 或 者 产品 与 1P0D 设 备 
通过 串口 进行 连接 通信 等 。 


可 想 而 知 ， 如 果 我 们 能 在 Androi d 模 拟 器 上 仿真 串口 功能 ， 那 么 就 
可 以 大 大 减少 程序 开发 和 调试 上 的 麻烦 ， 如 图 25-2 所 示 。 


Emulator [dev/ttySN 


Serial Port OnPC 


Device 





全 图 25-2 模拟 器 
接 下 来 分 步骤 说 明 上 图 的 实现 过 程 。 
(1) 首先 需要 局 动 一 个 带 串 口 的 模拟 器 。 根 据 前 几 个 小 节 的 分 
析 ， 读 者 应 该 已 发 现 QEMU 本 身 是 支持 串口 模拟 的 ， 只 是 Android 没 有 继 


承 这 一 “基因 ”一 一 因此 我 们 可 以 通过 向 QEMU 传 递 参数 来 达到 目的 。 比 
如 在 Windows 操 作 系 统 环境 下 ， 可 以 建立 如 下 脚本 : 


"C:\Program Files\Android\android-sdk\tools\emulator" -avd Device 


第 一 个 参数 是 emulator 程 序 本 身 ， 最 好 用 双 引 号 来 将 整个 路 径 包 含 


-avd 选 项 指明 需要 局 动 的 WD， 也 可 以 根据 需要 来 指定 具体 的 
system，kerne1 等 映像 文件 。 这 里 我 们 采用 的 都 是 默认 的 系统 映像 。 


最 后 ， 我 们 通过 -qemu 选 项 传 入 需要 模拟 的 串口 ， 即 COM1 。 这 个 
COM1 是 PC 主机 上 真实 存在 的 串口 设备 〈 可 以 通过 Wi ndows 中 提供 的 设备 
管理 器 来 查看 ) 。 当 然 ， 我 们 也 可 以 创建 虚拟 的 串口 。 比 如 利用 软件 工 
具 在 机 器 中 创建 一 对 虚拟 串口 COM3/COM4， 然 后 让 emulator 使 用 COM3， 
而 串口 分 析 工 具 则 打开 COM4， 这 样 就 可 以 实现 emulator 和 分 析 工 具 间 的 
通信 了 。 这 在 实际 工程 项 目 中 是 非常 有 用 的 一 种 调试 手段 。 


(2) 经 过 上 一 步骤 ， 我 们 成 功 局 动 了 一 个 市 串口 的 模拟 器 。 接 下 
来 ， 还 需要 找 出 这 个 串口 在 /dev 下 的 名 称 。 按 照 Android 模 拟 器 的 实 
现 ， 它 会 在 系统 的 /dev/ttySN 串 口 设备 编号 上 ， 为 新 增 的 串口 分 配 一 个 
名 称 (N 表 示 有 多 个 串口 ， 依 次 递增 )。 


比如 系统 本 身 已 有 /dev/ttyS0、/dev/ttyS1， 那 么 新 加 的 串口 就 变 
成 了 /dev/ttyS2。 


我 们 需要 为 这 个 串口 设备 设置 权限 ， 这 样 才能 为 后 续 的 读 写 操作 提 
供 可 能 。 命 令 如 下 : 


#adb shell 
# chomd 777 /dev/ttyS2 


(3) 到 这 一 步 ， 串 口 已 经 基本 可 用 。 读 者 可 以 写 个 应 用 程序 来 测 
试 下 ， 或 者 下 载 著名 的 开源 项 目 ser ial-port-api 程序 
(http://code. google. com/p/android-serialport-api/) 来 进行 测 
试 。 它 的 主 青 面 如 图 25-3 所 示 。 





Loopback 
Quit 


AKW25-3 主 界 面 
这 样 我 们 就 成 功 地 在 Android 模 拟 器 中 添加 了 串口 功能 ， 并 且 经 过 


测试 验证 和 真实 设备 的 串口 操作 没有 任何 区 别 。 读 者 如 果 还 有 其 他 需 
求 ， 也 可 以 参照 本 市 讲解 的 方法 来 尝试 “改造 ”Android 模 拟 器 。 





25.2 此 Android 非 彼 Android 


个 工具 取 名 为 “Android” 并 不 是 很 恰当 ， 既 会 引起 误解 ， 也 没 
M e 余 。 它 的 主要 功能 有 3 个 ， 即 : 


e 管理 AVD (Android Virtual Devices) ; 
e 管理 Andtoid 项 目 ; 
e 管理 Android SDK 平台、 插件、 文档 等 。 


no HB 


已 是 一 个 命令 行程 序 ， 语 法 如 下 : 





android [global options] action [action options] 


如 果 是 在 Eclipse 下 开发 ，ADT 本 身 已 经 集成 了 “Android” 这 个 工 
具 的 功能 ， 因 此 开发 者 一 般 情况 下 不 需要 直接 通过 命令 行 的 形式 来 操 


我 们 来 看 看 它 的 常见 用 法 。 
(1) 全 局 选项 如 表 25-16 所 示 。 


表 25-16 全 局 选项 


Verbose 模 式 ， 即 无 论 error，warning 或 者 information 信 
居 都 会 输出 





(2) 管理 AVD 和 SDK 如 表 25-17 所 示 。 


表 25-17 管理 AVD 和 SDK 





bva | 
bak | __JnaispKina 


create AVD 的 名 称 
avd 


使 用 ID 为 targetID 的 系统 映像 文件 。 获 取 可 
用 的 ID 列表 ， 可 以 用 “android list targets”. 
一 般 的 列表 格式 如 下 : 

id: 1 or "android-3" 

Name: Android 1.5 


p Type: Platform 


<targetID> 


API level: 3 

Revision: 4 

Skins: HVGA (default), HVGA-L, HVGA- 
create P, QVGA-L、QVGA-P 
avd ABIs : armeabi 





re <path>| | 设置 sD 卡 的 映像 文件 或 者 新 建 一 个 容量 
[KIM] size 的 SD 卡 

强制 生成 AVD 

Lp <path> | 此 AVD 相 关 文 件 的 存放 路 径 


-s <name>| 
<width>- ”此 AVD 使 用 的 皮肤 文件 
<height> 
elete 删除 指定 的 AVD 
avd 


[n <name> | 需要 移动 的 AVD 名 称 
move 
avd 








E 


目标 路 径 


r< s i 
rsnew- | 为 AVD 重 新 命名 
name> 











+ le <name> [NiaAvD | 
avd 


(3) 管理 项 目 如 表 25-18 所 示 。 


表 25-18 管理 项 目 





-t <targetID> 同 “create avd” 一 样 


-n <name> 需要 更 新 的 项 目 名 称 
| 
| -l <library path> 











需要 添加 的 库 的 存放 路 径 


人 
-s <subprojects> “| 更 新 子 目录 下 的 项 目 
| -t <targetID> 同 创建 时 的 选项 


| 1 | | 


i 5 
A A 
5 5 
= = 
= = 
V V 

X 





(4) 为 AVD 添 加 硬件 支持 。 


ER AREN AAT, RII Re Fe Se FF EB HI BAY SH 


列表 给 出 了 AVD 所 有 支持 的 硬件 属性 ， 开 发 者 可 以 在 AVD 目 录 下 的 
config. ini 文 件 中 添加 相应 属性 的 赋值 语句 如 表 25-19 所 示 。 


表 25-19 ”AVD 目 录 下 的 config. ini 文 件 中 添加 相应 属性 


内 存 hw.ramSize 





hw.touchScreen 






DPad (Directional 
pad) 通常 用 于 游戏 控 hw.dPad 


以 下 


| 
5 
只 


GSM modem hw.gsmModem 
iii = E : 


摄像 头 水 平方 向 最 大 
像素 





hw.accelerometer 








| La as 
音频 录制 hw.audioInpnut 


音频 回放 hw.audioOutput 


e 


Cache 分 区 disk.cachePartition 


Cache 分 区 大 小 disk.cachePartition.size 


(density ) — | 








25.3 快速 建立 与 模拟 器 或 真 机 的 通信 渠道 一 一 ADB 


ADB (Android Debug Bridge) 可 以 让 研发 人 员 快 速 建立 与 模拟 器 
或 真 机 的 通信 渠道 。 正 如 其 名 称 所 表示 的 ， 它 是 一 座 调试 的 桥梁 一 并 
且 基 于 命令 行 格式 。 


25. 3.1 ADB 的 使 用 方法 


对 于 一 般 的 开发 者 而 言 ，ADB 是 一 个 可 执行 程序 ， 位 于 SDK 安 装 路 径 
下 的 platform-tools 目 录 中 。 它 的 安装 也 非常 简单 用 户 只 要 下 载 
Android 的 SDK 即 可 。 当 然 ， 如 果 和 希望 在 任何 地 方 都 可 以 调用 到 ADB， 那 
么 可 以 考虑 将 它 的 存储 路 径 加 入 系统 Path 中 。 


如 果 是 在 Eclipse 开发 环境 下 ， 甚 至 不 用 直接 接触 到 具体 的 ADB 命 
令 。 因 为 Android 的 ADT 工 具 已 经 内 部 集成 了 对 ADB 的 调用 。 比 如 只 需要 
在 Eclipse 下 通过 单 击 工程 右键 ， 然 后 选择 “Run as-> Android 
Application” 来 将 应 用 程序 安装 到 指定 的 目标 设备 中 ， 而 不 必 杀 自 调 
用 ADB 的 “应 用 程序 安装 命令 ”。 


接 下 来 我 们 介绍 ADB 中 常用 的 一 些 命令 ， 通 用 格式 如 下 所 示 : 
adb[-d|-e|-s <serialNumber>]<command> 


因为 ADB 是 一 种 多 对 多 的 架构 〈 多 个 ADB Client 以 及 多 个 目标 设 
备 ， 下 一 小 节 有 详细 讲解 ) ， 所 以 在 使 用 ADB 命 令 时 ， 需 要 特别 指定 我 
们 所 针对 的 目标 对 象 。 如 果 不 清 楚 设 备 对 应 的 “serialNumber”， 可 以 
先 执行 如 下 查询 命令 : 


adb devices 


这 样 就 可 以 得 到 当前 所 有 目标 设备 的 状态 了 ， 如 下 所 示 。 





C:\Documents and Settings\Administrator>adhb devices 


List of devices attached 
emulator—5554 device 


emulator—5556 device 





[serialNumber ][state] 


其 中 serialNumber 又 由 “类 型 ”和 “端口 号 ”组 成 ， 以 “-” 隔 
FF; State 则 有 两 种 状态 ， 即 : 
e Offline. 说 明 当 前 设备 没有 连接 或 无 响应 。 
e Device. 说 明 当 前 设备 已 经 和 ADB Servet 正 常 连接 。 


比如 上 面 的 例子 中 共 展 示 了 两 个 模拟 器 设备 (emulator) ， 端 口号 
分 别 为 5554 和 5556， 而 且 都 处 于 正常 连接 状态 。 


接 下 来 就 可 以 向 指定 设备 发 送 ADB 命 令 了 。 如 下 所 示 是 我 们 通过 ADB 
在 emulator-5556 上 安装 一 个 APK 应 用 程序 的 命令 。 

















C:\Documents and Settings\Administrator>adb -s emulator-5556 install C:\AutoTest 
_Ex@2_Calculator.apk 
56 KB/s (42878 bytes in @.828s) 


pkg: /data/local/tmp/fAutoTest_Ex@2_Calculator.apk 
Success 





表 25-20 是 对 ADB 常 用 命令 的 释义 ， 更 多 详情 可 以 参见 官 万 文档 。 


3225-20 ”ADB 重 要 命令 一 览 表 


所 属 类 A 、、 
型 
只 将 adb 命 令 发 送 
给 唯一 的 USB 连 接 
设备 
k | 








会 返回 错误 


只 将 adb 命 令 发 送 | 如 果 当 前 运行 
给 当前 唯一 运行 的 | 的 模拟 器 实例 





备 。 比 如 前 一 个 例 
子 中 指定 在 
emulator-5556 上 安 


显示 adb 的 帮助 信 
E 
Bs adhtt = 
logcat [<option>] | 将 log 信 息 打 印 到 屏 
[<filter-specs>] 幕 上 
将 dumpsys， 
Debug |bugreport dumpstate 和 logcat 
信息 打印 到 屏幕 上 
显示 可 用 的 JDWP 
He 





将 指定 路 径 下 的 应 
install <path-to- “用 程序 安装 到 模拟 
apk> 器 或 者 设备 中 。 可 


connect <host>[: MEX 

<port>] i 

disconnect [<host> 汤 开 与 目标 设备 的 
[:<port>]] TCP/IP 连 接 





host 代 表 目 标 设 
备 的 也 地 址 ， 


port 是 端口 号 


将 模拟 器 或 设备 上 
的 指定 文件 复制 到 
pull <remote> 开发 环境 机 器 上 
(Adb Client 和 
Server 所 处 的 环 


push <local> 
<remote> 


get-serialno 


get-state 


这 个 命令 用 来 检查 
adb server 是 否 正 在 
start-server 运行 ， 如 果 没 有 ， 
会 将 其 启动 
= 这 个 命令 用 来 启动 
一 个 shell 环 境 
和 上 面 不 同 的 是 ， 
这 个 命令 会 直接 执 


结束 后 便 会 
退出 shell 环 境 


参见 表格 后 面 


的 注解 1 








注解 : 这 个 选项 通常 放置 在 ADB 命 令 前 面 ， 表 示 此 命令 会 一 直 等 
待 ， 直 到 其 针对 的 目标 设备 处 于 可 用 状态 。 比 如 下 面 这 个 例子 : 


adb wait-for-device shell getprop 


在 使 用 这 个 选项 时 ， 有 一 点 读者 应 该 特别 注意 一 一 对 于 那些 需要 在 
设备 完全 启动 的 状况 下 才能 成 功 执行 的 adb 命 令 ， 这 个 选项 可 能 会 不 起 
作用 。 比 如 我 们 之 前 提 到 的 安 洲 应 用 程序 的 命令 ， 如 果 系 统 在 还 没有 局 
动 完成 前 adb 命 令 就 开始 执行 ， 那 么 安装 任务 很 可 能 会 失败 。 


一 般 情况 下 ， 开 发 人 员 通 过 USB 线 将 研发 机 (PC) 与 目标 设备 进行 
连接 ， 然 后 就 可 以 通过 ADB 向 目标 设备 发 送 各 种 命令 了 。 但 这 并 不 代表 
ADB 只 能 通过 USB 连 接 一 一 比如 它 也 支持 TCP/1P 网 络 的 互联 方式 。 下 面 我 
们 就 举例 说 明 如 何 通 过 WiFi 来 实现 ADB 的 连接 ， 如 图 25-4 所 示 。 


ae: 






connect host: port 


全 图 25-4 通过 Wi-Fi 连 接 ADB 


。 要 实现 研发 机 与 目标 设备 的 TCP/IP 连 接 ， 首 先 要 保证 它们 是 可 以 
通过 网 络 互 相 访 问 的 (一 般 情 况 下 ， 需 要 两 者 处 在 同一 个 网 络 环境 
中 ， 如 局 域 网 ) 。 

。 将 目标 设备 设置 为 TCP/ZP 监 听 状 态 。 可 以 执行 以 下 命令 来 完成 这 
一 设置 (此 时 研发 机 与 目标 设备 还 是 需要 通过 USB 和 连接 ， 否 则 无 法 
发 送 ADB 命 令 ) : 











adb tcpip <port> 


命令 中 的 port 指 定 了 目标 设备 将 在 哪个 端口 进行 监听 ， 因 而 后 续 的 
连接 命令 要 和 这 里 的 端口 设置 保持 一 致 才能 成 功 。 


。 拔除 目标 设备 与 研发 机 的 USB 连 接 ， 为 下 面 的 “无 线 连 接 BOE 
备 。 








。 此 时 目标 设备 已 经 在 指定 的 端口 进行 监听 (IP 地 址 通常 Re 
由 器 自动 分 配 的 ， 我 们 不 能 指定 ) 了 ， 研 发 机 可 以 通过 如 下 命令 与 
设备 实现 WiFi 互 联 : 


adb connect <host>[:<port>] 


其 中 ，host 是 目标 机 的 ip 地 址 ， 而 port 就 是 上 面 tcpip 命 令 设 置 的 
监听 端口 。 


。 通过 以 上 几 个 步骤 ， 研 发 机 中 的 ADBSetrver 和 目标 设备 上 的 
ADBD ( 见 下 面 小 节 的 分 析 ) 就 实现 了 TCP/IP 的 连接 。 此 时 如 果 打 
开 Eclipse 中 的 DDMS， 就 可 以 发 现 目标 机 已 经 处 于 online 状 态 。 后 续 
操作 和 USB 和 连接 时 的 情况 没有 任何 差别 。 





25.3.2 ADB 的 组 成 元 素 


ADB 虽 然 采 用 的 是 客户 端 /服务 器 模型 ， 但 与 普 eae 
大 的 区 别 ， 即 它 的 框架 中 包含 了 3 个 重要 组 成 部 分 


e ADB Client 


ADB 客 户 端 运行 在 研发 机 (PC) 设备 上 。 比 如 我 们 在 Windows 操 作 系 
统 下 的 Eclipse 中 进行 开发 ， 那 么 ADB Client 就 运行 在 Wi ndows 环 境 中 。 


e ADB Server 


和 CS 模型 中 的 理解 不 同 ，ADB 的 服务 端 程序 和 客户 端 一 样 ， 都 运行 
于 研发 机 设备 上 。 这 是 因为 ADB Server 主 要 有 两 方面 的 任务 。 


其 一 ， 管 理 研 发 机 设备 与 目标 设备 /模拟 器 的 连接 状态 一 一 这 两 者 
是 “多 对 多 ”的 关系 ， 所 以 需要 有 一 个 “管理 者 ”。 


其 二 ， 处 理 ADB Client 的 连接 请 求 。 
e ADB Daemon 


Daemon 作为 后 台 进 程 运行 在 目标 设备 /模拟 器 中 。 它 将 与 ADB 
Server 进 行 通 信 连 接 以 完成 一 系列 ADB 的 命令 请 求 。 


如 图 25-5 所 示 o 


Emulator/Device 
Development Environment 


Emulator/Device 


va Emulator/Device 


ADB Daemon 
Y f 
ADB Server 





全 图 25-5 ADB Client、Server 和 Daemon 示 意图 


当 用 户 需要 发 送 ADB 命 令 时 ， 将 首先 局 动 一 个 ADB Client。 随 后 ADB 
会 检查 Server 程 序 是 否 已 经 在 运行 ， 否 则 它 还 会 局 动 Server 。ADB 
Server 将 绑 定 在 TCP 的 5037 端 口上 并 开始 等 待 客户 端 程序 的 连接 。 

另外 ，ADB Server 也 会 主动 扫描 有 效 的 模拟 器 /设备 。 扫 描 所 用 的 
端口 范围 是 5555 一 5585 的 奇数 号 一 一 读者 可 能 会 奇怪 为 什么 只 用 到 奇数 
号 。 这 是 因为 每 一 个 模拟 器 /设备 都 需要 用 到 两 个 端口 号 ， 分 别 用 于 
console 和 adb 的 连接 。 举 个 例子 ， 如 果 一 个 emulator 已 经 和 ADB Server 
建立 了 连接 ， 那 么 下 一 个 emulator 分 配 到 的 端口 号 就 如 表 25-21 所 示 。 


表 25-21 emulator 分 配 到 的 端口 号 


用 途 


这 样 就 有 效 保证 了 多 个 目标 设备 的 同时 运行 和 管理 。 





25.3.3 ADB 源 代码 解析 


ADB 源 代码 在 Android 工 程 目录 下 的 /system/core/adb/ 中 。 从 前 面 
小 节 的 分 析 中 我 们 知道 ADB 是 由 3 部 分 元 素 组 成 的 ， 即 ADB Client、 
Server 和 Daemon。 但 从 源 代码 的 角度 来 分 析 ，ADB 的 设计 者 并 没有 将 这 3 
个 元 素 的 源 文件 单独 分 隔 开 来 一 一 而 是 采用 了 包括 宏 在 内 的 巧妙 方式 来 
区 分 它们 。 这 在 一 定 程度 上 加 大 了 我 们 | 阅读 源 代码 的 难度 。 为 了 更 好 地 
理解 每 一 组 成 部 分 ， 读 者 可 以 先 从 ADB 的 makefile 文 件 入 手 ， 了 解 各 个 
模块 所 对 应 的 源 文件 一 一 对 于 ADB makefi le 的 详细 分 析 我 们 其 实在 本 书 
基础 篇 中 已 经 提前 讲解 了 ， 不 清楚 的 读者 可 以 回头 复习 。 


表 25-22 直 接 给 出 了 各 模块 所 对 应 的 源 文 件 。 
表 25-22 ”各 模块 所 对 应 的 源 文件 


NT 


| 模 块 名 | 


ADB Host 
(ADB Client/ADB 


Server ) 





‚Adb Daemon 


Adb Daemon 


源 文件 列表 

adb.c 

console.c 

transport.c 

transport_local.c 

transport_usb.c 

commandline.c 

adb_client.c 

adb_auth_host.c 

sockets.c 

services.c 

ile_sync_client.c 

$(EXTRA_SRCS)， 与 操作 系统 环境 
有 关 

(USB_SRCS)， 与 操作 系统 环境 有 关 


utils.c 


FP 


usb_vendors.c 
adb.c 
ackup_service.c 
devent.c 
transport.c 
transport_local.c 
transport_usb.c 
sockets.c 


Services.c 


= 


ile_sync_service.c 
jdwp_service.c 
ramebuffer_service.c 
remount_service.c 
usb_linux_client.c 


llog_service.c | 


由 表 可 知 ，3 个 组 成 元 素 在 很 大 程度 上 复 用 了 代码 。 
接 下 来 我 们 以 ADB 的 主 函 数 为 入 口 来 分 析 其 内 部 源码 实现 。 


ADB Client，Server 和 Daemon 的 main 函 数 都 在 adb. c 中 。 源 代码 如 
下 : 


int main(int argc, char **argv) 
{ 
#if ADB_HOST// 通 过 这 个 宏 来 区 分 ADB Host 和 Daemon 
adb_sysdeps_init(); 
adb_trace_init(); 
D( "Handling commandline()\n"); 
return adb_commandline(argc - 1, argv + 1); 
#else 
adb_qemu_trace_init(); 
if((argce > 1) && (!strcmp(argv[1],"recovery"))) { 
adb_device_banner = "recovery"; 
recovery_mode = 1; 


start_device_log(); 

D( "Handling main()\n"); 

return adb_main(0, DEFAULT_ADB_PORT); 
#endif 


J 


从 上 面 这 段 代 码 可 以 看 出 ， ADB 的 主 函 数 将 通过 ADB_ HOST 宏 来 判断 
当前 程序 是 ADB Host 或 者 ADB Daemon 这 就 意 际 着 ADB_ HOST 在 编译 时 
会 有 所 区 别 。 对 于 ADB Host, makefi le 中 加 入 了 额外 译 选 项 。 如 下 
所 示 : 

LOCAL_CFLAGS += -02 -g -DADB HOST=1 -Wall -Wno-unused-parameter 


LOCAL_CFLAGS += -D_XOPEN_SOURCE -D_GNU_SOURCE 
LOCAL_MODULE := adb 


而 对 于 ADB Daemon， 这 个 宏 定义 发 生 了 变化 。 


LOCAL_CFLAGS := -02 -g -DADB_HOST=0 -Wall -Wno-unused-parameter 
LOCAL_CFLAGS += -D_XOPEN_SOURCE -D_GNU_SOURCE 











可 见 当 ADB_H0ST 为 1 时 ， 代 表 ADB Host; 否则 为 0 时 ， 表 示 ADB 
Daemon。 以 下 两 个 小 节 我 们 将 分 别 分 析 在 这 个 宏 区 分 下 的 ADB Host 和 
ADB Daemon。 


1. ADB Host 源 码 解析 


本 小 节 我 们 选择 一 条 具体 的 ADB 命 令 来 完整 解析 它 的 实现 过 程 一 
同时 也 是 本 书 自动 化 测试 篇 中 将 会 用 到 的 一 个 重要 命令 。 如 下 所 示 : 


$ adb shell am instrument com.ThinkingInAndroid.AutoTest/android. 
(1) ADB 命 令 的 典型 处 理 流程 。 


et i one 
并 承载 如 下 测试 包 的 运 


com. ThinkingInAndroid.AutoTest 


其 流程 如 图 25-6 所 示 。 








Main sat 调用 Adb connect (1) 


KET-NI 


f 






adb commandlin (7 










ARSE C 


§ 


Interactive shell 








TANE: 






Eiana | 


EAM sever E Hi shell > 属 


4525-6 流程 图 
O 关于 main 国 数 我 们 前 一 个 小 节 已 经 做 过 分 析 了 。 
D 如 果 是 ADB Host, ASAmainey AIFS Aadb_ command! ine 来 解 


析 用 户 要 求 执行 的 命令 。 也 就 是 说 ，ADB Host 与 用 户 的 交互 接口 就 是 一 








© f£adb_command| ines RF, BAS -LSSVSHTMe, 
如 ADB Server 的 端口 号 ， 便 是 在 这 里 通过 读 取 环境 变量 
ANDROID ADB SERVER _PORT 得 到 的 。 


© 前 置 标志 为 当前 命令 的 运行 提供 了 限定 条 件 ， 如 我 们 之 前 所 看 
到 的 -d，-e 将 在 这 一 步 进行 解析 。 另 外 ， 到 目前 为 止 我 们 只 知道 可 以 通 
过 ADB_HOST 来 区 分 Host 和 Daemon， 而 Host 中 其 实 同 时 包含 了 Client 和 
Server， 它 们 又 是 如 何 区 别 的 呢 ? 


事实 上 ，ADB Server 是 由 程序 自动 启动 的 即 如 果 主 函数 的 
argv[0] 中 带 有 “server” 或 者 “fork-server” 人 参数 (这 是 ADB Client 
用 于 旷 化 ADB Server 的 特殊 标志 ) ， 那 么 变量 is_daemon 将 被 置 1 这 
将 在 下 一 个 步骤 中 产生 影响 。 


© 根据 上 述 的 参数 解析 结果 ， 程 序 会 判断 是 否 要 局 动 ADB 
Server: 如 果 是 最 终 调 用 launch_server。 后 者 则 负责 局 动 Server， 关 
键 语句 〈Windows 操 作 系 统 中 ) 如 下 : 


ret = CreateProcess(program_path, /* program path */ 

"adb fork-server server",/* the fork-server argument ' 
debug = 2 in the child*/ 

NULL, /* process handle is not inheritable */ 
NULL, /* thread handle is not inheritable */ 
TRUE, /* yes, inherit some handles */ 
DETACHED_PROCESS, /* the new process doesn't have a c 
NULL, /* use parent's environment block */ 
NULL, /* use parent's starting directory */ 
&startup, /* startup info, i.e. std handles */ 
&pinfo ); 


读者 可 以 自行 理解 函数 各 参数 的 含义 ， 然 后 体会 下 这 种 设计 的 巧妙 
Zs 

© 到 了 这 一 步 ， 才 真正 开始 处 理 我 们 的 “she11” 请 求 
几 个 步骤 都 是 围绕 这 个 请 求 展开 的 。 


D 如 果 用 户 的 命令 是 "adb she11"， 即 不 带 任何 参数 的 情况 ， 那 么 
将 启动 一 个 交互 式 的 shel1 环 境 。 如 下 所 示 : 











后 面 的 


C:\Documents and Settings\Administrator>adb shell 


root@generic:/ # 





否则 程序 会 直接 执行 用 户 指定 的 she1l1 指 令 ， 而 不 提供 交互 环境 。 
比如 这 个 例子 中 ， 对 应 的 she11 指 令 是 : 


"am instrument 
com. ThinkinglnAndroid. AutoTest/android. test. Instrumentat ionTesi 


么 当 指 令 完 成 以 后 ，ADB 将 自动 退出 she11 环 境 。 


I 这 一 步 就 是 创建 交互 式 she11 环 境 的 地 方 ， 在 这 个 例子 中 不 会 执 
行 到 。 

© 在 连接 ADB Server 之 前 ， 程 序 会 对 “已 经 处 理 过 ”和 “未 处 
理 ” 的 参数 进行 整理 。 另 外 ， 为 了 把 这 几 个 参数 合并 为 一 个 有 效 的 字符 
串 ， 参 数 中 包含 空格 的 地 方 还 需要 加 上 引号 。 


将 上 一 步 得 到 的 参数 传 入 adb_connect 
情 比较 多 ， 我 们 接 下 来 专门 进行 讨论 。 


(2) 涵 数 adb_connect 的 处 理 流程 。 
图 25-7 描 述 了 adb_connect 的 整体 调用 流程 。 
GD adb_connect 函 数 开始 执行 。 


D 先 查 询 当 前 ADB Server 的 版 本 号 。 目 的 有 两 个 ， 即 获知 当前 是 
否 有 Server 在 运行 ， 以 及 它 的 版 本 号 是 否 符合 要 求 〈 见 下 面 第 4 步 ) 。 


© 对 上 一 步 的 结果 进行 判断 。 


@ 如 果 成 功 查 询 到 当前 Server 的 版 本 ， 说 明 ADB Server 已 经 启 
动 。 这 时 还 应 进一步 检查 它 的 版 本 号 是 否 符合 要 求 。 


©) 如果 当前 正在 运行 的 ADB Server 版 本 不 符合 要 求 ， 将 会 被 系统 
强行 结束 并 重新 启动 。 流 程 和 下 面 的 第 6 步 是 一 样 的 ， 因 此 在 代码 实现 
中 直接 用 goto 语 名 进行 了 跳 转 。 如 果 ADB Server 的 版 本 号 也 通过 了 检 
查 ， 那 么 程序 将 直接 进入 第 7 步 。 





这 个 函数 要 处 理 的 事 





adb connect 






_adb_connect (“host:version") £5 


不 
wi 


adb connect (service) M 


socket loopback client Ø 







Server 版 本 是 1 
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_adb_ connect ("host:kill") £ 








写 入 命令 大 / 
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aS 
am 





全 图 25-7 adb_connect 的 整体 调用 流程 图 


© 启动 一 个 ADB Server 。 不 同 操作 系统 环境 下 的 实现 略 有 差异 ， 
所 以 源码 中 使 用 了 宏 来 进行 区 别 控制 。 我 们 以 Linux 环 境 为 例 来 简 述 
下 。 


。 建立 一 个 通道 ， 这 样 父子 进程 才能 进行 通信 。 

。 Fotk 一 个 新 进程 。 我 们 知道 ， 通 过 Linux 的 fotk 接 口 “ 铸 出 ”的 新 进 
程 程序 执行 点 和 原先 进程 完全 一 样 。 因 此 代码 中 需要 通过 判断 进程 
号 来 区 分 父子 进程 一 一 当 pid 为 0 时 ， yer 前 是 子 进 程 ; 否则 便 是 
父 进程 。 如 果 读 者 对 这 些 基础 知识 不 是 很 熟悉 ， 建 议 查 阅 Linux 相 
关 资 料 。 


相关 源码 实现 如 下 : 


if (pid == 0) {//Child 进 程 (也 就 是 被 fork 出 来 的 ADB Server 所 在 进程 ) 
adb_close(fd[0]); 
dup2(fd[1], STDERR_FILENO); 
adb_close(fd[1]); 
char str_port[30]; 
snprintf(str_port, sizeof(str_port), "%d", server_port); 
int result = execl(path, "adb", "-P", str_port, "fork-ser 
fprintf(stderr, "OOPS! execl returned %d, errno: %d\n", r 
} else {//Parent 进 程 ， 也 就 是 ADB Client 所 在 进程 


ADB Server 运 行 于 子 进程 中 。 因 此 上 述 代 码 段 中 pid 为 0 的 分 支 
en eae tis 同时 读者 会 发 现 它 其 实 还 是 复 用 
了 adb 的 程序 主体 ， 只 是 函 数 参 数 变 成 了 “fork- 
server” 和 “server”。 我 们 在 前 面 已 经 讲解 过 这 两 个 特殊 标志 的 含 
义 ， 应 们 将 在 sdb comandi ine 中 被 用 于 判断 当前 是 否 为 Server 进 程 。 


对 于 ADB 中 代码 的 高 度 复 用 ， 我 们 可 以 打 一 个 比方 一 一 ADB 程 序 就 像 
一 把 瑞士 军刀 ， 无 论 用 户 希 望 使 用 的 是 小 刀 、 叉 子 甚至 圆珠笔 、 镖 
子 等 ， 都 只 需 通 过 传 入 相应 的 参 数 来 轻松 得 到 。 

D 一 旦 ADB Server 启 动 后 ，ADB Client 就 可 以 开始 连接 它 了 。 


socket_loopback _ client( adb server_port, 


SOCK STREAM) 。 这 里 会 尝试 连接 127. 0. 0. 1 本 机 地 址 的 ADB Server 端 
口 。 即 向 ADB Server 发 起 连接 请 求 。 


© 判断 和 ADB Server 的 连接 是 否 已 经 成 功 。 
未 能 成 功 连 接 ADB Server， 任 务 失 败 。 


M 如 果 和 ADB Server 连 接 成 功 ， 我 们 就 可 以 向 其 发 送 数据 了 
a 然后 才 是 命令 数据 本 





D 如 果 传 送 命令 大 小 成 功 ， 这 里 将 接着 传输 命令 数据 。 在 本 例 
中 ， 对 应 的 是 "shell:am instrument 
com. ThinkinglnAndroid. AutoTest/android. test. Instrumentat ionTesi 


O 完成 上 两 步 操作 后 ， 就 可 以 通过 Server 的 返回 值 来 判断 命令 是 
否 执行 成 功 。 实 际 工 作 由 Adb_status 完 成 当 Server 返 回 值 
为 "0KAY" 时 ， 表 示 成 功 ; 返回 值 为 "FAIL" 时 ， 表 示 失 败 。 


流程 结束 。 
2. ADB Daemon 


我 们 知道 adbd 程 序 运行 于 目标 设备 端 〈 模 拟 器 或 真实 设备 ) , MA 
它 是 在 什么 情况 下 启动 的 呢 ? 


先 来 看 看 init. rc 中 关于 adbd 的 描述 : 


# adbd is controlled via property triggers in init.<platform>.usb 
service adbd /sbin/adbd 

class core 

socket adbd stream 660 system system 
disabled 

seclabel u:r:adbd:s0 





# adbd on at boot in emulator 模 拟 器 的 情况 下 
on property:ro.kernel.qemu=1 
start adbd 


可 见 根据 当前 是 模拟 器 或 者 真实 设备 ， 启 动 adbd 的 条 件 有 所 区 别 。 
本 书 的 原理 篇 中 对 init. rc 的 语法 规则 有 详细 分 析 一 一 如 果 读 者 对 语法 





不 是 很 清楚 ， 可 以 先 回 头 阅读 再 来 分 析 上 述 这 段 内 容 。 


“Service” 说 明 adbd 是 一 种 可 执行 的 服务 程序 ， 其 存储 路 径 在 文 
件 系统 中 的 /sbin/adbd。 后 面 紧 跟 的 disabled 选 项 告诉 系统 ， 不 要 在 这 
里 直接 启动 它 init. rc 文件 的 其 他 地 方 会 去 显示 调用 这 个 服务 。 


如 果 是 模拟 器 的 情况 下 〈 即 property:ro. kernel. qemu=1) ， 那 么 
将 直接 start adbd。 


FI, ADB Daemon 与 前 一 小 节 ADB Host 的 内 部 源码 结构 类 似 ， 有 兴 
趣 的 读者 可 以 自行 研究 。 我 们 将 在 下 一 小 节 中 重点 讲解 Daemon 和 Host 间 
的 通信 协议 。 


Sy 





25.3.4 ADB Protocol 


Protocol 是 事物 之 间 沟 通 的 桥梁 。 无 论 是 在 工程 技术 领域 还 是 日 常 
生活 中 ， 无 时 无 刻 都 充满 了 协议 的 束缚 一 一 有 的 是 人 为 强制 规定 的 ， 如 
3GPP 组 织 给 出 的 全 球 性 的 通信 协议 ; 有 的 则 是 约定 俗 成 的 ， 如 顾客 在 起 
市 买 东西 ， 都 是 先 付款 后 才能 把 货物 带 走 ， 这 就 是 顾客 与 店家 的 隐 含 协 
议 。 


ADB 程 序 本 身 并 不 复杂 ， 但 “及 心 虽 小 ， 五 脏 俱全 ”， 所 以 它 也 加 
入 了 严格 的 协议 规范 。 具 体 而 言 分 为 两 部 分 ， 即 : 


e ADB Client 与 ADB Server 间 的 通信 协议 ; 
e 以 及 ADB Server 与 ADB Daemon 间 的 通信 协议 。 


下 面 我 们 逐一 讲解 。 
1. ADB Client <- -> ADB Server 


ADB 协 议 的 初衷 就 是 让 Server 能 响应 Client 的 各 种 请 求 ， 而 Client 
也 能 正确 识别 请 求 的 执行 结果 。 


从 Client 的 角度 来 看 ， 它 向 Server 发 送 请 求 的 流程 如 图 25-8 所 示 。 


e ADB Client 需要 先 通过 本 机 IP 地 址 (127.0.0.1) 的 5037 端 口 (注意 : 
ADB Servetr 的 默认 监听 端口 是 5037， 不 过 用 户 也 可 以 通过 设置 


ANDROID_ADB_ SERVER_PORT WÁ MX) , 35 ADB Server 

。 连接 成 功 后 ， 首 先 发 送 数据 的 大 小 〈 用 4 个 字 节 表示 ， 并 且 为 十 六 
Hl) 。 比 如 我 们 希望 通过 “hostvetsion ”来 查询 版 本 号 ， 那 么 它 
的 数据 大 小 就 是 “000C” 。 

。 传送 真正 的 数据 内 容 ， 如 上 一 步 所 说 的 “hostvetsion o 














对 于 Server 来 说 ， 它 响应 Client 的 过 程 如 图 25-9 所 示 。 


ADB Client ADB Server 
连接 tcp:localhost:5037 


数据 大 小 4 字 节 ，16 进 制 ) 





全 图 25-8 ADB Client 向 Server 发 起 请 求 


ADB Client ADB Server 
成 功 的 情况 : “OKAY” 


失败 的 情况 : “FAIL” 





特殊 情况 : 版 本 号 


A 25-9 ADB Setrvet 响 应 ADB Client 的 请 求 


。 如 果 请 求 被 成 功 执行 ，Servet 将 向 ADB Clientik H “OKAY” 。 

。 否则 当 有 错误 发 生 时 ，ADRB Client 将 收 到 ADB Server 发 送 
的 “FAIL”。 

© 有 一 个 特殊 的 情况 ， 就 是 当 我 们 查询 版 本 号 时 ，Server 将 直接 返回 
一 个 4 字 节 、 十 六 进 制 的 数值 来 表示 版 本 号 。 


ADB Client 和 Server 间 目前 支持 的 协议 请 求 并 不 多 ， 我 们 在 表 25- 
23 中 做 统一 解释 。 


表 25-23 ADB Client 与 Server 间 的 协议 释义 


Service 类 别 请 R È 


向 ADB Server 查 询 内 部 版 
eo es 
za TH OKAY Bk FAIL 
host:version ie ~ 是 、 
个 4 字 节 、 十 六 进 制 表示 的 
版 本 号 
请 求 ADB Server 程 序 退 
出 。 这 通常 是 因为 Client 检 
测 到 当前 正在 运行 的 Server 
host:kill 不 符合 要 求 ， 因 此 强制 要 
求 其 退出 (比如 Server 的 版 
本 号 过 老 ， 就 可 能 发 生 这 
种 情况 ) 
[=] ADB Server 查 询 当 前 可 
用 的 Android 设 备 列表 以 及 
它们 的 状态 。 
ADB Server 首 先 会 回应 碍 
询 是 否 成 功 COKAY 或 者 
FAIL) 。 在 OKAY 的 情况 
i: 随后 将 发 送 一 个 4 字 
节 、 十 六 进 制 的 数据 大 小 
说 明 ， 最 后 才 是 具体 的 数 












ee 





Host Service 
(Host Service, Æ 
75 ADB Server & 


host:devices ti. ADB Client 收 到 后 进 
LE ater 
值得 一 提 的 是 ， 当 列表 传 
输 结 束 后 ，ADB Client 和 
Server 则 的 连接 将 会 终止 。 
这 和 下 面 的 命令 有 本 质 的 
区 别 





这 个 命令 是 host:devices 的 
升级 版 。 它 们 完成 的 功能 
是 一 样 的 ， 区 别 在 于 
host:track- devices 在 传送 完 
列表 后 ， 并 不 终止 客户 与 
host:track- 端的 连接 。 
devices 这 就 意味 着 当 这 些 设备 有 
变动 时 〔 添 加、 删除 
等 ) ，Server 会 主动 发 送 通 
知 给 ADB Client， 而 不 需 
要 客户 端 不 断 发 送 碍 询 才 
能 实时 跟踪 到 设备 状态 
这 个 查询 比较 特殊 ， 它 是 
在 有 新 的 模拟 器 启动 时 ， 
ates 发 送 给 ADB Server 的 ， 这 
po 样 Server 束 可 以 知道 一 个 新 
的 模拟 器 实例 启动 了 
这 个 命令 用 来 实现 我 们 之 
前 提 到 的 -s 选 项 。<serial- 
number> 用 来 区 分 各 
.1 ~ be 
<serial-number> o H 3 


host:emulator: 


host:transport: 





设备 之 上 的 ADB Daemon 上 


这 个 命令 用 来 实现 -4 选 
host:transport- |DO EAH ACIS BET 
USB 连 接 的 设备 上 。 如 果 


就 可 以 成 功 啊 应 ， jusb 当前 有 多 个 符合 条 件 的 设 










而 不 需要 与 具体 的 备 ， 命 令 将 失败 
Androidi T% 
eae nn nae 这 个 命令 用 来 实现 -e 选 项 ， 


. 将 数据 发 送 到 通过 TCP 连 
posttransport: | 接 的 模拟 器 上 。 如 果 当 前 
有 多 个 符合 条 什 的 模拟 
器 aes 命 ~ 令 将 失败 
当 没 有 指定 -s、-d、-e 中 的 
NN eee 
安 这 种 情况 处 
posttransport- | 送 给 任何 可 用 的 设备 /模拟 
y 器 ， 不 过 如 果 有 多 个 符合 
条 件 的 设备 /模拟 器 ， 将 会 
AIK 
这 个 命令 表示 Client 要 求 
ADB Server 针 对 某 指定 的 
(serial-number) 设备 进行 
查询 
这 个 命令 是 host-serial 的 变 
种 ， 表 示 请 求 的 目标 是 当 
前 唯一 通过 USB 进 行 连接 
的 设备 。 如 果 USB 连 接 的 
设备 不 存在 或 有 多 个 ， 这 
个 命令 将 失败 
这 个 命令 也 是 host-serial 的 
变种 ， 表 示 请 求 的 目标 是 
host-local:< 当前 唯一 的 模拟 器 实例 。 
request> 假如 没有 符合 要 求 的 模拟 
器 ， 或 者 有 多 个 实例 存 
fe HRS AIL 


<host- TET 
prefix>:get- serial number, $I% 


host-serial:< 
serial-number>: 








serialno 如 “emulator-5554”， 可 以 参 
考 我 们 之 前 的 描述 

<host- 以 字符 串 形式 返回 指定 设 

prefix>:get-statel| 备 的 状态 


请 求 ADB Server 将 local 的 

连接 转 为 ramote 所 指定 的 地 
其 中 ，<host-prefix> 可 

以 是 host-serial/host- 

usb/host-local/host 中 的 任何 

= 

<Local> 的 格式 有 : 

e@ tcp:<port> 

如 果 是 TCP 连 接 的 情况 

è local:<path> 

如 果 是 Unix Local Domain 

Socket 的 情况 

<Remote> 的 格式 有 : 

è tcp:<port> 

如 果 是 TCP 连 接 的 情况 

è local:<path> 

如 果 是 Unix Local Domain 

Socket 的 情况 

è jdwp:<pid> 

如 果 是 JDWP 线程 的 情况 

在 设备 的 shell 环 境 下 运行 

command 命 令 ， 并 返回 结 

果 或 者 错误 描述 。 其 后 的 

argl，arg2 需 要 以 空格 隔 

Ta 





<host- 
prefix>:forward: 
<local>: 
<remote> 


shell:command 
arg1 arg2 ... 





容 中 包 全 
三 将 此 参数 组 织 起 来 。 
这 个 命令 和 下 面 所 描述 的 


命令 类 似 





这 个 命令 用 来 实现 “adb 
shell*。 和 上 面 的 区 别 在 





于 ， 它 会 启动 一 个 交互 式 
的 shell 环 境 来 承载 用 户 的 
下 一 步 操作 


请 求 adbd 以 “可 读 可 写 ” 的 
模式 重新 挂 载 设备 文件 系 
统 ， 而 不 是 只 读 。 在 

做 “adb sync” 或 者 “adb 
push” 前 执行 这 个 命令 是 有 
必要 的 。 不 过 要 注意 在 某 
打开 设备 中 的 文件 ， 以 便 
于 ADB Client 进 行 读 / 写 操 
作 。 这 个 命令 通常 用 于 调 
试 ， 不 过 因为 权限 问题 ， 
并 不 是 所 有 设备 都 支持 。 
其 中 <path> 参 数 是 从 设备 
的 文件 系统 根 目录 开始 的 
全 路 径 


尝试 连接 本 机 上 的 tcp 
<port> žm H 
: : 党 试 去 连接 <server-name> 
<server-name> 上 器 上 的 tcp <port>%ig A 
Au 下、 E z z 
beins zN Unix Domain 
Socket 


localreserved: 
<path> 这 些 命令 是 上 面 local: 
localabstract: “<path> 的 变种 ， 通 常用 于 





dev:<path> 





= = D, 
A O aa 
go) CS 

O =} 

a ae 

V 


aa 
ie) 
as) 
A 
go) 
O 
= 
+ 
V 


<path> 其 他 Android 系 统 支持 的 
localfilesystem: lSocket 命 名 空间 
<path> 


= 





用 于 实现 “adb logcat”。 它 
用 于 打开 一 个 系统 的 
log:<name> log (dev/log/<name>) 并 


允许 Client 进 行 读 取 ， 权 限 


这 个 命令 用 于 获取 屏幕 截 

屏 并 将 数据 回 传 给 Client。 

Local Service 当 ADB Server 响 应 
了 “OKAY” 以 后 ， 它 会 接着 
传送 一 个 16 字 节 的 结构 
体 ， 定 义 如 下 : 
{ 
uint32_tdepth; //framebuffer 
的 深度 
人 uint32_tsize; //framebuffer 的 
“| 大 小 〈( 字 节 表 示 ) 

uint32_t width; 
//framebuffer 宽 
uint32_theight; //framebuffer 
| 可 





} 

在 当前 的 实现 中 ， 深 度 是 
16， 大 小 为 宽 \ 六 高 \*2。 
这 个 命令 需要 特殊 的 权限 


文 持 才能 完成 





这 个 命令 用 于 回 设 备 传送 
一 个 recovery 镜 像 。 
其 中 <size> 是 此 镜像 文件 的 
大 小 。 它 将 在 设备 中 做 如 
下 操作 : 
- 创建 一 个 /tmp/update 文 件 
- 读 取 文件 大 小 ， 然 后 读 取 
文件 内 容 写 入 上 面 创建 的 
recover:<size> 新 文件 中 
- 当 上 面 工 作 完 成 后 ， 将 创 
为 : /tmp/update.start。 
注意 : 此 命令 只 有 在 设备 
处 于 recovery 模 式 下 才 会 生 
效 ; 否则 /tmp 这 个 目录 是 


| EE SARE 
上 终止 
| i 连接 运行 于 <pid> 进 程 中 的 


这 个 命令 用 于 周期 性 地 发 


送 JDWP Pid 列 表 到 ADB 
Client. 


每 次 返回 的 数据 格式 如 
下 


必 <hex4>: 数据 的 大 小 ， 还 
rack-jdwp 是 以 4 字 节 、 十 六 进 制 表 
ZN o 


<content>: pid) RHR. 
每 个 pid 以 下 面 的 格式 表 
ZN: 

<pid>“\n” 


这 个 命令 用 于 启动 文件 同 
i 步 服务 。 它 是 "adb 
yne: push” Fu “adb pull” 的 实现 前 
提 








2. ADB Server<- ->ADB Daemon 


ADB Server 和 ADB Daemon 间 的 交互 ， 官 方 文 档 中 称 之 为 一 
个 “transport”。 目 前 系统 支持 两 种 形式 的 transport。 如 下 所 示 : 


e usb transport 


顾名思义 ， 这 说 明 ADB Server 和 和 Daemon 是 通过 USB 线 进行 连接 的 。 
通常 对 于 真实 的 Android 设 备 ， 都 采用 这 种 形式 。 


e local transport 


对 于 运行 于 研发 主机 之 上 的 模拟 器 ，ADB Server 将 通过 TCP 端 口 直 
接 与 其 连接 。 


49%, local transport 的 连接 方式 并 不 局 限于 模拟 器 。 换 句 话 
iz, ADB Server 与 真 机 设备 同样 也 可 以 进行 TCP 连 接 与 通信 。 另 外 ， 
locoal transport 也 并 不 仅仅 适用 于 ADB Server 与 Daemon 运 行 于 同一 主 
机 的 情况 理论 上 它们 可 以 分 布 在 世界 各 地 的 任何 角落 ， 只 不 过 到 目 
前 为 止 ADB 还 没有 实现 这 一 功能 。 





25.4 SDK Layout! ib 


Layout1ib 是 SDK 系 统 工具 集中 的 一 个 重要 组 成 部 分 ， 它 是 Android 
IDE (如 Eclipse、Android Studio 等 ) 实现 U1 界面 预览 的 关键 。 


Layout1ib 在 Android 源 码 工 程 中 的 路 径 
fz: /frameworks/base/tools/1ayout1ib， 主 要 组 成 元 素 如 下 所 示 。 


Android5.X frameworks base tools layoutlib 





bridge create rename_font 
z Layou 
# Cop The g 
z 
# Lic None 
Android.mk README 


我 们 先 来 看 下 README 文 件 对 它 的 描述 : 
/*README*/ 
Layoutlib is a custom version of the android View framework desig 
The goal of the library is to provide layout rendering in Eclipse 


None of the com.android.* or android.* classes in layoutlib run o 
大 家 注意 看 一 下 上 述 描述 中 的 两 个 重点 : 
e Custom version of the android View framework 


这 人 句 话 说 明 它 是 基于 Android View 框 架 的 一 个 定制 版 本 。 或 者 用 更 
直 日 的 话 来 讲 ， 惑 是 它 根 据 自 己 的 需求 对 View 框 染 进 行 了 改 瑟 。 那 么 目 
的 是 什么 呢 ? 


e Provide Layout rendering in Eclipse 


ARAMA CARES, RANMA SF Eclipse (IntelliJ 


1DEA 和 Android Studio 的 情况 也 是 类 似 的 ) 等 1DE 提 供 程 序 的 U1 宕 面 演 


染 功 能 。 
大 家 参考 图 25-10 所 示 的 截图 应 该 就 很 清楚 
(© MainActivityjava X | Kà activity_main.xml x 


Palette %- I“ [e Ti Nexus4- 六 @apptheme “MainActivityy @- H217 

BLE 图 - 回国 国 & aaBg a 
加 FrameLayout 
四 LinearLayout (Horizonti 
= LinearLayout (Vertical) 
[=| TableLayout 
图 TableRow 
团 GridLayout 

[H] RelativeLayout 

© Widgets 

bl Plain TextView 

Ab] Large Text 

Ab] Medium Text 

Ab Small Text 

ok Button 

ok Small Button 

(@ RadioButton 

CheckBox 
© Switch 





Medium Text 


= ToggleButton 

El ImageButton 

E ImageView 

== ProgressBar (Large) 
== ProgressBar (Normal) 


== ProgressBar (Small) 





=a DrnnreccRar (Horizont: 





全 图 25-10 Layoutlib ý HIDE F UILA Gis # 


图 25-10 中 activity_main. xm| 这 个 layout 的 界面 效果 可 在 右 侧 的 手 
机 框 中 实时 显示 出 来 ， 借 助 的 就 是 Layout1ib 这 个 工具 。 它 的 作用 有 点 
ao 但 是 在 原理 上 却 有 极 大 差异 Emulator SAh 

“运行 时 状态 ”的 ， 它 需要 借助 于 系统 Image 来 呈现 界面 效果 ; 而 
vert ib 产 生 界 面 的 过 Hene uena” a 





但 是 在 处 理 这 个 “静态 ” 责 面 的 过 程 中 ，Layout1ib 和 Emulator 一 
样 会 用 到 系统 Image 提 供 的 元 素 ， 比 如 View Framework。 只 不 过 这 些 系 
统 元 素 需 要 做 一 些 必 要 的 改造 ， 才 能 为 Layout1ib 所 用 。 不 难 推断 ， 实 
现 泻 染 U1 界面 这 样 一 个 功能 ， 实 际 上 是 要 做 大 量 工 作 的 。 


读者 可 能 会 有 疑问 ， 既 然 Layout1ib 承 担 的 任务 并 不 简单 ， 那 为 什 
么 /frameworks/base/tools/ layout1lib 中 的 源码 并 不 多 呢 ? 这 是 因为 
上 述 的 文件 夹 目录 只 包含 了 Layout1ib 的 部 分 实现 ， 真 正 的 “大 头 ”还 
在 于 Android View Framework， 以 及 如 何 改造 view framework。 大 家 如 
果 有 兴趣 的 话 可 以 分 析 一 下 Layout1ib 的 Android. mk 和 源码 实现 ， 从 中 
就 可 以 梳理 清楚 它 与 Yiew Framework 之 间 “ 干 丝 万 缕 的 关系 ”了 。 


25.5 TraceView 和 Dmtracedump 


我 们 知道 ，Android 开 发 者 可 以 在 代码 中 添加 Debug 类 提供 的 各 种 调 
试 函 数 ， 然 后 通过 SDK 中 的 TraceView 工 具 来 做 有 针对 性 地 分 析 。 接 下 来 
我 们 通过 一 个 简单 的 范例 来 实际 演示 下 TraceView 的 用 法 。 


Step1. 新 建 Android 工 程 。 
创建 一 个 简单 的 Android 应 用 程序 工程 ， 你 可 以 通过 各 种 1DE 来 快速 


完成 这 一 步 


Step2. 在 需要 被 追踪 的 起 点 和 终点 分 别 加 上 Debug 提 供 的 各 类 配套 
芳 数 。 璧 如 在 Activity 的 onCreate 和 onStop 中 添加 起 止 函 数 : 


@Override 

public void onCreate(Bundle savedInstanceState) { 
Debug.startMethodTracing("TraceTest") ; 
super .onCreate(savediInstanceState) ; 
setContentView(R.layout.main) ; 


} 


@Override 

protected void onStop() { 
super .onStop(); 
Debug. stopMethodTracing(); 


“TraceTest” 是 trace 文 件 的 名 称 ， 默 认 值 是 dmtrace. trace; WR 
没有 特别 指定 的 话 ， 这 个 文件 的 最 大 值 是 8MB。 程 序 从 
startMethodTracing 开 始 记 录 数 据 到 缓存 中 ， 并 在 stopMethodTracing 
时 将 这 些 数据 写 入 文件 如 果 在 此 之 前 文件 大 小 达到 上 限 ， 则 系统 将 
提前 结束 录制 ， 并 有 相应 提示 。 


因为 trace 文 件 会 被 保存 到 外 部 设备 《如 SD 卡 ) 中， 所 以 程序 必须 
要 申请 WRITE_EXTERNAL STORAGE 权限 ， 否 则 运行 时 会 报错 。 


Step3. 运行 应 用 程序 ，LogCat 中 会 有 trace 文 件 创建 成 功 与 否 的 提 





15:09:48.262 13472-13472/com. example. TraceTest I/dalvikvm: TRACE STARTED: ' /storage/emulated/legacy/TraceTest. trace 8192KB 
15:14:21.277 13472-13472/com. example. TraceTest I/dalvikvm: TRACE STOPPED: writing 278282 records 


; Step4， 我 们 可 以 用 ADB 工 具 将 上 述 的 trace 文 件 拉 取 到 本 地 进行 分 
JT 


adb pull /storage/emulated/legacy/TraceTest.trace D:\ 


Stepd. trace 文 件 虽 然 是 文本 格式 ， 但 直接 查看 并 不 方便 ， 因 而 我 
们 需要 借助 TraceView 工 具 来 加 快 分 析 。 截 图 如 图 25-11 所 示 。 





i TraceTesttrace Ù = a 





msec: 327,468 max msec: 1,000 (real time, dual clack) 


PRM RTS OD a a T E 
0 50 W0 150 20 50300} 350 40 450 50 550 60 60 70 750 80 80 W 0 100 


OL TE E 有 


(10) Binder, 2 





[9] Binder 1 











Name Inel Cpu Time.. Inel Cpu Time Frl Cpu Tim.. Fae Cpu Time Inel Real Tim.. Inel Real Time Fuel RealTim... Fuel Real Time alstRecurf (A 
J 0 (toplevel) 1000% 1220.373 01% 1783 1000%  816115.565 00% (000 100 
| 1 andrutd/app/Activiy.setContentView (NV 749% 914,222 0.0% 0,022 01% 932.072 0.0% (022 1+0 
I] 2com/huaweijandroid/content/res/ResourcesExloadDray 659% 803.808 01% 1,184 0.1% 818,714 00% 1169 20 
F 3 androidjcontent/res/Kesources getDrawable(I)Landroic b30% (19999 UU% (1036 O14 (bie 0% UU HU 
J| 4 android/app/Actity.nitAcionBar OV 632% NI 00% 0,065 01% 781868 010% (068 = 240 
J| 5 com/android/nternal/poicy/im/PhoneWindow.setDef 629% 768.152 0.0% 0012 0.1% 777.686 00% 003 1+0 
I] 6 com/android/nternawidget/ActionBarViewsetlccn (V 629% 768.136 0.0% 0016 01% 77.610 0.0% (016 1+0 
T 7 com/huaweijandroid/hwutl/Zip‘ileCache.getAndCheckC 358% 437.406 0.0% (297 0.1% 442.651 00% (1295 W 


全 图 25-11 界面 图 


TraceView 分 为 两 个 部 分 : 


e Timeline Panel 


上 半 部 分 是 一 个 时 间 轴 ， 逐 行 展 示 各 个 线程 的 执行 情况 。 向 右 为 时 
间 递 增 方向 ， 并 以 不 同 颜色 区 分 各 被 调用 的 函数 。 


e Profile Panel 


下 半 部 分 提供 了 每 个 函数 所 花费 时 间 的 统计 信息 。 根 据 官方 文档 的 
说 明 ， 目 前 有 两 种 类 型 的 时 间 统 计 : lnclusive 和 Exclusive times。 后 
者 是 指 本 范 数 运行 所 花费 的 时 间 ， 而 inclusive 则 是 本 函数 及 它 所 调用 
的 函数 的 时 间 总 和 。 调 用 和 被 调 函 数 分 别 被 称 
为 “parents” 和 “children”， 并 分 别 以 紫色 和 黄色 显示 。 


因为 trace 中 保存 了 各 个 函数 间 的 调用 关系 ， 我 们 自然 而 然 地 想到 
是 否 可 以 由 此 生成 函数 间 的 “调用 树 ” 呢 ?答案 是 肯定 的 ， 而 且 
Android 也 提供 了 现成 的 工具 来 达到 这 一 目标 ， 即 Dmtracedump 。 不 过 这 
个 工具 生成 调用 树 的 速度 比较 慢 ， 感 兴趣 的 同学 可 以 自行 党 试 。 


值得 一 提 的 是 ， 上 述 内 容 中 只 讲述 了 trace 机 制 的 其 中 一 种 关键 用 
法 。 事 实 上 它 是 Android 虚 拟 机 内 部 的 重要 组 成 部 分 ， 并 支持 多 种 工作 
方式 o] 总 结 如 下 z 


。 通 过 系统 属性 来 控制 trace 
当 Androi dRuntime 启 动 一 个 虚拟 机 时 《可 以 参见 本 书 Android 虚 拟 


机 章节 的 分 析 ) ， 它 会 通过 解析 各 种 系统 参数 来 对 后 者 进行 配置 ， 其 中 
与 trace 相 关 的 处 理 如 下 所 示 : 


* 


* Tracing options. 
Ei 


property get ("dalvik.vm.method-trace", propBuf, "false"); 
if (strcmp (propBuf, "true") == 0) { 
addOption ("-Xmethod-trace"); 
parseRuntimeOption ("dalvik.vm.method-trace-file", 
methodTraceFileBuf, 
"-Xmethod-trace-file:"); 
parseRuntimeOption ("dalvik.vm.method-trace-file-siz", 
methodTraceFileSizeBuf, 
"-Xmethod-trace-file-size:"); 
property get ("dalvik.vm.method-trace-stream", propBuf, "false"); 
if (strcmp (propBuf, "true") == 0) { 
addOption ("-Xmethod-trace-stream") ; 
} 


一 旦 虚拟 机 参数 中 带 有 使 能 Trace 的 控制 选项 后 ， 
Runtime: :start () 内 部 就 会 主动 调用 Trace: :Start () 来 完成 对 trace 的 
启动 ， 最 终 效 果 和 前 述 添加 Debug. startMethodTracing 的 方法 是 一 样 
的 。 


o 利用 /system/bin/am 来 控制 trace 


保存 在 bin 路 径 下 的 am 是 一 个 she11 脚 本 ， 它 提供 了 Act ivity 相 关 的 
很 多 操作 ， 包 括 本 小 节 所 讲解 的 trace 机 制 。 具 体 实 现 上 ，am 将 运行 
am. java 文 件 ， 后 者 则 进一步 利用 ActivityManager Service 所 提供 的 服 
务 来 开启 /关闭 trace。 因 为 AMS 和 各 个 应 用 程序 进程 间 保 持 着 通信 关 
联 ， 所 以 可 以 很 容易 地 把 trace 控 制 消息 推送 给 它们 。 各 应 用 程序 会 在 
主线 程 中 处 理 这 些 消息 ， 而 且 它 们 同样 也 是 借助 于 
Debug. startMethodTracing/Debug. stopMethodTracing 来 开关 trace 
的 。 有 兴趣 的 读者 可 以 阅读 ActivityThread 中 的 startProfiling 和 
stopProfiling 了 解 详 情 。 





e 利用 Debug.startMethodTracing/Debug.stopMethodTracing 来 控制 trace 


这 也 是 本 小 节 前 面部 分 所 讲解 的 方式 。 这 种 手法 需要 源 代码 的 配 
合 ， 因 而 操作 上 有 一 定局 限 性 ;优点 就 是 可 以 精确 地 将 trace 范 围 控制 
在 特定 的 代码 行 处 。 


由 此 可 见 trace 文 持 的 控制 方式 也 是 挺 多 的 ， 开 发 人 员 可 以 根据 实 
际 情况 选择 适合 自己 的 具体 手段 。 


25.6 Systrace 


Android 的 SDK 中 还 提供 了 一 个 分 析 应 用 程序 U1 运行 性 能 的 工具 ， 名 
为 Systrace (对 应 的 文件 夹 是 SDK/platform-tools/systrace) 。 
Systrace 是 由 Python 书 写 完成 的 ， 因 而 用 户 在 使 用 前 需要 安装 Python 的 
运行 环境 。 


经 验 表 明 应 用 程序 需要 保证 60 帧 / 秒 的 U1 绘制 速率 才能 让 用 户 感觉 
到 交互 过 程 是 “流畅 ”的 ， 所 以 我 们 在 开发 程序 时 需要 有 工具 来 帮助 衡 
量 应 用 程序 是 否 达 到 了 这 一 要 求 一 一 Systrace 就 可 以 做 到 这 点 。 男 外 ， 
它 还 额外 提供 了 针对 系统 和 应 用 程序 在 内 的 很 多 其 他 有 效 的 分 析 方 式 ， 
通常 情况 下 我 们 可 以 结合 起 来 分 析 。 

Systrace 的 启动 方法 比较 多 ， 既 可 以 在 1DE 中 通过 单 击 按键 的 方式 
来 调用 ， 也 可 以 利用 Android Device Monitor 中 的 四 来 启动 ， 还 能 
接 通过 命令 行 的 方式 来 运行 ， 格 式 如 下 : 
python systrace.py [options] [category1] [category2] ... [categor 

其 中 0ptions 各 项 内 容 及 释义 如 表 25-24 所 示 : 


表 25-24 Systrace 支 持 的 各 类 选项 及 释义 针对 Android 4.3 及 以 上 版 本 ) 








-h, --help 显示 帮助 信息 
-o <FILE> 指定 HTML 报 告 的 文件 名 称 


-t N, --time=N 指定 需要 跟踪 的 时 间 长 度 ， 黑 认 值 是 5 秒 





if 


-b N, --buf-size=N | 指定 最 大 的 buffer size， 以 KB 为 单位 
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可 选 的 包 
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gfx --- Graphics 
-l, --list-categories 下 
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号 分 隔 。 要 特别 注意 的 是 ， 开 发 者 需要 在 
(ents imace 类 提供 的 各 种 接口 才能 
X 


从 文件 中 生成 一 份 Systrace 报 告 


“DEVICE_SERIAL>| 连接 的 设备 中 选择 需要 被 跟踪 的 设备 


<DEVICE_SERIAL> 





Android Device Manager 把 这 些 选 项 进行 了 图 形 化 ， 如 图 25-12 所 
示 。 


例 。 





© x 
Systrace (Android System Trace) 


Settings to use while capturing system level trace 


Destination File: | C:\Users\xsO\trace.html Browse... 


Enable Application Traces from: None {v | 


C] Graphics 
L] Input 
C] View System 
C] WebView 
C] Window Manager 
O] Activity Manager 
C] Application 
C] Resource Loading 

































Commonly Used Tags: 





L] Sync Manager 


口 
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Advanced Options: C RenderScript 
口 Bionic C Library 
[C] Power Management 
L] IRQ Events 
M 


CPU Frequency 











cone 














全 图 25-12 Systrace 的 图 形 化 界面 


图 25-13 所 示 是 捕获 “sched gfx view wm” 所 生成 的 一 个 报告 范 
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i 540 4 


Interactions 


Merts Bxpensive neaswe/-ayout 
+ Kernel pats 


PU 0: | ura | E oom edl w ES E Fi 
+ Surtacthlinger (pid 938) 
com android. settings ‘com androj 








: Schadaling delay 4 


三 卫 二 三 TS 


Starting com android, settings: 
FramebufferSurface: 


com android Launchor/com, androj | 


VOYNC app 





VSYNC-st ; 


1 [system/bin/surtacetl inger 














1 iten selected: | Cpi Slice (1) 


fuming thread: GiDaeno 
Start: 4,470, 06 me 
Luraticn: 1.0) 15 
Ares {rom "Aaen, 
sit 4, 
prio: 120, 


statelberDsschedu.ed: R] 


AR 25-13 报告 范例 


在 分 析 的 过 程 中 ， 我 们 要 特别 注意 那些 绘制 时 间 超过 16ms 的 操作 ， 
因为 这 些 很 可 能 是 导致 掉 帧 ， 进 而 引发 弄 面 “不 流畅 ”的 罪魁 视 首 。 同 
时 Systrace 也 提供 了 引导 信息 来 帮助 开发 者 改善 这 些 问题 ， 辟 如 右上 和 角 
的 Alert 就 是 对 于 程序 中 当前 存在 问题 的 警示 ; 而 对 于 消耗 时 间 过 长 的 操 
作 ， 则 会 有 特别 标注 ， 如 图 25-14 所 示 。 








全 图 25-14 界面 图 


红色 的 图 标 F《〈 运 行 图 可 看 到 颜色 ) 表示 当前 的 操作 远 超 过 常规 时 
间 ， 因 而 需要 用 户 特别 注意 。 


关于 Systrace 的 更 多 用 法 与 信息 ， 和 希望 读者 可 以 结合 实际 的 性 能 优 
化 范例 来 学 习 体 会 ， 相 信 会 有 不 小 的 收获 。 


当然 ， 这 些 分 析 工 具 并 不 是 Android 操 作 系 统 专 有 的 。 事 实 上 我 们 
要 看 到 Android 在 Instruments/Profiler 工 具 上 与 Apple xCode, Visual 
Studio 和 Tizen 等 操作 系统 还 有 一 定 的 差异 。 其 中 Apple xCode 以 完备 的 
Instruments 而 备 受 开发 人 员 喜 爱 ， 如 图 25-15 所 示 。 


Apple xCode 提 供 了 各 种 类 型 的 监测 工具 ， 包 括 Memory Leak, 
CPU、GPU 等 。 开 发 者 可 以 在 如 上 所 示 的 统一 界面 中 添加 所 要 监控 的 对 
象 ， 以 直观 的 方式 查看 profi1e 结 果 。 


而 Ti zen 系 统 则 了 明显 吸收 了 xCode 的 这 些 “优势 ”， 所 以 在 功能 上 它 
们 是 比较 相似 的 一 一 只 不 过 前 者 暂时 还 没有 xCode 做 得 那么 完善 。 功 能 
截 选 如 图 25-16 所 示 。 
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All Heap & Anonymous VM 44,734 1745MB 677,119 = 380.77 MB 688853 itt 一 一 一 一 一 
- . Mark Generation | 
All Heap Allocations {1,677 986MB 676,125 311.09MB 687802 | _ 
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“) Imagel0 jpeg. Data 1 402MB 0 40MB 24 | AM Alocaton 
VM: Corelmage 21 4.02 MB 0 402MB 21 | O Created & Persistent 
VM: CoreAnimation 10 472MB 18 268MB 28 vad & Do 
Malloc 1.50 MB 1 1.50 MB 0 1.50 MB 1 
VM: Performance tool data ? 1.04 MB 0 10MB 2 Allocation Type 
) Malloc 1.00 MB 1,00 MB 6 100MB 7 O AI Heap & Anonymous W 
Malloc 47.50 KB 21 70750KB O 787.50K8 4 At Heap Alocations 
| VM: CG raster deta 22 680.00 KB 0 680,00 KB 2 AI VM Regions 
NSlnlineData 21 483,00 KB 80 445.64 KB 101 Call Tree 
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| CFData (store) 306 159.61 KB 1,624 1.80 MB 1,930 
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Malloc 64 Bytes 845 5A8IKB 50167 9,11 MB 51,012 
| Malloc 16.00 KB 3 48,00 KB dad 3.86 MB 247 | 
门 NSISLingarExpression 5 dB6KB 37 BKE 87 人 
CFData 418 43.31 KB 1930 = 210.33 KB 2,348 0 
(| VM: CoreUl image data 2 40.00 KB 0 40.00 KB 2 G 
CFString (immutable) 651 319KB 7855 476.00 KB 8,506 
| Malloc 16.50 KB 2 33.00 KB 127 2.08 MB 129 Data Mining 
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Tizen Dynamic Analyzer 
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Heap allocation B 
3 Atest CPU (%) Process 
system-monitor 

PID : 3008 08 





79.7MiB 
Time | TD | AD | 
00:01.106|/3008 |3008 start 


Process Size 
system-monitor 00:01.109 | 3008 3008 __libe csu 
PID : 3008 op }|| 00:01.109 3008 3008 init 





545 amig | | 00:01,109 3008 | 3008 main 
00:01.146 | 3008 3008 create wi 
00.01335 | 3000 3000 create eli 
00:01,368 3008 3008 create_co 
00:01.372| 3008 3008 create la‘ 
00:01.375 | 3008 |3008 create na 
00:01.375 | 3008 3008 create sc 
00:01.377 | 3008 3008 load edj 
00:01.380 | 3008 3008 get interf 
00:01.382 | 3008 3008 load edj 
00:01.382 | 3008 3008 load edj 
00:01.383 | 3008 3008 create lal 
00;01,385 | 3008 3008 load edj 





全 图 25-16 Tizen Dynamic Analyzer 


不 同 操作 系统 中 的 监控 机 制 存 在 不 小 的 差异 ， 因 而 体现 在 具体 的 实 
现 上 就 难免 有 些 不 同 。 合 理 利用 系统 提供 的 性 能 监测 和 问题 定位 工具 有 
利于 我 们 尽早 发 现 隐藏 在 程序 中 的 潜在 问题 ， 从 而 有 效 提高 代码 的 可 靠 
性 和 程序 的 稳定 性 。 


最 后 我 们 对 Android 中 的 常用 Profi le 工具 做 了 一 个 小 结 ， 供 大 家 人 参 
考 借 鉴 。 如 表 25-25 所 示 。 





表 25-25 Android 常 用 工具 一 览 表 


提供 了 程序 中 各 个 线程 和 函数 的 执行 起 始 时 间 ， 
以 及 单个 函数 内 部 具体 的 时 间 消 耗 





占用 内 存 空间 的 各 个 对 象 的 详细 信息 ， 包 括 对 象 
所 属 Class， 所 属 线程 、 分 配 内 存 的 代码 位 置 等 


这 一 项 和 前 述 两 项 是 Android 系 统 中 分 析 应 用 程序 
内 存 问 题 的 “最 佳 搭档 >”。 一 个 典型 的 使 用 流程 
是 : 我 们 首先 使 用 Memory Monitor 来 观察 程序 是 
全 经 党 性 发 生 GC 事 件 (问题 是 否 存在 ) 答案 

的 ， 开 发 者 再 进一步 利用 Heap Viewer 
来 甄别 出 候选 的 可 疑 对 象 类 型 〈 导 致 问 题 的 可 疑 
对 象 是 什么 ) ， 并 借助 于 Allocation Tracker 来 确 
定 发 生 问 题 的 代码 在 哪个 位 置 (问题 是 如 何 产 生 
的 ) 。 大 家 可 以 参阅 本 书 第 5 章节 中 对 内 存 管理 优 
化 的 分 析 




















MAT 并 非 由 Android 系 统 提 供 ， 而 是 Eclipse 基金 会 
Memory 开发 的 一 款 通 用 型 的 JVM 内 存 问题 诊断 分 析 器 。 
Analyzer 。 | 如 果 开 发 人 员 在 使 用 上 述 几 个 内 存 工具 后 仍 无 法 
ao 解决 问题 ， 可 以 尝试 通过 MAT 来 做 进一步 分 析 。 
MAT 的 官方 网 址 是 : https://eclipse.org/mat 





Development 
Tools (安装 
于 Android 设 
wE) 


分 析 应 用 程序 的 UI 界面 框架 ， 从 而 找 出 是 否 有 影 
啊 性 能 的 元 余 实现 


可 以 让 开发 者 对 整个 Android 设 备 中 的 进程 和 线程 

执行 情况 进行 分 析 。 这 个 工具 的 独特 优势 是 可 以 

针对 UI 界面 的 各 个 绘制 帧 进行 跟踪 ， 并 从 中 得 出 

R 同时 还 有 相应 的 解决 方法 
六 


用 于 辅助 开发 人 员 分 析 OpenGL ES 程序 中 的 代码 
问题 。 如 捕获 OpenGL ES 的 命令 以 及 各 帧 的 信息 





各 个 ROM 厂 了 商 通 常会 定制 自己 的 开发 调试 设置 ， 
如 图 25-17 所 示 的 范例 截图 
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Show clip bounds, margins, etc 


Force RTL layout direction 
Force screen layout direction to RTL for all 
locales 


Window animation scale 
Animation scale .5x 


Transition animation scale 
Animation scale .DX 


Animator duration scale 
Animation scale .5x 


Simulate secondary displays 
None 


HARDWARE ACCELERATED RENDERING 


Force GPU rendering 
Force use of GPU for 2d drawing 


Show GPU view updates 


Flash views inside windows when drawn 


g=. L Cc 
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2.7 RBR 

代码 履 兰 率 是 用 于 衡量 测试 用 例 完 整 性 的 重要 手段 之 一 ， 可 以 说 绝 
大 多 数 对 质量 要 求 严 苛 的 公司 都 会 对 此 有 量化 要 求 。 例 如 笔者 曾 和 
Goog | i 部 人 员 做 过 交流 ， 他 们 通常 都 会 要 求 项 目的 代码 覆盖 率 达 到 
85% 以 


从 技术 角度 来 看 ， 实 现代 码 覆 功率 的 方法 很 多 ， 它 们 大 致 可 以 被 归 
为 图 25-18 所 示 的 几 个 分 类 。 


Code Coverage 


a 和 
Runtime Profiling 
a 


JVMPI JVMTI 







全 图 25-18 代码 改 盖 率 的 实现 方法 
(引用 自 Jacoco 官 方 文档 ) 


目前 主流 的 代码 必 盖 率 工 具有 Emma、Jacoco、Clover 等 。Jacoco 因 
为 其 功能 全 面 ， 开 源 社 区 活跃 等 诸多 优点 ， 可 以 说 是 当前 Java 珊 最 流行 
的 代码 覆盖 率 工具 之 一 。 


其 中 Eclemma 是 一 个 Eclipse 插件 ， 其 开始 的 版 本 中 使 用 的 是 Emma， 
后 来 则 改 用 Jacoco 作 为 它 的 核心 基础 库 。 


总 的 来 说 ， 代 码 履 善 率 框 架 支 持 两 种 工作 模式 ， 即 0n-the-fly 


instrumentation 和 Offline instrumentation. 


0n-the-fly 简 单 而 言 就 是 利用 代码 宪 蔓 率 工 具 自 己 的 Class Loader 
来 代 蔡 程序 原先 的 加 载 器 ， 并 在 动态 运行 时 加 入 代码 履 盖 率 统计 信息 。 


这 种 方式 有 一 定 的 局 限 性 ， 例 如 无 法 适用 于 如 下 的 场景 : 


e 不 支持 Java Agents 的 运行 时 环境 ; 

在 部 署 时 无 法 配置 JVM 参 数 的 情况 ; 

需要 将 字 节 码 转 化 为 其 他 虚拟 机 码 ‘ a JL, Android Dalvik VM; 
与 其 他 agents 会 产生 运行 时 冲突 的 情 

需要 被 Boot Class Loadet 加 载 的 类 。 


由 于 上 述 这 些 原 因 ，Android 系 统 选择 的 是 代码 禾 盖 率 工具 〈 以 前 
是 Emma， 目 前 是 Jacoco) 的 另 一 种 工作 模式 ， 即 0ffline 
instrumentation。 暴 型 的 命令 如 下 所 示 : 








java -cp emma.jar emma instr -m overwrite -cp to_be_instrumented. 


其 中 to_be_instrumented. jar 是 需要 被 统计 的 对 象 ， 会 被 事先 做 择 
HE 处 理 。 具体 到 Android 的 编译 环境 中 ， 代 码 履 盖 率 工具 通常 需要 处 理 
的 对 象 是 $ (full_classes_jarjar_jar)。 为 了 保证 收集 的 履 蔓 信息 可 以 
与 源 代码 建立 起 正确 的 关联 ， 通 常 要 求 Java 编 译 的 是 Debug 版 本 。 


Android 早 期 版 本 中 使 用 的 代码 履 盖 率 套件 是 Emma， 后 来 则 逐步 切 
换 为 Jacoco。 另 外 ， 随 着 Android M 版 本 中 Jack 编 译 器 的 出 现 ， 情 况 又 
发 生 了 一 些 变化 。 因 为 Jack 编 译 器 会 直接 生成 dex 产 物 ， 导 致 很 多 依赖 
T 这 其 中 就 包括 了 代码 履 盖 率 

工具 。 按 照 6oogle 内 部 的 一 些 资料 来 看 ， 他 们 也 在 学 
Android N preview 版 本 中 发 布 的 Jacoco 子 项 目 或 许 会 一 个 比较 
好 的 解决 方案 。 


一 点 从 编译 脚本 中 也 可 以 看 出 来 。 如 下 是 Android M 版 本 里 的 实 





现 : 


/*build/core/java_library.mk*/ 

ifeq (true, $(EMMA_INSTRUMENT ) ) 

ifeq (true, $(LOCAL_EMMA_INSTRUMENT) ) 
ifeq (true, $(EMMA_INSTRUMENT_STATIC) ) 
LOCAL_STATIC_JAVA_LIBRARIES += emma 
endif # LOCAL_EMMA_INSTRUMENT 

endif # EMMA_INSTRUMENT_STATIC 

else 

LOCAL_EMMA_INSTRUMENT := false 

endif # EMMA_INSTRUMENT 


与 之 对 应 的 Android N 版 本 中 的 实现 : 


/*build/core/java_library.mk*/ 

ifeq (true, $(EMMA_INSTRUMENT ) ) 

ifeq (true, $(LOCAL_EMMA_INSTRUMENT ) ) 
ifeq (true, $(EMMA_INSTRUMENT_STATIC) ) 
# Jack supports coverage with Jacoco 
LOCAL_STATIC_JAVA_LIBRARIES += jacocoagent 
endif # LOCAL_EMMA_INSTRUMENT 

endif # EMMA_INSTRUMENT_STATIC 

else 

LOCAL_EMMA_INSTRUMENT := false 

endif # EMMA_INSTRUMENT 


由 于 历史 原因 ，Androi dai Balas pA (C85 78 te 28 1B KAY BE 9A 
沿用 “Emma ”这 个 词 ， 但 是 内 部 实现 却 一 直 在 发 生变 化 ， 这 一 点 需要 大 
家 特别 注意 。 如 无 特别 说 明 ， 下 面 内 容 中 所 提 到 的 Emma 是 指 通用 的 代码 
黎 兰 率 工 具 ， 而 不 区 分 具体 类 型 。 


上 述 两 个 脚本 中 涉及 3 个 重要 的 变量 ， 其 中 
EMMA_INSTRUMENT_STAT1C 会 把 Emma 的 核心 jar 包 加 入 所 有 开启 了 Emma 功 
能 的 模块 中 (从 java_1ibrary. mk 和 package_internal. mk 等 共用 脚本 中 
i INSTRUMENT_STATI1C 的 处 理 过 程 也 可 以 看 出 这 点 ) 。 


和 EMMA_1NSTRUMENT_STATI1C 不 同 的 是 ，EMMA_1INSTRUMENT 只 对 
|ibcore 起 作用 。 LOCAL EMMA _INSTRUMENT 则 是 一 个 本 地 变量 ， 是 各 个 
模块 中 使 用 Emma 功能 的 控制 开关 。 


FE BRET Android RAPHE Kem ear 《以 
Framework} fll) 的 典型 操作 步骤 : 


(1) Android M 版 本 之 前 《默认 使 用 的 是 emma. jar) 


Step1， 在 /frameworks/base/Android. mk 中 与 Framework. jar 相 关 
联 的 部 分 添加 如 下 两 行 语 句 : 
LOCAL_MODULE := framework 


EMMA_INSTRUMENT := true ## 新 增 语句 ， 打 开 EMMA 开 关 
LOCAL_EMMA_INSTRUMENT := true ## 新 增 语句 ， 人 允许 Framework 这 个 模块 进行 代入 


Step2， 在 编译 版 本 之 前 ， 先 执行 如 下 语句 : 








export EMMA_INSTRUMENT_STATIC=true 


Step3. 清除 之 前 的 编译 结果 : 


make clean 
Step4， 执 行 编译 。 


在 编译 过 程 中 ，java. mk 会 根据 上 述 的 配置 条 件 进 行 Emma 相关 处 
理 ， 具 体 如 下 : 


$(full_classes_emma_jar): $(full_classes_jarjar_jar) | $(EMMA_JAR 
$(transform-classes.jar-to-emma) 


编译 系统 中 的 函数 统一 定义 在 definitions. mk 中 ， 如 下 所 示 : 


/*build/core/definitions.mk*/ 

define transform-classes.jar-to-emma 

$(hide) java -classpath $(EMMA_JAR) emma instr -outmode fullcopy 
$(PRIVATE_EMMA_COVERAGE_FILE) -ip $< -d $(PRIVATE_EMMA_INTERM 
$(addprefix -ix , $(PRIVATE_EMMA_COVERAGE_FILTER) ) 

endef 


因为 Emma 的 插 桩 能 力 体 现在 一 个 名 为 “emma. jar” 的 Jar 包 中 ， 所 
以 我 们 需要 调用 Java 命 令 来 运行 它 。Emma 支 持 多 种 参数 配置 ， 例 如 - 
outfi le 用 于 指定 em 文件 《详细 记录 了 Emma 对 目标 所 做 的 插 术 内容， 以 
便 后 面 和 采集 到 的 运行 数据 进行 合并 ， 最 终 得 到 代码 履 盖 率 ) 的 路 径 ， 
即 
$ (PRIVATE EMMA COVERAGE FILE)=$ (intermediates. COMMON) /coverage. 
输入 参数 $< 指 的 是 第 一 个 依赖 条 件 ， 璧 如 在 这 个 场景 中 对 应 的 是 
$(full_classes_jarjar_jar) 。 而 “-d” 表 示 输 出 路 径 ， 具 体 值 是 
$ (PRIVATE EMMA INTERMEDIATES ae =$ (intermediates. COMMON) /emma 
如 果 对 j 这 些 知识 点 不 清楚 的 话 ， 建 议 大 家 可 以 参考 一 下 本 书 的 编译 系统 


Bp. 


编译 成 功 后 ，Framework 对 应 的 代码 覆盖 率 中 间 产 物 如 图 25-19 所 
Ko 


ES framework_intermediates emma out 
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101 
1010 


emma_out jack-rsc 


with-local classes.dex 
一 人 一 10 
101 
1010 
classes.jack classes.jar classes2.dex 


i me me 


classes-full-debug. classes-jarjar.jar classes-no-debug- 
jar var.jar 
1 frame 
10 frame a 
= frame | 
coverage.em jack-rsc.java-source- javalib.jar 
list 


全 图 25-19 中 间 产 物 
Step5， 将 上 述 步 又 中 输出 的 最 终 软 件 版 本 刷 写 到 设备 /或 模拟 器 
Step6， 执 行 测试 过 程 ， 收 集 代 码 履 盖 率 统计 文件 coverage. ec. 
Step7， 利 用 Emma 提供 | 结合 coverage. ec 和 
coverage. em 文件 生成 最 终 的 报告 。 暴 型 命令 如 下 : 


java -cp path/to/emma.jar emma report -r html -in coverage.em -in 


可 见 Android 系 统 中 自 带 的 Emma 工具 使 用 起 来 还 是 比较 方便 的 。 大 
家 如 果 在 项 目 开 发 中 有 类 似 需 求 ， 建 议 可 以 充分 利用 Android 提 供 的 已 
有 工具 ， 达 到 事半功倍 的 效果 。 


(2) Android N 版 本 “默认 使 用 的 是 jacoco) 


由 于 Jack 编 译 器 的 工作 原理 限制 ，Android 系 统 需要 对 原先 的 代码 
窗 瘟 率 统计 方式 进行 调整 。 例 如 在 java. mk 中 ,ful| classes emma jar 
已 经 不 复 存 在 ， 同 时 bui1t_dex_intermediate 的 定义 也 发 生 了 改变 : 


/*build/core/java.mk*/ 

ifeq ($(LOCAL EMMA INSTRUMENT), true) 

$(built_dex_intermediate): PRIVATE JACK COVERAGE OPTIONS := \ 
-D jack.coverage="true" \ 
-D jack.coverage.metadata. file=$(intermediates.COMMON)/covera 
-D jack.coverage. jacoco.package=$(JACOCO_PACKAGE_NAME ) 

else 

$(built_dex_intermediate): PRIVATE_JACK_COVERAGE_OPTIONS := 

endif 


中 间 过 程 的 dex 文 件 会 包含 插 桩 后 的 信息 ， 它 的 生成 过 程 是 : 
$(built_dex_intermediate): $(jack_all_deps) | setup-jack-server 


@echo Building with Jack: $@ 
$(jack-java-to-dex) 


$ (jack—java-to-dex) 的 定义 在 Definitions. mk 中 ， 它 最 终 会 调用 
jack 这 个 工具 链 来 把 Java 编 译 成 dex， 并 且 会 根据 上 述 的 
PRIVATE JACK COVERAGE 0PTIONS 选 项 同步 生成 插 桩 信息 。 这 样 一 来 
Android N 版 本 中 代码 覆盖 率 统计 的 成 功 与 否 ， 很 大 程度 上 就 取决 于 
jack 这 个 编译 器 的 内 部 实现 了 。 

值得 一 提 的 是 ，A0SP 工 程 的 external/jack 目 录 下 是 空 的 ，jack 的 
真正 源码 目录 是 toolchain/ jack。 参 见 如 下 网 址 : 


https://android. googlesource. com/toolchain/jack/ 


而 且 我 们 在 git clone jack 项 目 时 ， 还 需要 加 上 特定 的 分 支 信 息 
(因为 其 master 分 支 也 是 空 的 ) 。 大 家 可 以 参考 如 下 的 命令 行 范例 : 


git clone https://android.googlesource.com/toolchain/jack -b ub-j 


另外 ，jacoco 生 成 报告 的 方式 和 Emma 还 是 有 些 差 异 的 ， 大 致 有 如 下 
几 种 方法 。 


e jacoco 插 件 


如 果 你 是 通过 IDE (Eclipse, Android Studio) 创建 的 工程 项 目 
《如 Android 应 用 程序 工程 》， 那 么 推荐 使 用 集成 的 jacoco 插 件 ， 这 样 
可 以 省 去 很 多 麻烦 


e Ant/Maven 


假设 是 非 1DE 的 工程 ， 那 么 在 收集 到 才 盖 率 数据 后 ， 我 们 可 以 利用 
Ant/Maven 来 生成 最 终 的 报告 〈 到 目前 为 止 ，jacoco 并 不 支持 命令 行 形 
式 的 报告 生成 方法 ) 。 


o 使 用 jacoco 提 供 的 API 接 口 
Jacoco 虽 然 不 支持 命令 行 来 生成 报告 ， 但 我 们 仍然 可 以 利用 它 提供 


的 AP1 接 口 来 编写 自己 的 报告 生成 工具 。Jacoco 官 方 为 此 还 提供 了 一 
参考 范例 。 


25.8 模拟 GPS 位 置 


开发 人 员 在 某 些 情况 下 需要 模拟 GPS 坐标 位 置 ， 例 如 为 地 图 软件 构 
建 全 球 各 地 的 测试 场景 一 一 些 时 我 们 就 可 以 用 到 Mock GPS Location. 


Android 系 统 也 考虑 到 了 类 似 的 诉求 ， 并 提供 了 一 定 的 方法 来 帮助 
开发 者 更 方便 地 达成 目标 。 不 过 随 着 版 本 的 升级 换代 ， 系 统 提供 的 具体 
辅助 方式 也 在 不 断 调 整 。 以 真 机 设备 〈 模 拟 器 上 Mock Locat ion 的 方法 
有 很 多 ， 比 如 利用 DDMS 提 供 的 专用 Pane1， 用 Emulator Console 来 发 送 
命令 等 ) 来 说 ， 旧 版 本 的 Android 系 统 会 在 开发 者 选项 中 提供 一 个 “多 
许 模 拟人 位置 ”的 开关 。 在 这 个 选项 打开 的 情况 下 ， 我 们 再 借助 于 某 些 专 
用 程序 便 可 以 实现 GPS 信息 的 模拟 ; 而 新 版 本 Android 系 统 中 的 控制 粒度 
更 细 了 ， 需 要 用 户 精确 选择 可 以 做 Mock Location 的 程序 ， 对 比如 图 25- 
20 所 示 。 


而 且 对 于 那些 希望 出 现在 “Select mock loction app” 列 表 中 的 
应 用 程序 ， 它 们 还 得 在 Androidmanifest. xm| 中 显 式 声明 下 面 属性 : 





&lt;uses-permission android:name="android.permission.ACCESS MOCK_ 


Android 6. 0 之 前 ， 开 发 者 可 以 利用 
Settings. Secure. ALLOW_MOCK_LOCATION 来 判断 当前 是 否 开 启 了 位 置 模 
拟 功 能 ; 而 Android 6. 0 之 后 这 个 变量 就 被 废弃 了 ， 开 发 者 可 以 尝试 使 
用 isFrom MockProvider 来 做 类 似 的 检测 。 


《 开发 者 选项 


开启 开发 者 选项 


打开 蓝牙 数据 包 日 志 


抓 取 所 有 蓝牙 数据 包 到 一 个 文件 — 


打开 监 牙 调试 日 志 


PLATA EF isis BA Ne 
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Developer options 
USB debugging 
Debug mode when USB is connected Ko 
Revoke USB debugging authorizations 


Monitor apps installed by ADB 


Require user confirmation when apps installed by ADB 


Select mock location app 
No mock location app set 


Enable view attribute inspection 


Select debug app No debug app set 


= 


Restore default settings 


全 图 25-20 Android 开 发 者 选项 中 位 置 模拟 功能 的 变化 
( 左 : 6.0 之 前 右 : 6.0 之 后 ) 


当 我 们 需要 将 系统 的 GPS 坐标 设置 成 某 个 指定 地 点 时 ， 可 以 调用 
LocationManager 中 提供 的 setTestProviderLocation 接 口 ， 范 例如 下 : 


String providerString = LocationManager .GPS_PROVIDER; 
Location mockLocation = new Location(providerStr); 
mockLocation.setLatitude(123); 
mockLocation.setLongitude(123); 
mockLocation.setAltitude(30) ; 


locationManager .setTestProviderLocation(providerString, mockLocat 


如 果 程 序 声 明了 ACCESS_MOCK_LOCATI0N， 融 可 以 通过 上 述 方法 来 产 
生 模 拟 的 位 置 了 ， 从 而 完成 测试 目标 。 


